UsrMove feature (was Re: FESCo meeting minutes for 2011-10-24)

Pádraig Brady P at
Fri Oct 28 11:01:55 UTC 2011

This feature is going to cause a lot of churn.
Aside from the huge changes within fedora I
think a bigger issue will be downstream of fedora
where third party packages and configs will
require large changes.  I would worry we might
alienate our users a bit with this?

Now I'm all for clean up, but sometimes it
may have to be done piecemeal for pragmatic reasons.

Could someone please enlighten me on the functional
benefits of moving everything to /usr?
I can see the clean up benefits of splitting things by
mutability/persistence, with the proposed scheme being:

 /etc - non-shareable, can be read-only, host-only configuration
 /usr - shareable, can be read-only, package managed, binaries
 /var - non-shareable, writable, host-only state/data
 /run - temporary state

However the existing hierarchy can be quite easily adjusted.
For example I previously worked with a Fedora 14 system
on installations of up to 1000 systems that were organized like:

 /tmp     - temporary state (rw) (ram)
 /var     - host state (rw) (nfs)
 /etc/dev - device state³ (rw) (local disk/flash etc.)
 /...     - the rest¹ (ro²) (nfs)

¹ The rest was a single file system. I've never mounted
/usr as a separate file system anyway.

² Note there were a few places in the rest of the hierarchy
that needed to be bind mounted to the (rw) locations,
but they were minimal and encapsulated in /etc/statetab.d/blah
Also it seemed quite elegant in the case of /etc for example
to have all the config together, with only a couple of places
auto bind mounted to (rw).

³ Stuff like touchscreen calibration settings.

Also about snapshots. This is possible (better?) when
done from the source location. I.E. in my example above,
the (ro) nfs directory was easily copied or directed
to a new release directory.  For local systems the
equivalent would be doing a snapshot of the (ro) file system
at the file system level (like BTRFS supports), rather than
going down through the file hierarchy which seems inefficient
and racy.


More information about the devel mailing list