Re: [Lsf-pc] [LSF/MM TOPIC] really large storage sectors - goingbeyond 4096 bytes

[Dave Chinner]

On Wed, Jan 22, 2014 at 09:21:40AM -0800, James Bottomley wrote:
> On Wed, 2014-01-22 at 17:02 +0000, Chris Mason wrote:
> > On Wed, 2014-01-22 at 15:19 +0000, Mel Gorman wrote:
> > > On Wed, Jan 22, 2014 at 09:58:46AM -0500, Ric Wheeler wrote:
> > > > On 01/22/2014 09:34 AM, Mel Gorman wrote:
> > > > >On Wed, Jan 22, 2014 at 09:10:48AM -0500, Ric Wheeler wrote:
> > > > >>On 01/22/2014 04:34 AM, Mel Gorman wrote:
> > > > >>>On Tue, Jan 21, 2014 at 10:04:29PM -0500, Ric Wheeler wrote:
> > > > >>>>One topic that has been lurking forever at the edges is the current
> > > > >>>>4k limitation for file system block sizes. Some devices in
> > > > >>>>production today and others coming soon have larger sectors and it
> > > > >>>>would be interesting to see if it is time to poke at this topic
> > > > >>>>again.
> > > > >>>>
> > > > >>>Large block support was proposed years ago by Christoph Lameter
> > > > >>>(http://lwn.net/Articles/232757/). I think I was just getting started
> > > > >>>in the community at the time so I do not recall any of the details. I do
> > > > >>>believe it motivated an alternative by Nick Piggin called fsblock though
> > > > >>>(http://lwn.net/Articles/321390/). At the very least it would be nice to
> > > > >>>know why neither were never merged for those of us that were not around
> > > > >>>at the time and who may not have the chance to dive through mailing list
> > > > >>>archives between now and March.
> > > > >>>
> > > > >>>FWIW, I would expect that a show-stopper for any proposal is requiring
> > > > >>>high-order allocations to succeed for the system to behave correctly.
> > > > >>>
> > > > >>I have a somewhat hazy memory of Andrew warning us that touching
> > > > >>this code takes us into dark and scary places.
> > > > >>
> > > > >That is a light summary. As Andrew tends to reject patches with poor
> > > > >documentation in case we forget the details in 6 months, I'm going to guess
> > > > >that he does not remember the details of a discussion from 7ish years ago.
> > > > >This is where Andrew swoops in with a dazzling display of his eidetic
> > > > >memory just to prove me wrong.
> > > > >
> > > > >Ric, are there any storage vendor that is pushing for this right now?
> > > > >Is someone working on this right now or planning to? If they are, have they
> > > > >looked into the history of fsblock (Nick) and large block support (Christoph)
> > > > >to see if they are candidates for forward porting or reimplementation?
> > > > >I ask because without that person there is a risk that the discussion
> > > > >will go as follows
> > > > >
> > > > >Topic leader: Does anyone have an objection to supporting larger block
> > > > >	sizes than the page size?
> > > > >Room: Send patches and we'll talk.
> > > > >
> > > > 
> > > > I will have to see if I can get a storage vendor to make a public
> > > > statement, but there are vendors hoping to see this land in Linux in
> > > > the next few years.
> > > 
> > > What about the second and third questions -- is someone working on this
> > > right now or planning to? Have they looked into the history of fsblock
> > > (Nick) and large block support (Christoph) to see if they are candidates
> > > for forward porting or reimplementation?
> > 
> > I really think that if we want to make progress on this one, we need
> > code and someone that owns it.  Nick's work was impressive, but it was
> > mostly there for getting rid of buffer heads.  If we have a device that
> > needs it and someone working to enable that device, we'll go forward
> > much faster.
> 
> Do we even need to do that (eliminate buffer heads)?

No, the reason bufferheads were replaced was that a bufferhead can
only reference a single page. i.e. the structure is that a page can
reference multipl bufferheads (block size >= page size) but a
bufferhead can't refernce multiple pages which is what is needed for
block size > page size. fsblock was designed to handle both cases.

Cheers,

Dave.
-- 
Dave Chinner
david@xxxxxxxxxxxxx
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/