Re: thin provisioned LUN support

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



>>>>> "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-scsi" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [SCSI Target Devel]     [Linux SCSI Target Infrastructure]     [Kernel Newbies]     [IDE]     [Security]     [Git]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux ATA RAID]     [Linux IIO]     [Samba]     [Device Mapper]
  Powered by Linux