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.
Zach
Attachment:
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ xfs mailing list xfs@xxxxxxxxxxx http://oss.sgi.com/mailman/listinfo/xfs
