Re: random i/o error without error in dmesg

[Austin S Hemmelgarn <ahferroin7@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 3685 bytes --]

On 2015-10-28 01:21, Duncan wrote:
> Marc Joliet posted on Tue, 27 Oct 2015 21:54:40 +0100 as excerpted:
>
>>> IOW, does it take a full reboot to clear the problem, or is a simple
>>> ro/rw mount cycle enough, or an unmount/remount?
>>
>> Seems that a full reboot is needed, but I would expect that it would
>> have the same effect if I were to pivot back into the initramfs, unmount
>> / from there,
>> then boot back into the system.  Because quite frankly, I can't think of
>> any reason why a power cycle to the SSD should make a difference here.
>> I vaguely remember that systemd can do that, so I'll see if I can find
>> out how.
>
> Agree with both the systemd returning to the initr* point (which I
> actually had in mind while writing the above but don't remember the
> details either, so chose to omit in the interest of limiting the size of
> the reply and research necessary to generate it), and the ssd power-cycle
> point.
>
>>> Finally, assuming root itself isn't btrfs, if you have btrfs configured
>>> as a module, you could try unmounting all btrfs and then unloading the
>>> module, then reloading and remounting.  That should entirely clear all
>>> in-memory btrfs state, so if that doesn't solve the problem, while
>>> rebooting does, then the problem's very possibly outside of btrfs scope.
>>> Of course if root is btrfs, you can't really check that.
>>
>> Nope, btrfs is built-in (though it doesn't have to be, what with me
>> using an initramfs).
>
> Same here, also gentoo as I guess you know from previous exchanges.  But
> unfortunately, if your initr* is anything like mine, and your kernel
> monolithic as mine, making btrfs a module with a btrfs root isn't the
> easy thing it might seem to those who run ordinary distro supplied binary
> kernels with pretty much everything modularized, as doing so involves a
> whole new set of research on how to get that module properly included in
> the initr* and loaded there, as well as installing and building the whole
> module-handling infrastructure (modprobe and friends) again, as it's not
> actually installed on the system at all at this point, because with the
> kernel entirely monolithic, module-handling tools are unnecessary and
> thus just another unnecessary package to have to keep building updates
> for, if they remain installed.
FWIW, I'm pretty sure that genkernel-next (and possibly genkernel too at 
this point, but that's never had working userland support for BTRFS 
AFAICT) includes btrfs.ko and it's dependencies in any initr* it 
generates when it sees those modules on the system, although I'm not 
100% certain because I always build the driver for my root filesystem 
into the kernel directly.
>
[ snip ]
> What's left in the lib_user list after a dip to emergency mode, whether
> you've returned to multi-user mode or not, is often only systemd and
> perhaps its journald service, itself.  Journald can be restarted manually
> in the usual way (systemctl restart journald.service or whatever, I
> usually use tab completion so don't pay all that much attention to the
> specific name), if necessary, while systemd itself can be "reexecuted"
> using the systemctl daemon-reexec (tab-completion again) command.
Udev might also be listed (for some reason, a lot of distros don't stop 
it when going to emergency mode, I don't know about what Gentoo does in 
this case though because I don't use systemd), and at least the last 
time I checked, dropping to emergency mode on Debian and Fedora testing 
versions also keeps any dhcp clients or other stuff needed for 
maintaining the network connection running as well.



[-- Attachment #2: S/MIME Cryptographic Signature --]
[-- Type: application/pkcs7-signature, Size: 3019 bytes --]