Files with non-ASCII names inaccessible after xfs_repair

[Dave Chinner]

On Tue, Jan 14, 2014 at 05:59:23PM -0800, Zachary Kotlarek wrote:
> 
> On Jan 14, 2014, at 5:53 PM, Dave Chinner <david at fromorbit.com> wrote:
> 
> > Pretty simple - the leaf[].address is simply a compressed offset
> > into the leaf. all dirents are 8 byte aligned, and the tag is the
> > byte offset into the leaf dirent space. Hence:
> > 
> > 	leaf[].address = bu[16].tag >> 3
> > 			= 0x1d8 >> 3
> > 			= 0x3b
> > 			= bleaf[3].address
> > 
> >> bleaf[3].hashval = 0x16d0707c
> >> bleaf[3].address = 0x3b
> > 
> > And there were are - there's a single bit discrepancy in the lower
> > byte of the hash. That tends to imply we have a bug in xfs_repair.
> > 
> > What version of xfs_repair did you use? (xfs_repair -V)
> 
> 
> 3.1.11.

OK, Now I've looked at the code, the answer is easy and you're
probably not going to like it. I missed this the first time through
from your xfs-info output:

naming   =version 2              bsize=4096   ascii-ci=1
                                              ^^^^^^^^^^

It's called *ASCII* Case Insensitivity for a reason: it doesn't
support anything other than ASCII. So your usage is not actually
supported at all, hence it's no surprise that it has caused
breakage.

Internationalised UTF-8 character sets are not supported
because it causes case conversion issues when kernel and userspace
character sets don't match exactly. IOWs, to support UTF-8 case
insensitivity, we need to have on-disk translation tables so that
the kernel and userspace use the same case translations. See here:

http://xfs.org/index.php/Unfinished_work#Support_for_unicode_.2F_utf8_filesystems

I suspect that the way to fix your filesystem is to run xfs_repair
under a "C" locale so that the glibc tolower() function behaves the
same way the kernel behaves and so the hashes calculated by
xfs_repair match the what the kernel thinks is correct.

Cheers,

Dave.
-- 
Dave Chinner
david at fromorbit.com