On Jan 14, 2014, at 10:37 PM, Dave Chinner <david@xxxxxxxxxxxxx> 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
Attachment:
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ xfs mailing list xfs@xxxxxxxxxxx http://oss.sgi.com/mailman/listinfo/xfs
