> On Mon, 2008-11-10 at 19:31 +1100, Dave Chinner wrote: > > On Sun, Nov 09, 2008 at 10:40:24PM -0500, Black_David@xxxxxxx wrote: > > > There will be a chunk size value available in a VPD page that can be > > > used to determine minimum size/alignment. For openers, I see essentially > > > no point in a 512-byte UNMAP, even though it's allowed by the standard - > > > I suspect most arrays (and many SSDs) will ignore it, and ignoring > > > it is definitely within the spirit of the proposed T10 standard (hint: > > > I'm one of the people directly working on that proposal). > > > > I think this is the crux of the issue. IMO, it's not much of a standard > > when the spirit of the standard is to allow everyone to implement > > different, non-deterministic behaviour.... > > I disagree. The discard request is a _hint_ from the upper layers, and > the storage device can act on that hint as it sees fit. There's nothing > wrong with that; it doesn't make it "not much of a standard". Bingo! That is exactly the spirit and thinking behind the UNMAP proposal. Besides, UNMAP is already inherently non-deterministic in that only the device knows what value will result from reading an unmapped block (unless the "unmapped blocks always read as zero" bit is set by the device). [... snip ...] > So I think it's perfectly acceptable for the operating system to treat > discard requests as a hint, with best-effort semantics. And any device > which _really_ cares will need to make sure for _itself_ that it handles > those hints reliably. I agree, at least to the extent that the device makes sure make sure that it reliably handles the hints that it cares about. Thanks, --David ---------------------------------------------------- David L. Black, Distinguished Engineer EMC Corporation, 176 South St., Hopkinton, MA 01748 +1 (508) 293-7953 FAX: +1 (508) 293-7786 black_david@xxxxxxx Mobile: +1 (978) 394-7754 ---------------------------------------------------- -- To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
