[plug] Statically Mounting USB Drives

[Daniel Pittman]

Gavin Chester <gavin.chester at gmail.com> writes:
> On Wed, 2008-05-28 at 14:02 +1000, Daniel Pittman wrote:
>> Gavin Chester <gavin.chester at gmail.com> writes:
>> > On Wed, 2008-05-28 at 11:50 +1000, Daniel Pittman wrote:
>> >
>> >> Using a persistent name rather than a hardware name makes your system
>> >> independent of that renumbering, and makes you happier in the long
>> >> run.
>> >
>> > Not always :-(

[...]

>> You then decided that the problem that the persistent naming tools were
>> intended to solve was more trouble than benefit.
>
> For me, yes.
>
>> > Now I have to remember to force non-persistent naming in my fstab
>> > setup since opensuse has adopted it as default.
>> 
>> So, now you carefully ensure that the same problem will occur again
>> next time you change the order of detection.
>
> No, as I understand it persistent names need the _same_ drive to allow
> successful booting - and its purpose is just to overcome the order of
> it all. 

What those names do is extract some meta-data from the disk[1], as well
as the filesystem -- the UUID and LABEL attributes are properties of the
filesystem in the partition, not of the disk.

The udev software doesn't care what physical device the filesystem
content resides on, so that part has no dependency on the physical disk.
(The device path does, which is why it isn't recommended for use. :)


If you reformat the filesystem the UUID will change, though the label
may stay the same.  Each choice has a trade-off, with my preference
being UUID -- I would rather be able to mount the disk in another
machine without label conflicts, though YMMV.

> I regularly setup systems with /home on a separate drive. Say, when I
> swap the /home drive for another some time later, my understanding of
> persistent names is that I believe this will mean failure to boot
> since fstab entries refer to the drive name/code rather than its boot
> order.

Well, they refer to the filesystem identity, so yes: if you want to
change the filesystem to a new device then you do need to update the
fstab.

On the other hand, at that same time you have installed hardware,
formatted filesystems, transfered data and so forth.  This is, at least
for most people, not a common operation.


However -- if you routinely reformat filesystems, and you don't like
mounting by label (or forget to keep a consistent label) then, yes,
mounting by UUID or LABEL will be more pain than mounting by disk.

(Until you get a BIOS or kernel that inserts USB devices before SATA
 devices in the boot sequence, and your ordering fails. ;)

> But, I said I have nearly forgotten what my particular experience was
> when dealing with this as a problem, so I may be wrong, in part ;-)
>
>> Clearly, my reading is wrong somewhere, because that interpretation
>> really doesn't make much sense.  Can you clarify?
>
> Hopefully the above will clarify.

It does clarify: your concern was about replacing disks or file systems,
which the persistent names do make a little more work.  Now I understand
why you might feel the persistent names are less useful.

I think, personally, that if replacing filesystems is more common than
booting your server then you are, colloquially, doin' it wrong. ;)

>> Oh, and it would be nice to know what the actual problem that caused
>> the system to be unbootable was -- was it grub or the fstab related
>> boot process that failed?  How, and why?  What did you need to do to
>> recover that?
>
> Well, grub only refers to what's in your fstab, so one follows the
> other. 

...er, no.  This is another topic, kind of, but no.

grub uses the content of /boot/grub/menu.lst and the BIOS device
enumeration to boot.  It passes an opaque string to the kernel /
initramfs combination for them to use in booting.

Changing /etc/fstab actually does nothing as far as grub is concerned[2].

[...]

>> Given the description at hand I can't really comment one way or the
>> other -- without any detail this is nothing but an assertion, and an
>> unarguable one, because I don't doubt you had problems, but I don't know
>> they had anything to do with the persistent device names.
>
> Are you the maintainer of the udev/persistent name package/system,
> because you seem terribly formal about me having bad experiences with it
> persistent names? ;-) 

No.  I just believe that most people will benefit from them, and that as
a general rule it is suboptimal advice for people to avoid them.

> But, _yes_ my problem had _everything_ to do with persistent naming
> since eliminating it manually (editing them out of fstab) was the
> widely recommended solution to rescue my system. I hope that provides
> all the answers you seek. It's jsut a case of an 'imposition' of a
> system management concept not being suited to everyone and every case.

I was curious, because you never know when you are going to learn
something new about the tool and how it can fail. :)

Regards,
        Daniel

Footnotes: 
[1]  Which is generally not recommended to use, but present.

[2]  ...though your distro may have added some magic to fix it up.