On 2018-10-05 12:32 a.m., L A Walsh wrote:

...

Some of the programs in /sbin don't seem to make sense and I was wondering why they had not been moved to /usr/sbin

... There are all sorts of arguments (and I realise, Linda, your anti-systemd proclivity might mean you don't subscribe to some of them) for the unification of /usr on /. That now seems to be common

On 10/5/2018 7:06 AM, Anton Aylward wrote: practice,

although, not I've mentioned it I'm sure people here will discuss it.

1) Just to be clear, I don't have an anti-systemd proclivity, though some of the personalities and practices associated with its development and adoption have left some things to be desired. I would prefer you not try create misconceptions about my "proclivities" whether they are accurate or not. My proclivities are generally irrelevant and subject to change several times a day depending on input. 2) if you read the /usrmerge page you'll find that /usr is intended to be on a separate partition from '/' allowing '/usr': (quotes from https://www.freedesktop.org/wiki/Software/systemd/TheCaseForTheUsrMerge/ ) * We can offer a ***read-only*** export of the vendor supplied OS to the network * The client hosts will then only need a minimal host-specific root filesystem with symlinks pointing into the shared /usr filesystem. Some questions/issues: * If the usr partition is to be used on other hosts, doesn't that imply at least, that 'mount' needs to be present and executable? The 2nd part of that, "executable", implies that the libraries needed to run mount must be part of the client's "Core OS", OR 'mount' needs to use static linkage (not the case in openSUSE tumbleweed relying on 10 linkables, 7 of which are in /usr/lib64 * Of course there are many utils/progs other than mount that need to be present on a 'Core OS' in order to boot * Some security conscious tools will not allow symlinks in the path leading to an executable; The only workaround I found for VirtualBox's distrust of symlinks was to put all of opt somewhere else (/home/opt) and mount that on /opt.

I can see why you might need RPC networking early on, so if you can demonstrate, very specifically, that need ...

True, but DNS, and network configuration are likely to be needed 1st. DNS isn't brought up till much later. Same with routing and firewall services. However, these rpc services need /usr/lib64 libraries. I don't see it being likely that /usr/lib64 will come up before /usr/sbin, so I don't see why you'd have rpc programs in /sbin that won't work until /usr/lib64 is mounted. I missed your reasoning for why you'd need a a binary that manages .info files in /sbin (vs. /usr/sbin), especially since it also requires libraries in /usr/lib64.

Of course you use XFS, don't you, Linda?

Not XFS from 2010. That was too slow. Also of note -- the standard linux scheduler 'CFQ' defeats all of the parallel operations of XFS, but of course you knew that right? There have been quite a few improvements for smal files since 2010. There's also quite a bit of work going in to support btrfs features in xfs to support deduplication and volume snapping. If the files occupy the same space I'd expect you'd get large I/O benefits, but haven't seen figures on that. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org