From: Linus Torvalds <torvalds@linux-foundation.org>
To: Jeff Garzik <jeff@garzik.org>
Cc: Alan Cox <alan@lxorguk.ukuu.org.uk>,
Grant Grundler <grundler@google.com>,
Linux IDE mailing list <linux-ide@vger.kernel.org>,
LKML <linux-kernel@vger.kernel.org>,
Jens Axboe <jens.axboe@oracle.com>,
Arjan van de Ven <arjan@infradead.org>
Subject: Re: Implementing NVMHCI...
Date: Sat, 11 Apr 2009 17:49:41 -0700 (PDT) [thread overview]
Message-ID: <alpine.LFD.2.00.0904111725570.4583@localhost.localdomain> (raw)
In-Reply-To: <49E12D03.5070906@garzik.org>
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
next prev parent reply other threads:[~2009-04-12 0:55 UTC|newest]
Thread overview: 45+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-04-11 17:33 Implementing NVMHCI Jeff Garzik
2009-04-11 19:32 ` Alan Cox
2009-04-11 19:52 ` Linus Torvalds
2009-04-11 20:21 ` Jeff Garzik
2009-04-11 21:49 ` Grant Grundler
2009-04-11 22:33 ` Linus Torvalds
2009-04-12 5:08 ` Leslie Rhorer
2009-04-11 23:25 ` Alan Cox
2009-04-11 23:51 ` Jeff Garzik
2009-04-12 0:49 ` Linus Torvalds [this message]
2009-04-12 1:59 ` Jeff Garzik
2009-04-12 1:15 ` david
2009-04-12 3:13 ` Linus Torvalds
2009-04-12 14:23 ` Mark Lord
2009-04-12 17:29 ` Jeff Garzik
2009-04-11 19:54 ` Jeff Garzik
2009-04-11 21:08 ` John Stoffel
2009-04-11 21:31 ` John Stoffel
[not found] <20090412091228.GA29937@elte.hu>
2009-04-12 15:14 ` Szabolcs Szakacsits
2009-04-12 15:20 ` Alan Cox
2009-04-12 16:15 ` Avi Kivity
2009-04-12 17:11 ` Linus Torvalds
2009-04-13 6:32 ` Avi Kivity
2009-04-13 15:10 ` Linus Torvalds
2009-04-13 15:38 ` James Bottomley
2009-04-14 7:22 ` Andi Kleen
2009-04-14 10:07 ` Avi Kivity
2009-04-14 9:59 ` Avi Kivity
2009-04-14 10:23 ` Jeff Garzik
2009-04-14 10:37 ` Avi Kivity
2009-04-14 11:45 ` Jeff Garzik
2009-04-14 11:58 ` Szabolcs Szakacsits
2009-04-17 22:45 ` H. Peter Anvin
2009-04-14 12:08 ` Avi Kivity
2009-04-14 12:21 ` Jeff Garzik
2009-04-25 8:26 ` Pavel Machek
2009-04-12 15:41 ` Linus Torvalds
2009-04-12 17:02 ` Robert Hancock
2009-04-12 17:20 ` Linus Torvalds
2009-04-12 18:35 ` Robert Hancock
2009-04-13 11:18 ` Avi Kivity
2009-04-12 17:23 ` James Bottomley
[not found] ` <6934efce0904141052j3d4f87cey9fc4b802303aa73b@mail.gmail.com>
2009-04-15 6:37 ` Artem Bityutskiy
2009-04-30 22:51 ` Jörn Engel
2009-04-30 23:36 ` Jeff Garzik
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=alpine.LFD.2.00.0904111725570.4583@localhost.localdomain \
--to=torvalds@linux-foundation.org \
--cc=alan@lxorguk.ukuu.org.uk \
--cc=arjan@infradead.org \
--cc=grundler@google.com \
--cc=jeff@garzik.org \
--cc=jens.axboe@oracle.com \
--cc=linux-ide@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox