Re: systemd woes continue
On Wed, Jul 17, 2019 at 01:45:21PM +0000, Witold Baryluk wrote:
> Hey John,
>
> > The gist is: A lot of projects don't test their code on systems with
> separate
> > /usr partitions anymore, so things get silently broken.
>
> I don't have separate /usr, just single / (ext4) partition, and just
> separate /boot (ext2), and still systemd fails to mount this /boot file
> system, similar to Michael issue. So, I dont think it is really related to
> separate /usr vs non separate /usr.
>
> PS. On my amd64 system with systemd, I do have separate /usr, and it does
> work.
Recall my original statement of the issue. Separate "/usr" is ok.
Other persistent filesystems, say, "/boot", do *not* work. This is
consistent with what the rest of us are seeing who have run into this
problem with "systemd". I agree with the assertion/speculation that
what we're seeing shouldn't be unique to Alpha, and I don't think it is.
The "everything on /" default partitioning scheme is sensible for people
new to UN*X who simply want to get Linux up and running as quickly and
easily as possible. For people with a little bit of experience and a
sense of historical perspective, separate persistent filesystems are the
way to go. Most of the "heavy" disk I/O is associated with directories
like "/tmp" and "/var", not to mention swap partitions. "/tmp" is non-
persistent in modern distros, so we'll ignore it for now. On the other
hand, "/var" sees quite a bit of disk I/O (software updates, spooling,
e-mail, etc.), and it makes sense for "/var" to be on a separate
partition so that *when* a crash occurs, the resulting filesystem
corruption won't affect "/".
Other persistent filesystems are a matter of individual
taste/preference, but in general, the idea is to distinguish between
those parts of the directory hierarchy that are relatively stable vs.
those that are likely to see a lot of writing. Modern filesystems
aren't as likely to be unrecoverable after a crash, so we can get away
with a monolithic "everything on /" philosophy. That wasn't always the
case, and old fossils like me that got burned decades ago haven't
forgotten the lessons that were learned the hard way :-(. Another
consideration is that disks used to be much smaller, and multiple
persistent partitions were pretty much a forced choice, i.e., you
couldn't put everything on a single spindle, and there was no way to
construct a large logical volume out of multiple smaller physical ones
as we can do today. The standard hard disks available for a DEC PWS
when that system first hit the market would certainly have required
either separate persistent filesystems or logical volume capability
to be useful. At the time I first installed Linux on an Alpha, I think
only RedHat was using LVM by default (although they no longer supported
Alpha at that point), and I can't remember whether anyone else's
installer even offered it as an option.
In summary, I guess I'm saying there are valid reasons in 2019 for
having multiple persistent fiiesystems, even with large physical disks
and the ability to create large logical volumes out of multiple smaller
ones.
--Bob
Reply to: