From: Jan Kara <jack@suse.cz>
To: Eric Sandeen <sandeen@redhat.com>
Cc: linux-kernel@vger.kernel.org
Subject: Re: [PATCH 0/6] UDF cleanup and fixes
Date: Wed, 23 May 2007 09:45:57 +0200 [thread overview]
Message-ID: <20070523074557.GA20625@duck.suse.cz> (raw)
In-Reply-To: <46535503.4020702@redhat.com>
On Tue 22-05-07 15:39:31, Eric Sandeen wrote:
> Eric Sandeen wrote:
>
> > Jan -
> >
> > I ran 2.6.21 + your udf patches from -mm through some udf tests which,
> > oddly enough, can be found in the xfstests test suite in xfsprogs cvs
> > from sgi.
> >
> > It looks much better than before, but I was able to trip some of your
> > asserts. They were generated while fsx was running. The good news,
> > though, is that fsx passed. :) I haven't looked into it much further
> > yet, but wanted to let you know.
>
> Here's a short hacky testcase that trips the assert around line 123 of
> udf/truncate.c I'm looking into it but you may immediately see what the
> problem is...?
Yes, yesterday I've also managed to create a simple testcase - sorry for
not letting you know, I'd have saved you some time. I also know what the
problem is:
1) discard_prealloc() shouldn't be called from udf_clear_inode() - at
that point inode won't be written any more and thus changes to it won't be
reflected. Actually, this bug is hidden by the fact that UDF calls
discard_prealloc() on each filp release but anyway.
2) the second problem is extent rounding - when we discard prealloc we
also truncate the extent to match i_size. That is fine but if the buffer
remains in pagecache and is reused on second open, block_prepare_write()
won't call udf_get_block() (as the buffer is already mapped) and thus the
extent remains truncated even though we write after it's end. The easiest
way out would be to simply leave the extent length rounded to block
boundary but I have to check with the specification whether this is
allowed...
Honza
--
Jan Kara <jack@suse.cz>
SuSE CR Labs
prev parent reply other threads:[~2007-05-23 7:34 UTC|newest]
Thread overview: 27+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-03-06 16:44 Jan Kara
2007-03-06 16:46 ` [PATCH 1/6] " Jan Kara
2007-03-07 9:37 ` Christoph Hellwig
2007-03-06 16:46 ` [PATCH 2/6] " Jan Kara
2007-03-07 9:37 ` Christoph Hellwig
2007-03-06 16:47 ` [PATCH 3/6] " Jan Kara
2007-03-07 9:38 ` Christoph Hellwig
2007-03-06 16:47 ` [PATCH 4/6] " Jan Kara
2007-03-07 9:38 ` Christoph Hellwig
2007-03-06 16:48 ` [PATCH 5/6] " Jan Kara
2007-03-07 9:38 ` Christoph Hellwig
2007-03-06 16:48 ` [PATCH 6/6] " Jan Kara
2007-03-07 9:38 ` Christoph Hellwig
2007-03-30 4:59 ` [PATCH 0/6] " Tino Keitel
2007-03-30 18:06 ` Chuck Ebbert
2007-03-31 9:46 ` Tino Keitel
2007-04-02 14:48 ` Chuck Ebbert
2007-04-04 6:36 ` Tino Keitel
2007-04-12 16:01 ` Jan Kara
2007-04-12 15:59 ` Tino Keitel
2007-04-16 15:23 ` Jan Kara
2007-04-02 12:54 ` Jan Kara
2007-04-02 13:54 ` Jan Kara
2007-04-27 21:54 ` Eric Sandeen
2007-05-03 15:13 ` Jan Kara
2007-05-22 20:39 ` Eric Sandeen
2007-05-23 7:45 ` Jan Kara [this message]
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=20070523074557.GA20625@duck.suse.cz \
--to=jack@suse.cz \
--cc=linux-kernel@vger.kernel.org \
--cc=sandeen@redhat.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
all inboxes | Powered by JetHome®