All of lore.kernel.org
 help / color / mirror / Atom feed
From: Theodore Tso <tytso@mit.edu>
To: Valerie Clement <valerie.clement@bull.net>
Cc: linux-ext4@vger.kernel.org
Subject: Re: e2fsprogs: pu branch
Date: Mon, 28 Jan 2008 09:38:42 -0500	[thread overview]
Message-ID: <20080128143842.GA9881@mit.edu> (raw)
In-Reply-To: <1201278779.23187.7.camel@ext1.frec.bull.fr>

On Fri, Jan 25, 2008 at 05:32:59PM +0100, Valerie Clement wrote:
> Hi Ted,
> 
> Here are the problems I found when testing e2fsprogs built in the "pu"
> branch. I've checked that they haven't been fixed in the latest version.
> (git describe => v1.40.3-98-gb6fea68)
> 
> 1- "Corrupt extent header" report from e2fsck
>   =======================================================
> 
> Steps to reproduce it:
> Copy a regular file on the ext4 filesystem and make a symbolic links to it:
> # ln -s foo lnk
> Unmount fs.
> 
> # e2fsck -f /dev/sdc0
> e2fsck 1.40.3 (05-Dec-2007)
> Pass 1: Checking inodes, blocks, and sizes
> Error while reading over extent tree in inode 49105: Corrupt extent header
> Clear inode<y>

This is a kernel-level bug, actually.  The symlink is a "fast symlink"
where the target of the symlink is in inode itself.  The kernel level
code should *not* be setting the EXTENTS_FL flag.  Still, we'll have
to put in some code to work around it for people with current kernel
levels.

> 2- "EXT2 directory corrupted" report from debugfs
>   ===================================i===========
> When trying to debug the previous problem using debugfs: 
> 
> debugfs:  ncheck 49105
> ncheck: EXT2 directory corrupted while calling ext2_dir_iterate
> ncheck: EXT2 directory corrupted while calling ext2_dir_iterate
> ncheck: EXT2 directory corrupted while calling ext2_dir_iterate

Not all parts of the ext2 library have been fixed to understand
extents (in particular, ext2_dir_iterate).  On the todo list...

> 3- Strange "FILE SYSTEM WAS MODIFIED" report from e2fsck.
>   =======================================================
> 
> The test just creates an empty file so it is surprising that e2fsck modifies
> the filesystem. 
> I found the reason of this modification when reading the git logs, e2fsck
> backups the primary superblock to the backups when the feature sets are 
> different (EXT3_FEATURE_INCOMPAT_EXTENTS in that case).
> 
> It's not really a problem, it's just confusing. To see with other users,
> perhaps.

Yeah, we should add a explanatory message for that case.  Thanks for
pointing that out.

					- Ted

           reply	other threads:[~2008-01-28 14:38 UTC|newest]

Thread overview: expand[flat|nested]  mbox.gz  Atom feed
 [parent not found: <1201278779.23187.7.camel@ext1.frec.bull.fr>]

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=20080128143842.GA9881@mit.edu \
    --to=tytso@mit.edu \
    --cc=linux-ext4@vger.kernel.org \
    --cc=valerie.clement@bull.net \
    /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.