From: Ryoichi KATO <Ryoichi.Kato@jp.sony.com>
To: tytso@mit.edu
Cc: linux-ext4@vger.kernel.org, sct@redhat.com,
akpm@linux-foundation.org, adilger@clusterfs.com,
tim.bird@am.sony.com
Subject: Re: e2fsck bogus error report on orphan-list
Date: Fri, 20 Jul 2007 08:20:26 +0900 [thread overview]
Message-ID: <87fy3krnet.wl%ryoichi@me.sony.co.jp> (raw)
In-Reply-To: <20070719165510.GB14815@thunk.org>
At Thu, 19 Jul 2007 12:55:10 -0400,
Theodore Tso wrote:
> On Fri, Jul 20, 2007 at 12:39:19AM +0900, Ryoichi.Kato@jp.sony.com wrote:
> > Hi,
> > I hit a problem of ext3/e2fsck on orphan-list handling.
>
> Wow, I'm rather impressed that this was sufficient for a presentation
> at a conference. You could have just sent me e-mail. :-)
I know it's a rare case for most of the people and not sure
it is a 'bug', but I thought it might happen more offten for CE people.
So, I asked for opinions of CE people in a lighting session of
"CELF Technical Jamboree."
> > 1. Delete a file in an ext3 filesystem in early 1970
>
> Dare I ask *why* the system clock was set in the 1970's? Umm... don't
> do that.
As Tim pointed out, embedded devices offten omit RTC battery.
> > 2. Set RTC to 2007, and then mount/write the filesystem.
>
> There is code that detects when the time is set back in the 1970's
> (normally due to a bad clock battery) and thus disables this
> particular check. So it only triggers when the clock was previously
> bad, and is now good.
Actually, it's a *real* problem happend for my car navigation product.
Until GPS signal is available, it's clock was 1970.
And for servers and PCs, it's possible that RTC backup battery run out,
then clock get set correctly afterward by, say, NTP.
> The net is that the check is basically a sanity check to make any bugs
> in the orphaned list handling would be discovered, although it can
> also trigger if there is block device corruption where part of the
> inode table is corrupted. I had added hueristics that for most people
> meant that it never triggered, so I'm surprised that it actually did
> in your environment. Still, if it did, the easist thing to do is to
> just turn it off.
Now, after things behind the problem turned out, it's easy.
But let me point out that,
* It is very difficult to relate RTC to the problem.
No clue without digging into e2fsck source code.
* -p (preen) option of e2fsck doen't fix it automatically.
Though I'm not sure but, maybe it's safe to correct the
problem automatically?
Actually, it took me for several weeks to solve, because it is rare.
My system only reset RTC for hardware reset or when main battery run out
but not for software reset. But it can happen.
Thank you.
--
Ryoichi KATO <Ryoichi.Kato@jp.sony.com>
System Design Dept. No4
Audio Development & Engineering Div.
Sony Corporation Audio Business Group
Tel +81-3-3599-3862 / Fax +81-3-3599-3859
next prev parent reply other threads:[~2007-07-19 23:43 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-07-19 15:39 e2fsck bogus error report on orphan-list Ryoichi.Kato
2007-07-19 16:55 ` Theodore Tso
2007-07-19 21:05 ` Tim Bird
2007-07-19 23:20 ` Ryoichi KATO [this message]
2007-07-20 4:10 ` Theodore Tso
2007-07-20 9:45 ` Ryoichi KATO
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=87fy3krnet.wl%ryoichi@me.sony.co.jp \
--to=ryoichi.kato@jp.sony.com \
--cc=adilger@clusterfs.com \
--cc=akpm@linux-foundation.org \
--cc=linux-ext4@vger.kernel.org \
--cc=sct@redhat.com \
--cc=tim.bird@am.sony.com \
--cc=tytso@mit.edu \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox