Re: random i/o error without error in dmesg

[Marc Joliet <marcec@gmx.de>]

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

Am Friday 22 April 2016
schrieb Marc Joliet <marcec@gmx.de>

>Hi
>
>FWIW, this sounds like what I've been seeing with dovecot.  In case it's
>relevant, I'll try to explain.
>
>After some uptime, I'll see log messages like this:
>
>Okt 26 12:05:46 thetick dovecot[467]: imap(marcec): Error: pread() failed
>with file /home/marcec/.mdbox/mailboxes/BTRFS/dbox-Mails/dovecot.index.log:
>Input/output error
>
>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.
>
>As in Szalma's case, btrfs-scrub never reports anything wrong.

FWIW, this still happens.  I tried various things, in order:

- set mmap_disable=yes (as mentioned in [0] and [1]),
- stop mounting with compress=lzo, and
- upgrade dovecot 2.2.19 to 2.2.23,

none of which helped.

I found very little on the web: [0] (in German) is fairly recent, but the 
error apparently just went away.  [1] is pretty old (2007) and the reporter 
was using unionfs.  I also found a russian forum entry [2], which relates to 
btrfs again, but if Google Translate is accurate enough, the user "solved" the 
problem by using XFS instead.

My current attempt is to use the maildir mailbox format (instead of mdbox) in 
the hope that it doesn't trigger this bug, while reverting the changes above 
(except for the dovecot upgrade).  It's "just" a home server, so I don't 
expect any major differences in performance (also since KMail probably uses 
akonadi for searching).

[...]
>Anyway, the current state of the system is:
>
># uname -r
>4.1.9-gentoo-r1
># btrfs filesystem show /
>Label: 'MARCEC_ROOT'  uuid: 0267d8b3-a074-460a-832d-5d5fd36bae64
>        Total devices 1 FS bytes used 74.40GiB
>        devid    1 size 107.79GiB used 105.97GiB path /dev/sda1
>
>btrfs-progs v4.2.2
># btrfs filesystem df /
>Data, single: total=98.94GiB, used=72.30GiB
>System, single: total=32.00MiB, used=20.00KiB
>Metadata, single: total=7.00GiB, used=2.10GiB
>GlobalReserve, single: total=512.00MiB, used=0.00B
>
>The filesystem is mounted as (leaving out subvolume mounts which use the same
>mount options):
>/dev/sda1 on / type btrfs (rw,noatime,compress=lzo,ssd,discard,space_cache)

I have since obtained an old Mac Mini and have been using it as a home server 
since early April, onto which I moved dovecot (using doveadm-sync(1)).  Its 
current state is:

diefledermaus etc # uname -r
4.4.8-gentoo
diefledermaus etc # btrfs --version
btrfs-progs v4.5.1
diefledermaus etc # btrfs fi show
Label: 'MACROOT'  uuid: 8b2b0242-5816-4529-9e88-6c82ffff2eaf
        Total devices 1 FS bytes used 12.29GiB
        devid    1 size 251.20GiB used 15.09GiB path /dev/sda3

Label: 'MARCEC_BACKUP'  uuid: f97b3cda-15e8-418b-bb9b-235391ef2a38
        Total devices 1 FS bytes used 797.14GiB
        devid    1 size 976.56GiB used 819.12GiB path /dev/sdb2

diefledermaus etc # btrfs fi df /
Data, single: total=12.01GiB, used=11.38GiB
System, DUP: total=40.00MiB, used=16.00KiB
Metadata, DUP: total=1.50GiB, used=926.77MiB
GlobalReserve, single: total=288.00MiB, used=0.00B
diefledermaus etc # mount | grep root
/dev/sda3 on / type btrfs 
(rw,noatime,compress=lzo,space_cache,autodefrag,subvolid=257,subvol=/rootfs)
/dev/sda3 on /mnt/rootfs type btrfs 
(rw,noatime,compress=lzo,space_cache,autodefrag,subvolid=5,subvol=/)

Note that the file system was *freshly* created using btrfs-progs 4.3.1 and 
gentoo-sources 4.1.15-r1 (the current stable versions in Gentoo; -r1 is a 
Gentoo-specific revision number).

References:

[0] https://debianforum.de/forum/viewtopic.php?f=27&t=157374
[1] http://www.dovecot.org/list/dovecot/2007-November/026551.html
[2] https://www.linux.org.ru/forum/general/11598803

-----------------------------------------------------------

I'd like to add that dovecot is the *only* software I use that has this sort 
of problem with btrfs -- and it's *only* the transaction *.log files; the few 
times the index files had problems, they were automatically fixed.  However, 
once the problem shows up, no other software can read the files, either (e.g., 
cat fails).  Furthermore, restarting dovecot doesn't help, only rebooting, 
i.e., unmounting the entire file system, not just the subvolume the mailbox 
resides on (as discussed previously in this sub-thread).  So I'm not sure 
what, exactly, is at fault here: dovecot, btrfs, or both?

So given all the above, does anybody have any further suggestions on how to 
proceed?  Because regardless of whether the switch to maildir ends up 
resolving the issue for me, something is going wrong.  I'm thinking of filing 
a bug report with dovecot; perhaps none of their devs test with btrfs?

Greetings
-- 
Marc Joliet
--
"People who think they know everything really annoy those of us who know we
don't" - Bjarne Stroustrup

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 819 bytes --]