linux-kernel - Re: [Lsf-pc] [LSF/MM TOPIC] really large storage sectors

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <1390413819.1198.20.camel@ret.masoncoding.com>
Date:	Wed, 22 Jan 2014 18:02:09 +0000
From:	Chris Mason <clm@...com>
To:	"James.Bottomley@...senPartnership.com" 
	<James.Bottomley@...senPartnership.com>
CC:	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"linux-ide@...r.kernel.org" <linux-ide@...r.kernel.org>,
	"lsf-pc@...ts.linux-foundation.org" 
	<lsf-pc@...ts.linux-foundation.org>,
	"linux-mm@...ck.org" <linux-mm@...ck.org>,
	"linux-scsi@...r.kernel.org" <linux-scsi@...r.kernel.org>,
	"rwheeler@...hat.com" <rwheeler@...hat.com>,
	"akpm@...ux-foundation.org" <akpm@...ux-foundation.org>,
	"linux-fsdevel@...r.kernel.org" <linux-fsdevel@...r.kernel.org>,
	"mgorman@...e.de" <mgorman@...e.de>
Subject: Re: [Lsf-pc] [LSF/MM TOPIC] really large storage sectors - going
 beyond 4096 bytes

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

--
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/