On Jan 12, 2014, at 5:50 PM, Dave Chinner <david@xxxxxxxxxxxxx> wrote:
>> Attempts to access the now-busted files/directories with accents in their
>> paths result in a kernel log like:
>> Jan 11 02:05:39 vera XFS (dm-31): I/O error occurred: meta-data dev dm-31
>> block 0x3c8ff73e0 ("xfs_trans_read_buf") error 11 buf count 4096
> error 11 = EAGAIN/EWOULDBLOCK
> That tends to imply that there's some interesting error occurring in
> the layers below XFS here.
The error you note only started showing up *after* the xfs_repair, and only
when attempting to access the non-ascii file paths. It doesn’t take the
filesystem offline; other than those particular paths being inaccessible the
filesystem seems to be working correctly (though I’ve suspended user writes
until this is worked out). The affected paths are all around the disk, all
contain non-ascii characters in final portion of the path name, and do not
affect other paths in the same directory.
I can find a newer kernel to boot off and see how it behaves if you think it
would make any difference, but I’m pretty sure xfs_repair re-wrote the affected
directory entries and broke them as opposed to some sort of block-layer
corruption being responsible for breaking only these files.
Description: S/MIME cryptographic signature