Re: random i/o error without error in dmesg

Szalma László
2015-10-28T08:45:11Z

Ok, I had a chance to try some things.

1.: the error

md5sum xyz
md5sum: xyz: Input/output error

(no any errors in dmesg)

2.: mount -o remount,ro /mnt/x

(could not do, it is used)
mysql stop && mount -o remount,ro /mnt/x
problem persists: io error.
mount -o remount,rw /mnt/x
still io error
umount /mnt/x
mount /mnt/x
NO io error, md5sum works!

The umount/mount ALWAYS solved the problem for me, mount -o remount,ro
was tried for the first time, but it was not enought. Reboot was not needed.
(kernel 4.2.4)

László Szalma

2015-10-27 07:23 keltezéssel, Duncan írta:
> Marc Joliet posted on Mon, 26 Oct 2015 15:23:39 +0100 as excerpted:
>
>> Occasionally they go away by themselves, but usually I have to reboot to
>> make them go away. This happens when getmail attempts to fetch mail,
>> which fails due to the above error. After the reboot getmail succeeds
>> again.
> Just out of curiosity, does a remount,ro, followed by a remount,rw, solve
> the problem?
>
> The ro/rw cycle should force anything in memory to device, so if that
> eliminates the problem, it could well be some sort of sync issue. If it
> doesn't, then it's more likely an in-memory filesystem state issue,
> that's cleared by the reboot.
>
> And if the ro/rw cycle doesn't clear the problem, what about a full
> unmount/mount cycle, at least of that subvolume?
>
> If you're running multiple subvolumes with root being one of them, you
> can't of course unmount the entire filesystem, but you could go down to
> emergency mode (systemctl emergency), try unmounting everything but /,
> mounting / ro, and then switching back to normal mode (from emergency
> mode, simply exiting should return you to normal multi-user or gui
> target, remounting filesystems as necessary, etc).
>
> IOW, does it take a full reboot to clear the problem, or is a simple ro/rw
> mount cycle enough, or an unmount/remount?
>
> 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.
>