linux-ext4 - Re: Question on fallocate/ftruncate sequence

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] [thread-next>] [day] [month] [year] [list]

Message-ID: <4AC26630.6030509@redhat.com>
Date:	Tue, 29 Sep 2009 14:55:28 -0500
From:	Eric Sandeen <sandeen@...hat.com>
To:	Jiaying Zhang <jiayingz@...gle.com>
CC:	Andreas Dilger <adilger@....com>, Theodore Tso <tytso@....edu>,
	Frank Mayhar <fmayhar@...gle.com>,
	Curt Wohlgemuth <curtw@...gle.com>,
	ext4 development <linux-ext4@...r.kernel.org>
Subject: Re: Question on fallocate/ftruncate sequence

Jiaying Zhang wrote:
> On Tue, Sep 29, 2009 at 12:15 PM, Eric Sandeen <sandeen@...hat.com> wrote:
>> Jiaying Zhang wrote:
>>> Sorry for taking so long to finish this. Here is the new patch based on
>>> Andreas's suggestions. Now the patch clears the EXT4_EOFBLOCKS_FL
>>> flag when we allocate beyond the maximum allocated block. I also
>>> made the EOFBLOCKS flag user visible and added the handling
>>> in ext4_ioctl as Andrea suggested.
>> I was testing this a bit in xfstests, with test 083 (recently I sent a
>> patch to the xfs list to let that test run on generic filesystems) which
>> runs fsstress on a small-ish 100M fs, and that fsstress does space
>> preallocation (on newer kernels, where the older xfs ioctls are hooked
>> up to do_fallocate in a generic fashion).
> 
> Does the fsstress use fallocate with KEEP_SIZE?

Effectively, yes.   It uses the compatible xfs ioctls, which calls
do_fallocate with KEEP_SIZE.

>> I'm actually seeing more corruption w/ this patch than without it,
>> though I don't yet see why.  I'll double check that it applied properly,
>> since this was against 2.6.30.5....
> 
> Do you want me to port my changes to the latest ext4 git tree?
> I should have done so at the beginning.

Sure :)

>> Also it strikes me as a little odd to allow clearing of the EOF Flag
>> from userspace, and the subsequent discarding of the blocks past EOF.
>>
>> Doesn't truncating to i_size do exactly the same thing, in a more
>> portable way?  Why make a new interface unique to ext4?
> 
> As Andreas suggested, I think the main purpose is to allow users
> to scan for any files with EOF flag with the getflag ioctl. We may
> not allow users to clear it with the setflag ioctl but just rely on
> the truncate interface, but supporting the setflag ioctl interface
> doesn't seem to do any harm.

I like the idea of being able to find them, but adding the clearing
interface seems redundant to me.  All filesystems would need to
implement this, and I don't see that we gain anything.

Thanks,
-Eric

> Jiaying
--
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