Martin K. Petersen wrote:
"Ric" == Ric Wheeler <rwheeler@xxxxxxxxxx> writes:
Ric> Big arrays have an internal "track" size that is much larger than
Ric> 512 bytes (Symm for example is 64k. Everything smaller than that
Ric> is a read-modify-write. Effectively, they have few to no bits
Ric> left to track this other bit of state at the smal level of
Ric> granularity.
My point still stands that this is an implementation problem in the
array firmware. It's not really our problem to solve. Especially
since drive vendors and mid-range storage vendors are getting it
right.
If EMC wants to provide thin provisioning on the Symmetrix they'll
have to overcome the inherent limitations in their own internal
architecture.
What's next? Requiring us to exclusively read and write in multiples
of block sizes that are artifacts of internal array implementation
details?
For thin provisioning to really work on the Symm, then, we're
effectively requiring the filesystem to use 64k filesystem blocks.
Lame!
I don't have a problem with honoring some bits akin to the block
device characteristics VPD in trying to do a best-effort scheduling of
the I/O. But effectively disabling thin provisioning for blocks
smaller than that is simply broken.
Actually, the big arrays have larger "unmap" chunks than the 64k, so it
is even more painful than that :-)
What is likely to happen is that "thin" will work for vendors with this
kind of limitation in a very limited way and they will need to have some
kind of user space tool to clean up the mess.
ric
--
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
