mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Linus Torvalds <torvalds@linux-foundation.org>
To: Robert Hancock <hancockrwd@gmail.com>
Cc: Szabolcs Szakacsits <szaka@ntfs-3g.com>,
	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: Sun, 12 Apr 2009 10:20:32 -0700 (PDT)	[thread overview]
Message-ID: <alpine.LFD.2.00.0904121012500.4583@localhost.localdomain> (raw)
In-Reply-To: <49E21E8A.2040005@gmail.com>



On Sun, 12 Apr 2009, Robert Hancock wrote:
>
> What about FAT? It supports cluster sizes up to 32K at least (possibly up to
> 256K as well, although somewhat nonstandard), and that works.. We support that
> in Linux, don't we?

Sure. 

The thing is, "cluster size" in an FS is totally different from sector 
size.

People are missing the point here. You can trivially implement bigger 
cluster sizes by just writing multiple sectors. In fact, even just a 4kB 
cluster size is actually writing 8 512-byte hardware sectors on all normal 
disks.

So you can support big clusters without having big sectors. A 32kB cluster 
size in FAT is absolutely trivial to do: it's really purely an allocation 
size. So a fat filesystem allocates disk-space in 32kB chunks, but then 
when you actually do IO to it, you can still write things 4kB at a time 
(or smaller), because once the allocation has been made, you still treat 
the disk as a series of smaller blocks.

IOW, when you allocate a new 32kB cluster, you will have to allocate 8 
pages to do IO on it (since you'll have to initialize the diskspace), but 
you can still literally treat those pages as _individual_ pages, and you 
can write them out in any order, and you can free them (and then look them 
up) one at a time.

Notice? The cluster size really only ends up being a disk-space allocation 
issue, not an issue for actually caching the end result or for the actual 
size of the IO.

The hardware sector size is very different. If you have a 32kB hardware 
sector size, that implies that _all_ IO has to be done with that 
granularity. Now you can no longer treat the eight pages as individual 
pages - you _have_ to write them out and read them in as one entity. If 
you dirty one page, you effectively dirty them all. You can not drop and 
re-allocate pages one at a time any more.

				Linus

  reply	other threads:[~2009-04-12 17:26 UTC|newest]

Thread overview: 44+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [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 [this message]
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
2009-04-11 17:33 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-11 23:25       ` Alan Cox
2009-04-11 23:51         ` Jeff Garzik
2009-04-12  0:49           ` Linus Torvalds
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

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.0904121012500.4583@localhost.localdomain \
    --to=torvalds@linux-foundation.org \
    --cc=alan@lxorguk.ukuu.org.uk \
    --cc=arjan@infradead.org \
    --cc=grundler@google.com \
    --cc=hancockrwd@gmail.com \
    --cc=jens.axboe@oracle.com \
    --cc=linux-ide@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=szaka@ntfs-3g.com \
    /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

Powered by JetHome