linux-ext4.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Jan Kara <jack@suse.cz>
To: Andreas Dilger <adilger.kernel@dilger.ca>
Cc: Jan Kara <jack@suse.cz>,
	Masayoshi MIZUMA <m.mizuma@jp.fujitsu.com>,
	Andrew Morton <akpm@linux-foundation.org>,
	linux-ext4 <linux-ext4@vger.kernel.org>
Subject: Re: [PATCH] [RESEND] ext3: set i_extra_isize of 11th inode
Date: Thu, 9 Sep 2010 18:38:08 +0200	[thread overview]
Message-ID: <20100909163807.GA3281@quack.suse.cz> (raw)
In-Reply-To: <608119C2-BE41-4BC1-AAA3-A215C06720FE@dilger.ca>

On Fri 27-08-10 12:57:47, Andreas Dilger wrote:
> On 2010-08-27, at 07:58, Jan Kara wrote:
> >  first let me explain one thing: I definitely agree that the issue
> > spotted by Masayoshi MIZUMA is more serious than some possible problem
> > with ancient e2fsprogs. What I was discussing about is, whether we should
> > fix the issue with the original patch (removing the workaround from
> > ext3_iget) or with my patch (putting the same logic into ext3_new_inode so
> > that it does not create xattrs which ext3_iget will just ignore).
> 
> I agree that this is a safe fix, but it will propagate the workaround far
> into the future instead of actually fixing it.
> 
> >  The disadvantage of my fix is that xattrs for inos <= EXT3_FIRST_INO will
> > be always stored out of inode, the disadvantage of the original patch is
> > the remote possibility of problems with ancient e2fsprogs.
> 
> I don't think there are realistic chances of problems with older
> filesystems running newer kernels.  I think the workaround that was
> suggested below is also totally safe - instead of silently erasing the
> xattr (as kernels do today), or returning an error with a bad
> i_extra_isize (as would happen with the originally proposed patch) it
> will "know" that this bad value on low-numbered inodes was caused by
> mke2fs and just reset it instead of returning the error.
  Sigh, sorry to bring this up again... I wanted to use the original patch
with the workaround you suggested but realized there's still a hole. The
new patched kernel will happily use extra inode space for xattrs for inode
11 but if you mount the filesystem with older kernel it will reset
i_extra_size to zero and thus you'll lose the stored xattrs.
  So to get out of this compatibility trap we'd have to accept xattrs in
the extended inode space but never store it there and after a sufficiently
long time, we could remove the workaround. But this seems not worth the
effort to me given we speak about a single inode and rather trivial
workaround in ext3_iget and ext3_new_inode.
  Any ideas Andreas?

									Honza
-- 
Jan Kara <jack@suse.cz>
SUSE Labs, CR

  reply	other threads:[~2010-09-09 16:38 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-08-20  2:20 [PATCH] ext3: set i_extra_isize of 11th inode Masayoshi MIZUMA
2010-08-20  7:42 ` Andreas Dilger
2010-08-23  0:16   ` Masayoshi MIZUMA
2010-08-23  0:50     ` [PATCH] [RESEND] " Masayoshi MIZUMA
2010-08-24 13:17       ` Jan Kara
2010-08-25  0:05         ` Masayoshi MIZUMA
2010-08-25 23:04           ` Jan Kara
2010-08-25 23:39             ` Andreas Dilger
2010-08-26  0:36               ` Ted Ts'o
2010-08-26  0:55                 ` Andreas Dilger
2010-08-26  1:21                   ` Ted Ts'o
2010-08-26  1:51                     ` Andreas Dilger
2010-08-26  1:25                   ` Masayoshi MIZUMA
2010-08-26 12:27               ` Jan Kara
2010-08-26 23:59                 ` Andreas Dilger
2010-08-27 13:58                   ` Jan Kara
2010-08-27 18:57                     ` Andreas Dilger
2010-09-09 16:38                       ` Jan Kara [this message]
2010-09-09 19:23                         ` Andreas Dilger
2010-08-26  0:26             ` Masayoshi MIZUMA
2010-08-26 12:29               ` Jan Kara

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=20100909163807.GA3281@quack.suse.cz \
    --to=jack@suse.cz \
    --cc=adilger.kernel@dilger.ca \
    --cc=akpm@linux-foundation.org \
    --cc=linux-ext4@vger.kernel.org \
    --cc=m.mizuma@jp.fujitsu.com \
    /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;
as well as URLs for NNTP newsgroup(s).