[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-ID: <873azkl7x4.wl%ryoichi@me.sony.co.jp>
Date: Fri, 20 Jul 2007 00:39:19 +0900
From: Ryoichi.Kato@...sony.com
To: linux-ext4@...r.kernel.org, tytso@...nk.org
Cc: sct@...hat.com, akpm@...ux-foundation.org, adilger@...sterfs.com,
Tim Bird <tim.bird@...sony.com>
Subject: e2fsck bogus error report on orphan-list
Hi,
I hit a problem of ext3/e2fsck on orphan-list handling.
The following sequence produces bogus e2fsck error report:
"/dev/XXX: Inodes that were part of a corrupted orphan linked list found."
1. Delete a file in an ext3 filesystem in early 1970
2. Set RTC to 2007, and then mount/write the filesystem.
3. Run e2fsck (with -f)
This is because i_dtime (deletion time) field is also used as a
next-pointer of an orphan-list (stores inode number rather than time),
and e2fsck handles it improperly.
You will have the same probrem if you run e2fsck on an ext3
filesystem with 1.2+ billion of files in it. (Is it possible?)
For more detail, please take a look at a document I wrote:
- http://tree.celinuxforum.org/CelfPubWiki/Ext3OrphanedInodeProblem
- http://tree.celinuxforum.org/CelfPubWiki/JapanTechnicalJamboree15?action=AttachFile&do=get&target=ext3orphaned-inode.ppt (Sorry for .PPT)
So, my questions are:
*Is this really a bug (or design defect) ?
*Which of ext3 or e2fsck is responsible for the problem?
- I feel that e2fsck is. But needs help of ext3 to solve it elegantly.
*How should I(we) deal with this problem.
- As a work-around, it's avoidable by just set RTC
to 2007 or so before doing any ext3 operation.
Thank you.
--
Ryoichi KATO <Ryoichi.Kato@...sony.com>
Audio Development & Engineering Div.
Sony Corporation Audio Business Group
Tel +81-3-3599-3862 / Fax +81-3-3599-3859
--
Ryoichi KATO <Ryoichi.Kato@...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
-
To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists