[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <cac28cb80709190241m3fb1913ft64148071b54a1cb4@mail.gmail.com>
Date: Wed, 19 Sep 2007 13:41:17 +0400
From: "Alex Tomas" <alex@...sterfs.com>
To: "David Chinner" <dgc@....com>
Cc: "Linus Torvalds" <torvalds@...ux-foundation.org>,
"Nathan Scott" <nscott@...nex.com>,
"Andrea Arcangeli" <andrea@...e.de>,
"Nick Piggin" <nickpiggin@...oo.com.au>,
"Christoph Lameter" <clameter@....com>,
"Mel Gorman" <mel@...net.ie>, linux-fsdevel@...r.kernel.org,
linux-kernel@...r.kernel.org, "Christoph Hellwig" <hch@....de>,
"William Lee Irwin III" <wli@...omorphy.com>,
"Jens Axboe" <jens.axboe@...cle.com>,
"Badari Pulavarty" <pbadari@...il.com>,
"Maxim Levitsky" <maximlevitsky@...il.com>,
"Fengguang Wu" <fengguang.wu@...il.com>,
"swin wang" <wangswin@...il.com>, totty.lu@...il.com,
hugh@...itas.com, joern@...ybastard.org
Subject: Re: [00/41] Large Blocksize Support V7 (adds memmap support)
On 9/19/07, David Chinner <dgc@....com> wrote:
> The problem is this: to alter the fundamental block size of the
> filesystem we also need to alter the data block size and that is
> exactly the piece that linux does not support right now. So while
> we have the capability to use large block sizes in certain
> filesystems, we can't use that capability until the data path
> supports it.
it's much simpler to teach fs to understand multipage data (like
multipage bitmap scan, multipage extent search, etc) then deal with mm
fragmentation. IMHO. at same time you don't bust IO traffic with
non-used space.
--
thanks, Alex
-
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