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.
My quick summary is that we most of the work so far has been done
without any real hardware to play with - in 2.6.29-rc3, I don't see any
low level ATA or SCSI bits that turn requests tagged with REQ_DISCARD
into the specific ATA or SCSI commands. Did I miss something & if not,
do we have plans to push anything upstream soonish?
One note on the SCSI devices, there was a T10 proposal to add an "UNMAP"
bit to the "WRITE SAME" command for SCSI. The details of the proposed
interface are at:
http://www.t11.org/t10/document.08/08-356r4.pdf
The up side of using WRITE SAME with unmap is that there are no fuzzy
semantics about what the unmapped sectors will be - they will all be
whatever the WRITE SAME command would have set (usually zeroes I assume).
The summary of write same is that you send down one sector (say 512
bytes of zeroes) and a count so you can do a zeroing of the target
without having to send all of the data over the wire. Very useful for
initializing members of a RAID device for example to a known pattern.
The down side would be that if we incorrectly send down a WRITE SAME
command to a non-thin device, I think that we would kick off a potential
extremely long IO. For example, imagine doing a write same of a full TB
- that could take an hour which might be an issue :-) Of course, we
should not be doing that if we get the code right.
I don't see another of the PDF's claims of advantages for file systems
to be really all that useful.
With either the write same and its proposed unmap bit or with the
original T10 unmap, do we have a short list of infrastructure that needs
fleshed out? Anything we can do to help get peoples patches to test with
their non-GA thin enabled devices?
Is there a similar short list of things to be done for T13 devices with
TRIM? Anyone have a chance to test on real hardware yet?
Thanks!
Ric
--
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
