From: Jeff Liu <jeff.liu@oracle.com>
To: Josef Bacik <jbacik@fusionio.com>
Cc: linux-btrfs@vger.kernel.org, linux-fsdevel@vger.kernel.org,
tytso@mit.edu, david@fromorbit.com
Subject: Re: [PATCH] btrfs: fix file truncation if FALLOC_FL_KEEP_SIZE is specified
Date: Fri, 28 Jun 2013 21:07:49 +0800 [thread overview]
Message-ID: <51CD8AA5.4050307@oracle.com> (raw)
In-Reply-To: <20130628124100.GU4288@localhost.localdomain>
On 06/28/2013 08:41 PM, Josef Bacik wrote:
> On Fri, Jun 28, 2013 at 01:15:52PM +0800, Jeff Liu wrote:
>> From: Jie Liu <jeff.liu@oracle.com>
>>
>> Create a small file and fallocate it to a big size with
>> FALLOC_FL_KEEP_SIZE option, then truncate it back to the
>> small size again, the disk free space is not changed back
>> in this case. i.e,
>>
>> # dd if=/dev/zero of=/mnt/test bs=512 count=1
>> # ls -l /mnt
>> total 4
>> -rw-r--r-- 1 root root 512 Jun 28 11:35 test
>>
>> # df -h
>> Filesystem Size Used Avail Use% Mounted on
>> ....
>> /dev/sdb1 8.0G 56K 7.2G 1% /mnt
>>
>> # xfs_io -c 'falloc -k 512 5G' /mnt/test
>> # ls -l /mnt/test
>> -rw-r--r-- 1 root root 512 Jun 28 11:35 /mnt/test
>>
>> # sync; df -h
>> Filesystem Size Used Avail Use% Mounted on
>> ....
>> /dev/sdb1 8.0G 5.1G 2.2G 70% /mnt
>>
>> # xfs_io -c 'truncate 512' /mnt/test
>> # sync; df -h
>> Filesystem Size Used Avail Use% Mounted on
>> ....
>> /dev/sdb1 8.0G 5.1G 2.2G 70% /mnt
>>
>> With this fix, the truncated up space is back as:
>> # sync; df -h
>> Filesystem Size Used Avail Use% Mounted on
>> ....
>> /dev/sdb1 8.0G 56K 7.2G 1% /mnt
>>
>> Signed-off-by: Jie Liu <jeff.liu@oracle.com>
>> ---
>> fs/btrfs/inode.c | 3 ---
>> 1 file changed, 3 deletions(-)
>>
>> diff --git a/fs/btrfs/inode.c b/fs/btrfs/inode.c
>> index 4f9d16b..7e1a5ff 100644
>> --- a/fs/btrfs/inode.c
>> +++ b/fs/btrfs/inode.c
>> @@ -4509,9 +4509,6 @@ static int btrfs_setsize(struct inode *inode, struct iattr *attr)
>> int mask = attr->ia_valid;
>> int ret;
>>
>> - if (newsize == oldsize)
>> - return 0;
>> -
>> /*
>> * The regular truncate() case without ATTR_CTIME and ATTR_MTIME is a
>> * special case where we need to update the times despite not having
>
> Cc'ing a few people on this since I'd like their opinion. Looking at other fs's
> it looks like ext4 does the same thing we do and would leave the prealloc'ed
> space, but it appears that xfs will truncate it. What do we think is the
> correct behavior? I'm inclined to take this patch, but I'd like to have an
> xfstest made for it so other file systems can be made to be consistent, and I'd
> like to make sure we all agree what is the correct behavior before we wander
> down that road. Thanks,
Looks Ext4 does the same thing to XFS in this case :), but OCFS2 does not.
I'd like to write a test case for xfstest if we reach an agreement.
Thanks,
-Jeff
next prev parent reply other threads:[~2013-06-28 13:07 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <51CD1C08.40801@oracle.com>
2013-06-28 12:41 ` [PATCH] btrfs: fix file truncation if FALLOC_FL_KEEP_SIZE is specified Josef Bacik
2013-06-28 13:07 ` Jeff Liu [this message]
2013-06-28 13:12 ` Josef Bacik
2013-06-29 2:22 ` Dave Chinner
2013-06-29 2:44 ` Jeff Liu
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=51CD8AA5.4050307@oracle.com \
--to=jeff.liu@oracle.com \
--cc=david@fromorbit.com \
--cc=jbacik@fusionio.com \
--cc=linux-btrfs@vger.kernel.org \
--cc=linux-fsdevel@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 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).