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:	Wed, 4 Jul 2007 17:11:27 -0600
From:	Valerie Henson <val@....edu>
To:	Mike Waychison <mikew@...gle.com>
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

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?

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.

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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ