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

Re: [linux-lvm] Advanced Format disks mixed with regular disks?

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:


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