linux-fsdevel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Matthew Wilcox <matthew@wil.cx>
To: James Bottomley <James.Bottomley@HansenPartnership.com>
Cc: Ric Wheeler <rwheeler@redhat.com>,
	David Woodhouse <dwmw2@infradead.org>,
	"Martin K. Petersen" <mkp@mkp.net>, Jeff Garzik <jeff@garzik.org>,
	linux-scsi@vger.kernel.org, linux-fsdevel@vger.kernel.org,
	IDE/ATA development list <linux-ide@vger.kernel.org>
Subject: Re: TRIM vs UNMAP vs WRITE SAME and thin devices
Date: Sat, 7 Feb 2009 15:50:25 -0700	[thread overview]
Message-ID: <20090207225025.GB31509@parisc-linux.org> (raw)
In-Reply-To: <1234019372.4658.9.camel@localhost.localdomain>

On Sat, Feb 07, 2009 at 09:09:32AM -0600, James Bottomley wrote:
> On Sat, 2009-02-07 at 09:53 -0500, Ric Wheeler wrote:
> > I have been poked at by some vendors about the status of our support for 
> > the virtually/thinly provisioned luns since they are getting close to 
> > being able to test with real devices.
> 
> With my LSF hat on, a certain array vendor might be sponsoring to get
> the opportunity to raise this issue more fully.  The impression (mostly
> correct) is that we're thinking about trim/unmap purely from the SSD FTL
> point of view and perhaps not being as useful as we might to virtually
> provisioned LUNs ... so you could mention to the other vendors that they
> might have an interest in coming (and even possibly sponsoring).

I thought we had agreed on a plan which satisfied the SSD and insane
array vendors.  That is that we would do no tracking of allocation units
in the filesystem, but instead extend each trim out to cover the maximum
possible size.  I've confirmed with Intel's SSD people that this would
cause them no harm at all (trimming already trimmed sectors won't even
cause a slowdown).  Whether the filesystem people have taken note of
this, I have no idea.

-- 
Matthew Wilcox				Intel Open Source Technology Centre
"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."

  parent reply	other threads:[~2009-02-07 22:50 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <20090123041558.GC24652@parisc-linux.org>
     [not found] ` <4979AF62.7070409@redhat.com>
     [not found]   ` <1232721777.4430.7.camel@macbook.infradead.org>
2009-02-07 14:53     ` TRIM vs UNMAP vs WRITE SAME and thin devices Ric Wheeler
2009-02-07 15:09       ` James Bottomley
2009-02-07 16:14         ` Ric Wheeler
2009-02-12 13:51           ` Eyal Shani
2009-03-23 19:05             ` Greg Freemyer
2009-03-23 19:23               ` Mark Lord
2009-02-07 22:50         ` Matthew Wilcox [this message]
2009-02-07 23:03           ` James Bottomley
2009-02-08 16:47           ` Ric Wheeler
2009-02-08 20:50             ` Matthew Wilcox
2009-02-08 23:58               ` Ric Wheeler
2009-02-07 22:47       ` Matthew Wilcox
2009-02-07 23:36         ` David Woodhouse
2009-02-07 23:46         ` Jeff Garzik
2009-02-08  0:24           ` Matthew Wilcox
2009-02-08 20:06       ` Greg Freemyer
2009-02-08 20:44         ` Matthew Wilcox
2009-02-09  0:01           ` Ric Wheeler

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=20090207225025.GB31509@parisc-linux.org \
    --to=matthew@wil.cx \
    --cc=James.Bottomley@HansenPartnership.com \
    --cc=dwmw2@infradead.org \
    --cc=jeff@garzik.org \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-ide@vger.kernel.org \
    --cc=linux-scsi@vger.kernel.org \
    --cc=mkp@mkp.net \
    --cc=rwheeler@redhat.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;
as well as URLs for NNTP newsgroup(s).