[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20070306072850.GA23081@infradead.org>
Date: Tue, 6 Mar 2007 07:28:50 +0000
From: Christoph Hellwig <hch@...radead.org>
To: Mingming Cao <cmm@...ibm.com>
Cc: Jan Kara <jack@...e.cz>, Andrew Morton <akpm@...ux-foundation.org>,
nscott@...nex.com, "Amit K. Arora" <aarora@...ux.vnet.ibm.com>,
linux-fsdevel@...r.kernel.org, linux-kernel@...r.kernel.org,
linux-ext4@...r.kernel.org, suparna@...ibm.com, alex@...sterfs.com,
suzuki@...ibm.com, Ulrich Drepper <drepper@...hat.com>
Subject: Re: [RFC] Heads up on sys_fallocate()
On Mon, Mar 05, 2007 at 12:02:59PM -0800, Mingming Cao wrote:
> Yep, I think it makes sense to use preallocation for defragmentation.
> After all both preallocation and defragmentation shall call underlying
> filesystem multiple block allocator to try to allocate a chunk of
> contiguous blocks on disk. ext4 online defrag implementation by Takashi
> already support to choose a "goal" allocation block to guide the ext4
> block allocator to place the defraged file is a specific location.
>
> Passing a little bit more hint to sys_fallocate() (i.e, goal block,
> and/or whether the goal block is important over the size of prealloc
> extent), might make it more useful for the orginial goal (get contigous
> and guranteed blocks) and for defragmentation.
fallocate with the whence argument and flags is already quite complicated,
I'd rather have another call for placement decisions, that would
be called on an fd to do placement decissions for any further allocations
(prealloc, write, etc)
-
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/
Powered by blists - more mailing lists