linux-kernel - Re: [RFC] delayed allocation for 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] [thread-next>] [day] [month] [year] [list]

Date:	Fri, 29 Dec 2006 13:50:06 +1100
From:	David Chinner <dgc@....com>
To:	Christoph Hellwig <hch@...radead.org>, David Chinner <dgc@....com>,
	Alex Tomas <alex@...sterfs.com>, linux-ext4@...r.kernel.org,
	linux-kernel@...r.kernel.org
Subject: Re: [RFC] delayed allocation for ext4

On Sat, Dec 23, 2006 at 09:27:18AM +0000, Christoph Hellwig wrote:
> On Sat, Dec 23, 2006 at 02:31:23PM +1100, David Chinner wrote:
> > >  - ext4-delayed-allocation.patch
> > >    delayed allocation itself, enabled by "delalloc" mount option.
> > >    extents support is also required. currently it works only
> > >    with blocksize=pagesize.
> > 
> > Ah, that's why you can get away with a page flag - you've ignored
> > the partial page delay state problem. Any plans to use the
> > existing method in the future so we will be able to use ext4 delalloc
> > on machines with a page size larger than 4k?
> 
> I think fixing this up for blocksize < pagesize is an absolute requirement
> to get things merged.  We don't need more filesystems that are crippled
> on half of our platforms.
> 
> Note that recording delayed alloc state at a page granularity in addition
> to just the buffer heads has a lot of advantages aswell and would help
> xfs, too.  But I think it makes a lot more sense to record it as a radix
> tree tag to speed up the gang lookups for delalloc conversion.

I'm not sure it will make that much difference, really.  Looking up
by delalloc tag is only going to save a few tail pages in pagevec we
use for the look up and could be more expensive if delalloc pages
are sparsely distributed through the file.

We'd still have to keep the bufferheads around for partial page
state, and that becomes an interesting exercise in keeping things
coherent between the radix tree and the buffer heads.

Of course, then there's the unwritten state that XFS also carries
around per block (bufferhead) which has all the same issues as the
delalloc state.  I'd hate to have a generic method for handling
delalloc state which is different from the handling of the unwritten
state and needing two different sets of code to handle what is
essentially the same thing....

Cheers,

Dave.
-- 
Dave Chinner
Principal Engineer
SGI Australian Software Group
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/