On Tue, Jan 14, 2014 at 05:59:23PM -0800, Zachary Kotlarek wrote:
>
> On Jan 14, 2014, at 5:53 PM, Dave Chinner <david@xxxxxxxxxxxxx> 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@xxxxxxxxxxxxx
_______________________________________________
xfs mailing list
xfs@xxxxxxxxxxx
http://oss.sgi.com/mailman/listinfo/xfs
