[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <4631CFCD.7020207@yahoo.com.au>
Date: Fri, 27 Apr 2007 20:26:21 +1000
From: Nick Piggin <nickpiggin@...oo.com.au>
To: "Eric W. Biederman" <ebiederm@...ssion.com>
CC: Jens Axboe <jens.axboe@...cle.com>,
Christoph Lameter <clameter@....com>,
Christoph Hellwig <hch@...radead.org>,
David Chinner <dgc@....com>, linux-kernel@...r.kernel.org,
Mel Gorman <mel@...net.ie>,
William Lee Irwin III <wli@...omorphy.com>,
Badari Pulavarty <pbadari@...il.com>,
Maxim Levitsky <maximlevitsky@...il.com>
Subject: Re: [00/17] Large Blocksize Support V3
Eric W. Biederman wrote:
> Jens Axboe <jens.axboe@...cle.com> writes:
>>Yes, that is exactly the problem. Once you have that, pktcdvd is pretty
>>much reduced to setup and init code, the actual data handling can be
>>done by sr or ide-cd directly. You could merge it into cdrom.c, it would
>>not be very different from mt-rainier handling (which basically does RMW
>>in firmware, so it works for any write, but performance is of course
>>horrible if you don't do it right).
>
>
> Thanks for the clarification.
>
> So we do have a clear problem that we do not have generic support for
> large sector sizes residing in the page cache.
Well, it is a clear limitation. It hasn't mattered too much until
now, but it is one of the other issues that SGI hit (aside from
io efficiency) because they have 16K filesystems created on ia64
systems that I believe they want to access with x86-64 systems.
I'm slowly looking at patches in the background, but I'm hoping to
be able to spend a decent chunk of time working on them again soon.
It isn't trivial :)
--
SUSE Labs, Novell Inc.
-
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