linux-kernel - Re: Implementing NVMHCI...

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: <alpine.LFD.2.00.0904111725570.4583@localhost.localdomain>
Date:	Sat, 11 Apr 2009 17:49:41 -0700 (PDT)
From:	Linus Torvalds <torvalds@...ux-foundation.org>
To:	Jeff Garzik <jeff@...zik.org>
cc:	Alan Cox <alan@...rguk.ukuu.org.uk>,
	Grant Grundler <grundler@...gle.com>,
	Linux IDE mailing list <linux-ide@...r.kernel.org>,
	LKML <linux-kernel@...r.kernel.org>,
	Jens Axboe <jens.axboe@...cle.com>,
	Arjan van de Ven <arjan@...radead.org>
Subject: Re: Implementing NVMHCI...

On Sat, 11 Apr 2009, Jeff Garzik wrote:
> 
> Or just ignore the extra length, thereby excising the 'read-modify' step...
> Total storage is halved or worse, but you don't take as much of a performance
> hit.

Well, the people who want > 4kB sectors usually want _much_ bigger (ie 
32kB sectors), and if you end up doing the "just use the first part" 
thing, you're wasting 7/8ths of the space. 

Yes, it's doable, and yes, it obviously makes for a simple driver thing, 
but no, I don't think people will consider it acceptable to lose that much 
of their effective size of the disk.

I suspect people would scream even with a 8kB sector.

Treating all writes as read-modify-write cycles on a driver level (and 
then opportunistically avoiding the read part when you are lucky and see 
bigger contiguous writes) is likely more acceptable. But it _will_ suck 
dick from a performance angle, because no regular filesystem will care 
enough, so even with nicely behaved big writes, the two end-points will 
have a fairly high chance of requiring a rmw cycle.

Even the journaling ones that might have nice logging write behavior tend 
to have a non-logging part that then will behave badly. Rather few 
filesystems are _purely_ log-based, and the ones that are tend to have 
various limitations. Most commonly read performance just sucks.

We just merged nilfs2, and I _think_ that one is a pure logging filesystem 
with just linear writes (within a segment). But I think random read 
performance (think: loading executables off the disk) is bad.

And people tend to really dislike hardware that forces a particular 
filesystem on them. Guess how big the user base is going to be if you 
cannot format the device as NTFS, for example? Hint: if a piece of 
hardware only works well with special filesystems, that piece of hardware 
won't be a big seller. 

Modern technology needs big volume to become cheap and relevant.

And maybe I'm wrong, and NTFS works fine as-is with sectors >4kB. But let 
me doubt that.

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