From: Zlatko Calusic <zcalusic@bitsync.net>
To: "Darrick J. Wong" <darrick.wong@oracle.com>
Cc: linux-ext4@vger.kernel.org
Subject: Re: e2fsck not fixing deleted inode referenced errors?
Date: Tue, 30 Sep 2014 22:10:04 +0200 [thread overview]
Message-ID: <542B0E1C.30800@bitsync.net> (raw)
In-Reply-To: <20140930192955.GB9942@birch.djwong.org>
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
next prev parent reply other threads:[~2014-09-30 20:10 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-09-30 17:56 e2fsck not fixing deleted inode referenced errors? Zlatko Calusic
2014-09-30 18:30 ` Darrick J. Wong
2014-09-30 18:43 ` Zlatko Calusic
2014-09-30 19:29 ` Darrick J. Wong
2014-09-30 20:10 ` Zlatko Calusic [this message]
2014-09-30 19:54 ` Theodore Ts'o
2014-09-30 20:27 ` Zlatko Calusic
2014-09-30 20:36 ` Darrick J. Wong
2014-09-30 21:34 ` Zlatko Calusic
2014-10-01 6:44 ` Zlatko Calusic
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=542B0E1C.30800@bitsync.net \
--to=zcalusic@bitsync.net \
--cc=darrick.wong@oracle.com \
--cc=linux-ext4@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.