All of lore.kernel.org
 help / color / mirror / Atom feed
From: Eric Sandeen <sandeen@redhat.com>
To: Jiaying Zhang <jiayingz@google.com>
Cc: "Theodore Ts'o" <tytso@mit.edu>,
	Ext4 Developers List <linux-ext4@vger.kernel.org>
Subject: Re: [PATCH -v2] ext4: use truncate_setsize() unconditionally
Date: Tue, 24 May 2011 17:31:23 -0500	[thread overview]
Message-ID: <4DDC31BB.6080406@redhat.com> (raw)
In-Reply-To: <BANLkTinAsaFUUEhren4pcyzBw=iyrs8r4w@mail.gmail.com>

On 5/24/11 5:06 PM, Jiaying Zhang wrote:
> On Tue, May 24, 2011 at 7:30 AM, Eric Sandeen <sandeen@redhat.com> wrote:
>> On 5/23/11 2:19 PM, Theodore Ts'o wrote:
>>> In commit c8d46e41 (ext4: Add flag to files with blocks intentionally
>>> past EOF), if the EOFBLOCKS_FL flag is set, we call ext4_truncate()
>>> before calling vmtruncate().  This caused any allocated but unwritten
>>> blocks created by calling fallocate() with the FALLOC_FL_KEEP_SIZE
>>> flag to be dropped.  This was done to make to make sure that
>>> EOFBLOCKS_FL would not be cleared while still leaving blocks past
>>> i_size allocated.  This was not necessary, since ext4_truncate()
>>> guarantees that blocks past i_size will be dropped, even in the case
>>> where truncate() has increased i_size before calling ext4_truncate().
>>>
>>> So fix this by removing the EOFBLOCKS_FL special case treatment in
>>> ext4_setattr().  In addition, use truncate_setsize() followed by a
>>> call to ext4_truncate() instead of using vmtruncate().  This is more
>>> efficient since it skips the call to inode_newsize_ok(), which has
>>> been checked already by inode_change_ok().  This is also in a win in
>>> the case where EOFBLOCKS_FL is set since it avoids calling
>>> ext4_truncate() twice.
>>>
>>> Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
>>> ---
>>>  Jiayingz pointed out that in the case where we fallocate 12k, write 4k, and
>>>  then truncate to 4k, we should discard the excess fallocate'd blocks.  So if
>>>  attr->ia_size == inode.i_size, we can skip the truncate_setsize() call, but
>>>  if the EOFBLOCKS_FL flag is set, we should still call ext4_truncate().
>>
>> are there xfstests which cover this explicitly?  It should be simple to write.
>>
> Vivek has written a xfstest to cover this and more fallocate/truncate cases:
> http://old.nabble.com/-PATCH--xfstests%3A-test-fallocate%2C-write%2C-ftruncate-combinations.-to31666685.html#a31666685

ah, right - ok, thanks!  Sorry for not keeping up.

-Eric

> Jiaying
> 
>> If filesystem behavior differs we can always make ext4-only tests.
>>
>> -Eric
>>


      reply	other threads:[~2011-05-24 22:31 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-05-17 22:59 [PATCH] ext4: use vmtruncate() instead of ext4_truncate() in ext4_setattr() Jiaying Zhang
2011-05-18  2:46 ` Yongqiang Yang
2011-05-18  2:56 ` Yongqiang Yang
2011-05-18  3:27   ` Yongqiang Yang
2011-05-18  3:19 ` Eric Sandeen
2011-05-18  5:35   ` Andreas Dilger
2011-05-18 20:32     ` Jiaying Zhang
2011-05-18 20:45       ` Andreas Dilger
2011-05-18 20:57         ` Jiaying Zhang
2011-05-18  6:13   ` Dave Chinner
2011-05-18 14:05     ` Eric Sandeen
2011-05-18 20:42     ` Jiaying Zhang
2011-05-18 20:29   ` Jiaying Zhang
     [not found]   ` <BANLkTi=Yv_q820aHFa2wkCL-PnYNcZdWCQ@mail.gmail.com>
2011-05-18 20:31     ` Eric Sandeen
2011-05-18 20:38       ` Jiaying Zhang
2011-05-22 23:56 ` Ted Ts'o
2011-05-23 18:30   ` Jiaying Zhang
2011-05-23 19:19     ` [PATCH -v2] ext4: use truncate_setsize() unconditionally Theodore Ts'o
2011-05-23 20:22       ` Jiaying Zhang
2011-05-24 14:30       ` Eric Sandeen
2011-05-24 22:06         ` Jiaying Zhang
2011-05-24 22:31           ` Eric Sandeen [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=4DDC31BB.6080406@redhat.com \
    --to=sandeen@redhat.com \
    --cc=jiayingz@google.com \
    --cc=linux-ext4@vger.kernel.org \
    --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 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.