From: Matthew Wilcox <matthew@wil.cx>
To: Jamie Lokier <jamie@shareable.org>
Cc: "Knight, Frederick" <Frederick.Knight@netapp.com>,
David Woodhouse <dwmw2@infradead.org>,
ricwheeler@gmail.com, linux-fsdevel@vger.kernel.org,
Christoph Hellwig <hch@infradead.org>
Subject: Re: Thin device provisioning
Date: Sat, 9 Aug 2008 21:51:55 -0600 [thread overview]
Message-ID: <20080810035154.GN8618@parisc-linux.org> (raw)
In-Reply-To: <20080810005038.GA20183@shareable.org>
On Sun, Aug 10, 2008 at 01:50:38AM +0100, Jamie Lokier wrote:
> Matthew Wilcox wrote:
> > I've spoken with a few Linux filesystem people. They find it
> > significantly easier to send a single LBA/length pair at a time.
> > Modern filesystems try quite hard to keep fragmentation to a minimum, so
> > they don't expect a performance hit from sending multiple commands.
> > They're non-blocking writes, and the IO elevators can take care of
> > sending more important reads first.
>
> Perhaps there are occasions when it's more efficient for the disk to
> process several LBA/length pairs in a single operation?
>
> I.e. you send the first pair, the disk starts working, then you send
> the second, and that's not as efficient as doing both at the same
> time, which might translate to a single commit on SSD.
>
> The general solution to that would be a 'CORK' operation, though,
> similar to TCP_CORK: this operation will be followed by others, you
> may start it now, but don't rush...
If you read what Fred Knight (of the T10 committee) wrote, he said that
they felt it would be easier for filesystems and drivers to use multiple
extents. He didn't say anything about drives finding it more efficient.
--
Intel are signing my paycheques ... these opinions are still mine
"Bill, look, we understand that you're interested in selling us this
operating system, but compare it to ours. We can't possibly take such
a retrograde step."
prev parent reply other threads:[~2008-08-10 3:52 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <200808081714.m78HEMkA026466@coles02.co.lsil.com>
[not found] ` <AC32D7C72530234288643DD5F1435D53A80EC3@RTPMVEXC1-PRD.hq.netapp.com>
2008-08-09 16:45 ` Thin device provisioning Matthew Wilcox
2008-08-09 17:12 ` Knight, Frederick
2008-08-12 18:56 ` David Woodhouse
2008-08-12 20:38 ` Knight, Frederick
2008-08-12 23:21 ` Matthew Wilcox
2008-08-13 16:50 ` Alan D. Brunelle
2008-08-13 17:04 ` David Woodhouse
2008-08-10 0:50 ` Jamie Lokier
2008-08-10 3:51 ` Matthew Wilcox [this message]
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=20080810035154.GN8618@parisc-linux.org \
--to=matthew@wil.cx \
--cc=Frederick.Knight@netapp.com \
--cc=dwmw2@infradead.org \
--cc=hch@infradead.org \
--cc=jamie@shareable.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=ricwheeler@gmail.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