[Grml] Re: RFC: handling of external usb devices
Michael Prokop
mika at grml.org
Thu Sep 7 16:05:25 CEST 2006
* 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://lists.mur.at/pipermail/grml/attachments/20060907/0cb0fef7/attachment-0001.pgp
More information about the Grml
mailing list