>>>>> "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. -- Martin K. Petersen Oracle Linux Engineering -- 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
