Re: [gentoo-dev] Opinion against /usr merge

[Olivier Crête]

On Wed, 2012-07-18 at 18:24 -0700, Matthew Marlowe wrote:
> > It would be nice if a sensible structure could be proposed and
> > agreed by ALL Linux distributions (coordinated with BSD).
> >
>
> +1
>
> If a new file system standard is required, my preferences based on a
> history of what is worked and changed over the last 20-30 years would
> be:
>
> - OK with requiring / and /usr on the same FS.  This has become common
> practice with virtualization and small system deployments, and I
> haven't seen any compelling advantage for keeping separate on larger
> boxes.

No one proposes that, the only requirement that you have for modern
Linux to work well is that if /usr is on a separate partition, you need
to mount it before starting your main system (ie, from an initramfs).

> - NOT OK with limitation on allowing /var, /opt, /home, or any other
> common server mount points to require use of initramfs/initrd.  There
> is enough disagreement as to the reliability and ease of maintenance
> of initramfs/initrd that it should not be needed for common server
> deployments.

This is clearly not needed, /run was even invented to allow /var to be
mounted later.

> - It would be nice if the rootfs used a snapshot based filesystem and
> if the bootloader was intelligent enough to easily allow admins to
> boot to older snapshots as an expectation for any standard modern unix
> system.

One of the reasons to put everything in /usr is to allow using a
snapshot based FS, so you can run a system where /usr is read-only and
where when you can do all upgrade atomically by writing your changes to
a read-write snapshot and then switch all at once. So you never have any
half-upgraded package on your system.

> - Ideally, server motherboards would come with flash based storage
> where sysadmins could install rescue environments as part of a normal
> unix install, and that the boot loader or bios would be smart enough
> to provide the option to boot from it automatically whenever a normal
> boot failed.
> - NOT OK with removing the distinction between user and system
> binaries.  Essential binaries required to boot and troubleshoot system
> problems should be located separately from user binaries.  Security
> sensitive or paranoid admins should be able to make the system binary
> path read-only or completely remove the user binary directory from
> roots PATH if they so wish.

The rescue system should be entirely separate from the main system, so
it survives mishandled upgrades. So having that should not hinder how
your main system is built. So you should have it as a separate partition
or you can even have it an initramfs (ie, in a single file on the main
system).

> - OK with merging / and /usr, but in that case...why not just move
> everything in /usr to /...but limit /sbin to system binaries and /bin
> to user ones?  This would be horrible for migrations though and
> possibly confuse many scripts.

The idea of putting everything in /usr instead of / is that you can then
make /usr read-only and you can share /usr between multiple systems,
while / is read-write and contains /root and /etc.

> - NOT OK with making systemd the default init system anytime in the
> next few years, it is way too immature and like most major system
> software changes...probably will take much longer before it really has
> the standing to propose being a new standard.

I fully expect systemd to be the init system of the next iteration of
RedHat Enterprise Linux, which is probably the most "enterprise" of all
distributions, with the most QA and support and everything. It's not a
side project of dude of his basement, it has the full support of a large
team of people at RedHat. There has probably already been more testing
done on systemd today than on OpenRC...

> - What other elements can new filesystems like btrfs offer that should
> be considered?  ext3/ext4 has worked great with the older
> standards...but it essentially mimicked the capabilities of older
> file-systems that the original unix standards were based on.  Btrfs
> might change our expectations.  I'm assuming that btrfs will be the
> standard production fs in a few years.

The big thing that btrfs brings is snapshots and subvolumes... So it
makes it possible to do atomic upgrades and such. Also, you can have
"apps" be subvolumes and also handled atomically.

-- 
Olivier Crête
tester@g.o
Gentoo Developer