On Wed, Mar 16 2011 at 7:11pm -0400, Les Mikesell <lesmikesell@gmail.com> wrote: > On 3/16/2011 5:55 PM, Mike Snitzer wrote: > > > >>On 3/14/2011 1:17 PM, Mike Snitzer wrote: > >>>Both LVM2 and Device Mapper have been updated to accommodate stacking > >>>such a mix of drives. > >>> > >>>See this for a bit more detail: > >>>http://people.redhat.com/msnitzer/docs/io-limits.txt > >>> > >>>Particularly, the "Stacking I/O Limits" section. > >>> > >>>The concern raised for partial (4k) writes to the 512b drive was > >>>discussed a bit more here: http://lkml.org/lkml/2010/2/22/295 > >> > >>Unfortunately this does not help with the WD EARS model drives ( are > >>there any other 4kb sector drives on the market now? ), since they lie > >>and report that they have 512 byte sectors. > > > >I'm not following what you're saying. The kernel's blk_stack_limits() > >infrastructure accounts for "desktop" class 4K devices too (4K physical, > >512b logical) -- as does DM and lvm2. > > > >If given: > > > >"desktop" class drive: > >physical_block_size=4096 > >logical_block_size=512 > >minimum_io_size=4096 > >optimal_io_size=0 > > How does the kernel know about the physical_block_size when the > device reports itself as 512? And they handle 512 byte writes, just > very slowly. The drive exports the information as part of its response to the IDENTIFY DEVICE (for ATA) or READ CAPACITY (for SCSI) command -- it splits out the physical and logical block sizes along with other attributes. The kernel's SCSI (and libata) layer issues these commands to the drive. Much more detail available in Martin's paper: http://oss.oracle.com/~mkp/docs/linux-advanced-storage.pdf Mike _______________________________________________ linux-lvm mailing list linux-lvm@redhat.com https://www.redhat.com/mailman/listinfo/linux-lvm read the LVM HOW-TO at http://tldp.org/HOWTO/LVM-HOWTO/
