Various notes on /usr unification [LWN.net]

Various notes on /usr unification

Posted Mar 6, 2012 1:36 UTC (Tue) by rgmoore (✭ supporter ✭, #75) [Link]

I don't see fstab as losing its importance. You still need some place to record the identifiers and mount points for the key partitions, which may include things like /var, /tmp, /opt, and /usr/local in addition to the ones you mentioned. That information has to remain available after initramfs has done its job, and root still needs to be able to edit it in case the hardware configuration changes. It seems to me that it's simpler to have one canonical copy of fstab that's located on the one disk that initramfs knows about by itself. The mount process is a bit more complicated than it would be if initramfs had its own copy of fstab- you have to mount that disk, read fstab, and then mount any other disks mentioned there- but that's still simpler than trying to keep two copies of fstab in sync by rebuilding initramfs any time the canonical copy is edited.

Various notes on /usr unification

Posted Mar 6, 2012 11:37 UTC (Tue) by Cyberax (✭ supporter ✭, #52523) [Link]

I wouldn't mind something fstab-y but a little bit more modern. Fstab format is way too obsolete, there are no real notions of dependencies and ordering.

For example, Amazon EC2 nodes have specialized disks for scratch space. I want to assemble a RAID-0 of them, format them as XFS and then mount them on /tmp.

In my ideal world the fstab-ng would have entry like:
>none /tmp xfs defaults,noatime depends-on=assemble-scratch-raid

Where assemble-scratch-raid is, perhaps, a systemd task.

Various notes on /usr unification

Posted Mar 6, 2012 21:48 UTC (Tue) by rgmoore (✭ supporter ✭, #75) [Link]

I could definitely see a reworked fstab format. Even if you don't want to work in dependencies- there's some concept of ordering, at least- the format is also terse and cryptic. I wouldn't mind something a bit more verbose and readable. Just don't let Lennart Poettering get involved, or it'll generate another tempest in a teapot no matter how good an idea it is.

Various notes on /usr unification

Posted Mar 6, 2012 22:03 UTC (Tue) by dlang (✭ supporter ✭, #313) [Link]

why would there be enough benefit in a more human readable fstab (which is mostly not manipulated by humans anyway) that would make it worth breaking all existing tools that understand the current format?

while I would agree that there are nicer ways to configure what's managed by fstab, there is a large pool of tools and training that know the existing format, what may have been a great change to make 30 years ago needs much more justification now.