Am Friday 13 May 2016 schrieb Duncan <1i5t5.dun...@cox.net> >Szalma László posted on Thu, 12 May 2016 20:28:24 +0200 as excerpted: >> The files that rarely become unreadable (I/O error but no error in dmesg >> or anywhere) are mysql MyIsam database files, and they are always small. >> Like 16kbyte for example, or smaller. Sometimes dropping the fs cache >> fixes the problem, sometimes not. Umount / mount always fixes the >> problem. Scrub says the filesystem is OK (when the file is unreadable). > >Is it possible the files are always under 4 KiB?
For the record, I was seeing a similar error with dovecot *.index.log files (see the ML thread started by Szalma László) . In my case they are *not* all under 4 KiB. Looking at some of the affected files, one of them is 25K, and another is 6.6K. However, perhaps they compress to under 4K? But compressing the 25K one with lzop only goes down to 5.6K with -9 :-/ . >While there's a few variables as to max size, with 4 KiB being the >practical max, btrfs will inline really small files into their metadata >node instead of writing them out as 4 KiB data block extents. Since >that's obviously a different code-path, if it's only 4 KiB and smaller >files, it's possible there's a race in that code-path that when lost, >results in the file "disappearing" without a dmesg trace, only to >reappear after reboot. > >Actually, now that I think about it, if the files are all OVER say 2 KiB >but still quite small, say under 16 KiB, and if they had just recently >grown, it's possible that the race is in the transition from the inline >metadata state to the multiples of 4 KiB block data extent state. > >And if all the files had just shrunk, say from compaction (if done in- >place, not with a copy and rename), perhaps it's the reverse, the >transition from written data blocks to inline metadata state. I'm glad somebody is (publicly) thinking about this :-) ! Greetings -- Marc Joliet -- "People who think they know everything really annoy those of us who know we don't" - Bjarne Stroustrup
signature.asc
Description: This is a digitally signed message part.
