linux-ext4 - Re: [PATCH] ext4: use vmtruncate() instead of ext4_truncate() in ext4

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <BANLkTi=-mHcK529AC=s3aVfEEjoF7Rx-rg@mail.gmail.com>
Date:	Wed, 18 May 2011 13:38:20 -0700
From:	Jiaying Zhang <jiayingz@...gle.com>
To:	Eric Sandeen <sandeen@...hat.com>
Cc:	tytso@....edu, linux-ext4@...r.kernel.org
Subject: Re: [PATCH] ext4: use vmtruncate() instead of ext4_truncate() in ext4_setattr()

On Wed, May 18, 2011 at 1:31 PM, Eric Sandeen <sandeen@...hat.com> wrote:
> On 5/18/11 3:28 PM, Jiaying Zhang wrote:
>>
>>
>> On Tue, May 17, 2011 at 8:19 PM, Eric Sandeen <sandeen@...hat.com <mailto:sandeen@...hat.com>> wrote:
>>
>>     On 5/17/11 5:59 PM, Jiaying Zhang wrote:
>>     > There is a bug in commit c8d46e41 "ext4: Add flag to files with blocks
>>     > intentionally past EOF" that if we fallocate a file with FALLOC_FL_KEEP_SIZE
>>     > flag and then ftruncate the file to a size larger than the file's i_size,
>>     > any allocated but unwritten blocks will be freed but the file size is set
>>     > to the size that ftruncate specifies.
>>     >
>>     > Here is a simple test to reproduce the problem:
>>     >   1. fallocate a 12k size file with KEEP_SIZE flag
>>     >   2. write the first 4k
>>     >   3. ftruncate the file to 8k
>>     > Then 'ls -l' shows that the i_size of the file becomes 8k but debugfs
>>     > shows the file has only the first written block left.
>>
>>     To be honest I'm not 100% certain what the fiesystem -should- do in this case.
>>
>>     If I go through that same sequence on xfs, I get 4k written / 8k unwritten:
>>
>>     # xfs_bmap -vp testfile
>>     testfile:
>>      EXT: FILE-OFFSET      BLOCK-RANGE            AG AG-OFFSET              TOTAL FLAGS
>>       0: [0..7]:          2648750760..2648750767  3 (356066400..356066407)     8 00000
>>       1: [8..23]:         2648750768..2648750783  3 (356066408..356066423)    16 10000
>>
>>     size 8k:
>>     # ls -l testfile
>>     -rw-r--r-- 1 root root 8192 May 17 22:33 testfile
>>
>>     and diskspace used 12k:
>>     # du -hc testfile
>>     12K     testfile
>>     12K     total
>>
>>     I think this is a different result from ext4, either with or without your patch.
>>
>>     On ext4 I get size 8k, but only the first 4k mapped, as you say.
>>
>> I agree that truncating to a size larger than i_size is un-specified by
>> POSIX. However, I think the problem with the current behavior is that
>> we have an inconsistency between file's i_size and its extent tree.
>> Now we have 8k i_size but the file has only 4k space allocated. That
>> can confuse applications.
>
> That's called "a sparse file" right?  Apps should not be confused by that ...
But applications don't intend to create a sparse file in this case. They may
create a lot of such files in this way with 'df' showing there is
still plenty of
free space available but as they start writing to these files they will fill up
space and get ENOSPC unexpectedly.

Jiaying
>
> -Eric
>
--
To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html