On Jan 14, 2014, at 7:48 PM, Dave Chinner <david@xxxxxxxxxxxxx> wrote: > 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. Okay. Thanks for the explanation. FWIW, I read “ASCII-only case-insensitive” to mean “only case-insensitive for ASCII” as in ñ and Ñ would not match each other. If it actually means “anything other than ASCII is subject to complete breakage” a more nuanced explanation in the man page might be desirable. I don’t suppose there’s any way to disable that setting short of creating a new file system? > 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. Neither this: LC_ALL=C nor this: LC_ALL=POSIX or for that matter: LC_ALL=en_US.utf8 made any difference. And my default was already POSIX. Any other thoughts? Theoretically I could find the expected hashvals and overwrite them with xfs_db, right? Or at least unlink the files so I can reclaim the disk space? Zach
Attachment:
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ xfs mailing list xfs@xxxxxxxxxxx http://oss.sgi.com/mailman/listinfo/xfs
