Re: random i/o error without error in dmesg

[Duncan <1i5t5.duncan@cox.net>]

Marc Joliet posted on Thu, 29 Oct 2015 22:10:24 +0100 as excerpted:

>>Meanwhile, as explained in the systemd docs (specifically the systemd
>>for administrators series, IIRC), systemd dropping back to the initr* is
>>actually its way of automatically doing effectively the same thing we
>>were using lib_users and all those restarts to do, getting rid of all
>>possible still running on root executables, including systemd itself, by
>>reexecing systemd itself back in the initr*, as a way to help eliminate
>>*everything* running on root, so it can not only be remounted read-only,
>>but actually unmounted the same as any other filesystem, as userspace is
>>now actually running from the initr* once again.  That's a far *FAR*
>>safer reboot after upgrade than traditional sysvinit solutions were able
>>to do. =:^)
> 
> Yeah, the ability to do that is a nice plus of using an initramfs.
> Although I've never been clear on why it's *safer*.  Is it because the
> remount might fail?  Or are there other reasons, too?

While I don't claim anything but informed admin level authority on the 
problem...

It's first worth noting that the problem a return to initramfs helps 
solve is in practice reasonably rare and obscure, since if it weren't, 
people would have been experiencing it in serious numbers on sysvinit-
based systems all along, and something would have been done to solve it 
long before systemd came along.  So it's a relatively narrow issue that 
in practice can only affect a few users, a relatively small portion of 
the time.

>From my read of the systemd docs, it's more pointing out a theoretical 
issue than a practical one, pointing out that systemd is in fact a more 
theoretically correct solution to the (implicitly mostly theoretical) 
problem.

In that context, I believe the (mostly theoretical) point is as much that 
we were treating / (and perhaps another mount or two) special, remounting 
it read-only instead of unmounting it because in practice there wasn't 
any other choice, and that now that systemd offers the choice, it can in 
fact be treated just like any other filesystem, fully unmounting it 
before shutdown.

Since exceptions to rules are nice places for bugs to hide, in theory at 
least (the remount-ro root being such a universal exception that in 
practice it's a rule of its own, and bugs couldn't long hide in that 
exception /because/ of its universalness), being able to treat / like any 
other filesystem and unmount it is a "purer and more correct" solution.

IOW, it's a nice counter to the "systemd isn't unixy enough" point, as 
here, it's more "unixy" than sysvinit ever was.

That said, I expect that over the years there have been plenty of 
otherwise nice implementations of various useful things that ran into a 
shutdown/reboot-time problem due to root's remount-ro exception, that 
either limited them to non-root-filesystem deployment or sent them back 
for a workaround, if not causing them to rejected outright as unworkable, 
that in this new return-to-initr*-and-unmount-root environment will see 
faster deployment without the workarounds that heretofore were required.  
Of course that'll end up being a limitation on deployment on non-initr* 
direct-to-root boot sequences, but in this primarily prebuild binary 
distro with prebuild by-necessity-modular-kernel-and-initr* environment, 
that's unlikely to slow down wide deployment by much, and anyone wanting 
to do direct-to-root boots and/or non-systemd-based deployments will just 
have to find their own workarounds, which may ultimately be incorporated 
into upstream, or not, depending on upstream's whims.

Which, bringing it all back to the btrfs list title topic, is already 
where multi-device btrfs as / filesystem is in terms of initr*, since 
that's basically broken without an initr* to assemble it.  And of course 
the same thing goes for / on LVM, since it too requires userspace to 
activate, which means initr* if / is on it.

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman