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: <20090828221432.GS4197@webber.adilger.int>
Date:	Fri, 28 Aug 2009 16:14:32 -0600
From:	Andreas Dilger <adilger@....com>
To:	Jiaying Zhang <jiayingz@...gle.com>
Cc:	Frank Mayhar <fmayhar@...gle.com>,
	Eric Sandeen <sandeen@...hat.com>,
	Curt Wohlgemuth <curtw@...gle.com>,
	ext4 development <linux-ext4@...r.kernel.org>
Subject: Re: Question on fallocate/ftruncate sequence

On Aug 28, 2009  14:44 -0700, Jiaying Zhang wrote:
> On Fri, Aug 28, 2009 at 12:40 PM, Andreas Dilger<adilger@....com> wrote:
> > This isn't really correct, however, because i_blocks also contains
> > non-data blocks (indirect/index, EA, etc) blocks, so even with small
> > files with ACLs i_blocks may always be larger than ia_size >> 9, and
> > for ext2/3 at least this will ALWAYS be true for files > 48kB in size.
> 
> I see. I guess we need to use a special flag then. Or is there any
> other suggestions? I also have another question related to this
> problem. Why those fallocated blocks are not marked as preallocated
> blocks that will then be automatically freed in ext4_release_file?

Because fallocate() means "persistent allocation on disk", not "in memory
preallocation".  The "in memory" preallocation already happens in ext4,
and it is released when the inode is cleaned up.

Cheers, Andreas
--
Andreas Dilger
Sr. Staff Engineer, Lustre Group
Sun Microsystems of Canada, Inc.

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