My XFS filesystem dismounted while copying a ~3 GB file. I won’t claim to know
why; I’m fairly confident only that 1 file was being modified at the time. The
log replayed cleanly when remounting, but attempting to remove the file in
question caused the same dismount.
So I ran xfs_repair. It put one file in lost+found (which appears to be written
when if failed initially) and reported a number or warnings to the effect of:
bad hash table for directory inode 2054 (hash value mismatch):
rebuilding
rebuilding directory inode 2054
which I didn’t take to be serious, though I suspect now that’s where things
went wrong.
I now have 23 directories (matching the 23 “rebuilding" messages) where a file
or directory with non-ASCII characters in the name exists in the directory list
but cannot be read or deleted:
ls -la
ls: cannot access 07 - Señor Macho Solo.m4v: No such file or directory
-rw-rw----+ 1 profplump media 332M Sep 11 2010 06 - Christmas Special.m4v
??????????? ? ? ? ? ? 07 - Se??or Macho Solo.m4v
-rw-rw----+ 1 profplump media 304M Sep 11 2010 08 - Flu Shot.m4v
So the file exists in the directory listing (`ls` and `find` can both see it)
but I cannot delete or stat or open it. If I touch the affected filename I get
a second entry in the directory listing, both apparently pointing to the same,
new, empty file. If I then delete the same filename I get back to the original
state — a single, unusable directory entry.
I’d like to (if possible) re-link those directory listings to the related
files, or at least delete them so the files can be restored and folders can be
used normally. I’m also worried that running xfs_repair in the future might
re-create this problem.
But I don’t even know where to start in trying to fix this. And I still cannot
delete the file that started this whole sequence of events. So if anyone has
suggestions I’d be happy to hear them.
Zach
smime.p7s
Description: S/MIME cryptographic signature
|