Files with non-ASCII names inaccessible after xfs_repair

Zachary Kotlarek zach at kotlarek.com
Wed Jan 15 02:21:35 CST 2014


On Jan 14, 2014, at 10:37 PM, Dave Chinner <david at fromorbit.com> wrote:

> Sure. Can you write a patch to add explanation that explain the
> problem you've had?


Will do.


>> Theoretically I could find the expected hashvals and overwrite
>> them with xfs_db, right?
> 
> In theory, but hashvals need to be ordered correctly and that
> potentially means having to update btree node pointers and all sorts
> of other complexities. xfs_db is really not designed to rewrite
> directory structures manually.


It occurs to me the other way around is probably easier anyway — change the name entry to something ASCII-only (of the same byte length) and let xfs_repair rebuild the hash. That’s what got me into this mess, so by cartoon logic it should fix things if I do it again. ;-)

After testing that theory on a metadata dump I spun up an LVM snapshot, where it also seems to work. So that gets me back into a functional state, but given all the mucking I think I’ll restore a clean FS again anyway.

Thanks again for your help.

	Zach

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2749 bytes
Desc: not available
URL: <http://oss.sgi.com/pipermail/xfs/attachments/20140115/f9e9514f/attachment.p7s>


More information about the xfs mailing list