[Grml] Re: RFC: handling of external usb devices

[Michael Prokop]

* Mark <27e3kk302 at sneakemail.com> [20060905 01:15]:

> > problems start with multiple devices or devices with several
> > partitions on it

> Or moving the USB device from PC to PC.  That is the whole point of
> using USB for many people.  When you move the device, however, /dev/sda
> becomes /dev/sdd so the old-style fstab syntax just breaks.

ACK.

> Mika is probably right about automount.  His opinions are what make grml
> so great.

> On the other hand, *nix is a 30-year-old design.  Not all of it is still
> 100% right for today.  The fstab topic deserves more comments.  I have
> opinions about fstab.

> The /dev/XYZ syntax does not help.  I much prefer labels/UUIDs.  They
> are *much* less brittle for OS design.  It makes more sense to use
> labels/UUIDs than to synchronize /dev/XYZ changes.  A system based on
> labels/UUIDs has nothing to sync.  It "just works."

It fails as soon as multiple devices have the same fs-label.

[...]
> The traditional /dev/XYZ syntax is just a sysadmin preference.  It
> should not be turned into a fixed rule.  The rule being cemented now is
> this:  "grml will always use /dev/XYZ syntax no matter what you want,
> but we offer some alternative /dev/ABC-XYZ syntax too."

> The way to handle syadmin preferences is cheatcodes.  A grml cheatcode
> already toggles "build fstab."  A new cheatcode could toggle "use labels
> when building fstab" and "use UUIDs when building fstab."  That way,
> old-school sysadmins could keep /dev/XYZ (and risk the brittleness).

People don't read the docs (ask my mailbox). I want to avoid the use
of bootoptions as far as possible.

> Duplicate label problems are solved by UUIDs.  People worried about that
> should use UUIDs.  Incidentally, blkid gives the UUID.

Yes, but UUIDs are long and IMO they suck a little bit on
non-server-systems.

> > Additionally we will create
> > /dev/usb-sd* devices via udev rules like:

> The philosophy of grml was to avoid "symlink hell."  I'm ok with any
> solution that is not better handled by fstab labels.

"symlink hell" in regards to "init-stuff which has to be handled
manually" (/etc/rc*.d). You don't have to take care of /dev/usb-sd*
at all. All symlinks will be deleted automatically as soon as the
devices aren't present anymore. Nothing to care about.

> If the entire purpose is to avoid labels, then I do not like the
> solution, because syntax is a poor reason to do anything.  Besides, you
> could still put /dev/XYZ in comment sections of the fstab file.

> Swap partitions are even worse.  There is no fine control.  I'm not sure
> how to handle them automatically in any Debian system very well.  It's
> all-or-nothing.  Grml activates all swap partitions without regard to
> fstab unless you boot with cheatcode "noswap" which turns them *all*
> off.

> You can do swapon by label.  You can also boot noswap.  So then, by
> hand, you have full control:  boot noswap and do swapon by label, one
> swap at a time.  This technique gives you full control over which
> partitions are used.

Yes.

> Some of us like automation.  Some of us *need* automation for end users.
>  It would be nice to have labels for this purpose in fstab.  So, in
> effect, the rule might be this:  "only use a swap patition with these
> UUIDs and no other swaps you detect."  

Usually you set up a swap partition because you want to *use* it. :)
If you set up several swap partitions and want to use only a
specific one I think you have to handle this in your own initscript.

> These are my inputs:  Consider the mobile USB case.  Think about putting
> /dev/XYZ in fstab comments (where they are still visible, but not
> active).

Ok.

> Avoid symlink hell.

As written above: don't care about stuff you don't have to manage on
your own. :)

> Think about using cheatcodes to implement sysadmin prefs.

I'll talk about it with the other grmldevs on the next develmeeting.

regards,
-mika-
-- 
 http://grml.org/            # Linux for texttool-users and sysadmins
 http://wiki.grml.org/       # share your knowledge
 http://grml.supersized.org/ # the grml development weblog
 #grml @ irc.freenode.org    # meet us on irc
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://ml.grml.org/pipermail/grml/attachments/20060907/0cb0fef7/attachment-0003.pgp>