lkml.org 
[lkml]   [2014]   [Jan]   [22]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRe: [Lsf-pc] [LSF/MM TOPIC] really large storage sectors - going beyond 4096 bytes
Date
On Wed, 2014-01-22 at 09:21 -0800, James Bottomley wrote:
> On Wed, 2014-01-22 at 17:02 +0000, Chris Mason wrote:

[ I like big sectors and I cannot lie ]

>
> > 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)? We cope with 4k
> sector only devices just fine today because the bh mechanisms now
> operate on top of the page cache and can do the RMW necessary to update
> a bh in the page cache itself which allows us to do only 4k chunked
> writes, so we could keep the bh system and just alter the granularity of
> the page cache.
>

We're likely to have people mixing 4K drives and <fill in some other
size here> on the same box. We could just go with the biggest size and
use the existing bh code for the sub-pagesized blocks, but I really
hesitate to change VM fundamentals for this.

From a pure code point of view, it may be less work to change it once in
the VM. But from an overall system impact point of view, it's a big
change in how the system behaves just for filesystem metadata.

> The other question is if the drive does RMW between 4k and whatever its
> physical sector size, do we need to do anything to take advantage of
> it ... as in what would altering the granularity of the page cache buy
> us?

The real benefit is when and how the reads get scheduled. We're able to
do a much better job pipelining the reads, controlling our caches and
reducing write latency by having the reads done up in the OS instead of
the drive.

-chris



\
 
 \ /
  Last update: 2014-01-22 19:41    [W:0.453 / U:0.632 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site