linux-ext4 - Re: fallocate support for bitmap-based files

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]

Date:	Fri, 06 Jul 2007 14:15:44 -0700
From:	Mike Waychison <mikew@...gle.com>
To:	Valerie Henson <val@....edu>
CC:	Andrew Morton <akpm@...ux-foundation.org>,
	Theodore Tso <tytso@....edu>,
	Andreas Dilger <adilger@...sterfs.com>,
	Sreenivasa Busam <sreenivasac@...gle.com>,
	"linux-ext4@...r.kernel.org" <linux-ext4@...r.kernel.org>,
	Mingming Cao <cmm@...ibm.com>
Subject: Re: fallocate support for bitmap-based files

Valerie Henson wrote:
> On Fri, Jun 29, 2007 at 06:07:25PM -0400, Mike Waychison wrote:
>> Relying on (a tweaked) reservations code is also somewhat limitting at 
>> this stage given that reservations are lost on close(fd).  Unless we 
>> change the lifetime of the reservations (maybe for the lifetime of the 
>> in-core inode?), crank up the reservation sizes and deal with the 
>> overcommit issues, I can't think of any better way at this time to deal 
>> with the problem.
> 
> While I never ever intended the ext3-to-ext2 reservations port to be
> used :), I think you can make some fairly minor tweaks to it and get
> something that works for your use case.  Move the reservation drop to
> iput() and turn up your inode cache size, or store it in a tree when
> the inode is closed and go look for it again when it's reopened.
> Changing the reservation size seems fairly easy.  I'm not sure how the
> overcommit issues affect your use case; any data you can share on
> that?

The overcommit is speculation on my part.  GFS uses a lot of files on 
the disks and we like to keep the disks near full, especially in large 
GFS configurations.  If we end up with a lot of reservations in-core, 
associated with the inode cache, we begin to rely on memory pressure for 
getting the reserved blocks back.  That memory pressure may not exist 
(leading to ENOSPC).  Unless the code is adapted to cull reservations in 
that case.

> 
> In any case, storing the reservation data on-disk seems like not such
> a great idea.  It adds complexity, disk traffic, and a new set of
> checks for fsck.  I wouldn't want to incur that cost unless absolutely
> necessary.

Ya, I wouldn't want the reservations on disk either unless it came in as 
an explicit pre-allocation request (and was accounted for in statfs 
info).  I'm treating that as a completely different beast at the moment.

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