On 30.09.2014 21:29, Darrick J. Wong wrote:
Huh. This looks like a normal deleted file... just to ensure we're sane,
what's the output of:
debugfs -R 'ls <7913865>' /dev/md2
7913865 (12) . 7913864 (12) .. 7912053 (20) bumpmap.la
7912054 (20) bumpmap.so 7912055 (20) colormod.la
7912056 (20) colormod.so 7912057 (24) testfilter.la
7912058 (3968) testfilter.so
debugfs -R 'ncheck 7913865' /dev/md2
Inode Pathname
7913865 /backup/atlas/usr/lib/x86_64-linux-gnu/imlib2/filters
Hoping 7913865 -> /ext/backup/atlas/usr/lib/x86_64-linux-gnu/imlib2/filters
It is.
By any chance did you save the e2fsck logs?
I'm afraid not. I was in single-user mode, it scrolled much. And later
the log in /var/log/fsck was overwritten with clean fsck run. :(
Always thought that history of fsck logs should be kept... something
like /var/log/syslog.
Digging through the e2fsck source code, the only way an inode gets marked used
is if i_link_count > 0 or ... badblocks thinks the inode table block is bad.
What does this say?
debugfs -R 'stat <1>' /dev/md2
Inode: 1 Type: bad type Mode: 0000 Flags: 0x0
Generation: 0 Version: 0x00000000
User: 0 Group: 0 Size: 0
File ACL: 0 Directory ACL: 0
Links: 0 Blockcount: 0
Fragment: Address: 0 Number: 0 Size: 0
ctime: 0x4ddb7efa -- Tue May 24 11:48:42 2011
atime: 0x4ddb7efa -- Tue May 24 11:48:42 2011
mtime: 0x4ddb7efa -- Tue May 24 11:48:42 2011
Size of extra inode fields: 0
BLOCKS:
Tried to delete that directory - impossible, i/o errors. I'll try to
reboot now to see if anything changes...
In theory we can use debugfs to clear the directory and then run e2fsck to
clean up, but let's sanity-check the world before we resort to that. :)
My thought exactly. Now that you reminded me that debugfs exists, I'm
pretty convinced I could just unlink one directory and one file with it,
run e2fsck and maybe be done. But, if you have any other ideas in the
meantime, let's test them first.
--
Zlatko
--
To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
