linux-ide.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Eric Sandeen <sandeen@redhat.com>
To: Christoph Hellwig <hch@infradead.org>
Cc: Ric Wheeler <rwheeler@redhat.com>,
	Greg Freemyer <greg.freemyer@gmail.com>, Mark Lord <liml@rtr.ca>,
	Matthew Wilcox <matthew@wil.cx>,
	"Martin K. Petersen" <martin.petersen@oracle.com>,
	jens.axboe@oracle.com, james.bottomley@hansenpartnership.com,
	willy@wil.cx, jgarzik@pobox.com, linux-ide@vger.kernel.org,
	linux-scsi@vger.kernel.org
Subject: Re: [PATCH 1/4] block: Allow devices to indicate whether discarded blocks are zeroed
Date: Mon, 23 Nov 2009 11:50:05 -0600	[thread overview]
Message-ID: <4B0ACB4D.1030403@redhat.com> (raw)
In-Reply-To: <20091123170325.GA23217@infradead.org>

Christoph Hellwig wrote:
> On Mon, Nov 23, 2009 at 12:02:48PM -0500, Ric Wheeler wrote:
>> I agree - the discard of the whole device is a good idea.
>>
>> I just want to make clear that "discard block X; write block X with 
>> zeroed data" undoes the discard in general :-)
> 
> We can skip the writing of zeroes if we know the device returns zeroed
> blocks after a trim.  Martin's patch exports that information to
> userspace, and once we have a nice enough interface (e.g. blkid or an
> ioctl) we can actually use it in mkfs to optimize the writing of zeroes
> away.  Raw growling in sysfs is a bit too nasty to add it to mkfs for
> those few blocks IMHO.
> 

well, in testing, I've found that not all devices which claim to return
0s post-trim, do.

For example one ssd I have, if I pattern 1M of 0xaf, then trim from
512k to 1M, and read it back (all IO done direct) I get:

00000000  af af af af af af af af  af af af af af af af af
*
00080000  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00
*
000a9000  af af af af af af af af  af af af af af af af af
*
00100000

with scraps of data left over at 0xA9000.

So for the very few blocks that we zero at mkfs (thinking xfs here,
anyway) I'd really rather just zero them post-trim to be safe, at least
for now.

-Eric


  reply	other threads:[~2009-11-23 17:50 UTC|newest]

Thread overview: 31+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-11-21  2:45 Thin provisioning fixes Martin K. Petersen
2009-11-21  2:45 ` [PATCH 1/4] block: Allow devices to indicate whether discarded blocks are zeroed Martin K. Petersen
2009-11-21 10:13   ` Christoph Hellwig
2009-11-21 19:58     ` Matthew Wilcox
2009-11-22  2:43       ` Mark Lord
2009-11-23 16:37         ` Ric Wheeler
2009-11-23 16:54           ` Greg Freemyer
2009-11-23 17:02             ` Ric Wheeler
2009-11-23 17:03               ` Christoph Hellwig
2009-11-23 17:50                 ` Eric Sandeen [this message]
2009-11-23 17:05       ` Christoph Hellwig
2009-11-21 12:50   ` Ric Wheeler
2009-11-21 20:17     ` Martin K. Petersen
2009-11-21  2:45 ` [PATCH 2/4] sd: WRITE SAME(16) / UNMAP support Martin K. Petersen
2009-11-21  2:45 ` [PATCH 3/4] libata: Report zeroed read after Trim and max discard size Martin K. Petersen
2009-11-21 10:49   ` Christoph Hellwig
2009-11-21 20:16     ` Martin K. Petersen
2009-11-24 14:35       ` Christoph Hellwig
2009-11-24 15:20         ` Mark Lord
2009-11-24 15:21           ` Christoph Hellwig
2009-11-21  2:45 ` [PATCH 4/4] libata: Fix garbled Trim payload Martin K. Petersen
2009-11-21 10:47   ` Christoph Hellwig
2009-11-21 19:50     ` Martin K. Petersen
2009-11-21  4:56 ` Thin provisioning fixes Eric Sandeen
2009-11-21  6:08   ` Martin K. Petersen
2009-11-21  6:55   ` Martin K. Petersen
2009-11-26 10:59 ` Christoph Hellwig
2009-11-26 11:01   ` Jens Axboe
2009-11-26 11:05     ` Christoph Hellwig
2009-11-26 15:13       ` Mark Lord
2009-11-26 15:14         ` Mark Lord

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=4B0ACB4D.1030403@redhat.com \
    --to=sandeen@redhat.com \
    --cc=greg.freemyer@gmail.com \
    --cc=hch@infradead.org \
    --cc=james.bottomley@hansenpartnership.com \
    --cc=jens.axboe@oracle.com \
    --cc=jgarzik@pobox.com \
    --cc=liml@rtr.ca \
    --cc=linux-ide@vger.kernel.org \
    --cc=linux-scsi@vger.kernel.org \
    --cc=martin.petersen@oracle.com \
    --cc=matthew@wil.cx \
    --cc=rwheeler@redhat.com \
    --cc=willy@wil.cx \
    /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).