Advanced Format disks mixed with regular disks?
Hi,
Is there any concern with mixing 4KB-sector drives with 512-byte sector drives in the same LV?
Sincerely,
Ron
Signature · 1 line
I prefer banana-flavored energy bars made from tofu.
Quoted 4 lines · Ron Johnson
Hi,
Is there any concern with mixing 4KB-sector drives with 512-byte sector drives in the same LV?
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
Quoted 7 lines · Mike Snitzer
Quoted 3 lines
Is there any concern with mixing 4KB-sector drives with 512-byte sector drives in the same LV?
Both LVM2 and Device Mapper have been updated to accommodate stacking such a mix of drives.
Quoted 7 lines
See this for a bit more detail:
http://people.redhat.com/msnitzer/docs/io-limits.txtParticularly, 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
Are there any version-level hints about when/where these changes appear and come together in the real world (i.e. distributions like RHEL, debian, Ubuntu)?
Signature · 2 lines
Les Mikesell [email protected]
Quoted 11 lines · Les Mikesell
Quoted 10 lines · Mike Snitzer
Quoted 3 lines
Is there any concern with mixing 4KB-sector drives with 512-byte sector drives in the same LV?
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
Quoted 8 lines
Quoted 4 lines
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
Are there any version-level hints about when/where these changes appear and come together in the real world (i.e. distributions like RHEL, debian, Ubuntu)?
For the kernel, the bulk of associated infrastructure (ata, scsi, block, dm, md, etc) went in 2.6.31, 2.6.32 saw some improvements, and 2.6.33 and 2.6.34 saw a few bug fixes.
v2.6.32.11 saw a backport of the 2.6.33 and 2.6.34 bug fixes via commit 9b2ff97
RHEL6 has all this. I cannot speak for debian and/or Ubuntu.
As for LVM2, you'd want >= 2.02.62.
Mike
Quoted 27 lines · Mike Snitzer
Quoted 11 lines · Les Mikesell
Quoted 10 lines · Mike Snitzer
Quoted 3 lines
Is there any concern with mixing 4KB-sector drives with 512-byte sector drives in the same LV?
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.txtQuoted 8 lines
Quoted 4 lines
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
Are there any version-level hints about when/where these changes appear and come together in the real world (i.e. distributions like RHEL, debian, Ubuntu)?
For the kernel, the bulk of associated infrastructure (ata, scsi, block, dm, md, etc) went in 2.6.31, 2.6.32 saw some improvements, and 2.6.33 and 2.6.34 saw a few bug fixes.
Quoted 7 lines
v2.6.32.11 saw a backport of the 2.6.33 and 2.6.34 bug fixes via commit 9b2ff97
RHEL6 has all this. I cannot speak for debian and/or Ubuntu.
As for LVM2, you'd want>= 2.02.62.
Thanks...
$ cat /etc/debian_version wheezy/sid
$ /sbin/lvm version LVM version: 2.02.84(2) (2011-02-09) Library version: 1.02.63 (2011-02-09)
$ uname -r 2.6.37-2-amd64
Signature · 1 line
I prefer banana-flavored energy bars made from tofu.
Quoted 11 lines · Mike Snitzer
Quoted 4 lines · Ron Johnson
Hi,
Is there any concern with mixing 4KB-sector drives with 512-byte sector drives in the same LV?
Both LVM2 and Device Mapper have been updated to accommodate stacking such a mix of drives.
Quoted 8 lines
See this for a bit more detail:
http://people.redhat.com/msnitzer/docs/io-limits.txtParticularly, 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
Does this mean that util-linux v2.17.1 fdisk correctly handle AF disks? (Note that I will *not* be booting off an AF device.)
ftp://ftp.kernel.org/pub/linux/utils/util-linux/v2.17/v2.17.1-ReleaseNotes
fdisk:
- cleanup alignment, default to 1MiB offset [Karel Zak]
- don't check alignment_offset against geometry [Karel Zak]
- fallback for topology values [Karel Zak]
- fix ALIGN_UP [Karel Zak]
- fix check_alignment() [Karel Zak]
- fix default first sector [Karel Zak]
- use "optimal I/O size" in warnings [Karel Zak]
- use 1MiB offset and grain always when possible [Karel Zak]
- use more elegant way to count and check alignment [Karel Zak]
- use optimal_io_size [Karel Zak]
Signature · 1 line
I prefer banana-flavored energy bars made from tofu.
Quoted 26 lines · Ron Johnson
Quoted 11 lines · Mike Snitzer
Quoted 4 lines · Ron Johnson
Hi,
Is there any concern with mixing 4KB-sector drives with 512-byte sector drives in the same LV?
Both LVM2 and Device Mapper have been updated to accommodate stacking such a mix of drives.
Quoted 8 lines
See this for a bit more detail:
http://people.redhat.com/msnitzer/docs/io-limits.txtParticularly, 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
Does this mean that util-linux v2.17.1 fdisk correctly handle AF disks? (Note that I will *not* be booting off an AF device.)
ftp://ftp.kernel.org/pub/linux/utils/util-linux/v2.17/v2.17.1-ReleaseNotes
Quoted 11 lines
fdisk:
- cleanup alignment, default to 1MiB offset [Karel Zak]
- don't checkalignment_offsetagainst geometry [Karel Zak]
- fallback for topology values [Karel Zak]
- fixALIGN_UP[Karel Zak]
- fixcheck_alignment()[Karel Zak]
- fix default first sector [Karel Zak]
- use "optimal I/O size" in warnings [Karel Zak]
- use 1MiB offset and grain always when possible [Karel Zak]
- use more elegant way to count and check alignment [Karel Zak]
- useoptimal_io_size[Karel Zak]
Given that changelog, yes.
(cc'ing kzak for the authoritative answer ;)
Quoted 18 lines · Mike Snitzer
Quoted 15 lines · Ron Johnson
Quoted 14 lines · Mike Snitzer
Quoted 4 lines · Ron Johnson
Hi,
Is there any concern with mixing 4KB-sector drives with 512-byte sector drives in the same LV?
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
Quoted 8 lines
Quoted 8 lines
Quoted 5 lines
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
Does this mean that util-linux v2.17.1 fdisk correctly handle AF disks? (Note that I will *not* be booting off an AF device.)
ideally util-linux >= 2.17.2 (e.g. RHEL6)
Quoted 15 lines
Quoted 14 lines
ftp://ftp.kernel.org/pub/linux/utils/util-linux/v2.17/v2.17.1-ReleaseNotes
fdisk:
- cleanup alignment, default to 1MiB offset [Karel Zak]
- don't checkalignment_offsetagainst geometry [Karel Zak]
- fallback for topology values [Karel Zak]
- fixALIGN_UP[Karel Zak]
- fixcheck_alignment()[Karel Zak]
- fix default first sector [Karel Zak]
- use "optimal I/O size" in warnings [Karel Zak]
- use 1MiB offset and grain always when possible [Karel Zak]
- use more elegant way to count and check alignment [Karel Zak]
- useoptimal_io_size[Karel Zak]
Quoted 1 line
Given that changelog, yes.
Yes, it works. Note that you have to disable (-c -u) DOS compatible mode. The mode is disabled by default in Fedora, but enabled in RHEL6.
Some hints:
http://karelzak.blogspot.com/2010/05/4096-byte-sector-hard-drives.html
Karel
Signature · 2 lines
Karel Zak <[email protected]> http://karelzak.blogspot.com
Quoted 2 lines · Karel Zak
Some hints:
http://karelzak.blogspot.com/2010/05/4096-byte-sector-hard-drives.html
I remember working with 256 byte sector hard drives the size of a mini refrigerator. 512 byte sectors were "advanced format".
--
Stuart D. Gathman <[email protected]> Business Management Systems Inc. Phone: 703 591-0911 Fax: 703 591-6154
"Confutatis maledictis, flammis acribus addictis" - background song for a Microsoft sponsored "Where do you want to go from here?" commercial.
Quoted 6 lines · Stuart D. Gathman
Quoted 2 lines · Karel Zak
Some hints:
http://karelzak.blogspot.com/2010/05/4096-byte-sector-hard-drives.htmlI remember working with 256 byte sector hard drives the size of a mini refrigerator. 512 byte sectors were "advanced format".
More future oriented: I read about high density storage just around the
corner that uses much larger sectors, typically 128K or 256K. These
are things like holographic memory. The researchers complain that existing filesystems can't handle the large sector size efficiently. (Don't know what filesystems they tried.) I note the similarity between
those sector sizes and flash erase blocks.
--
Stuart D. Gathman <[email protected]> Business Management Systems Inc. Phone: 703 591-0911 Fax: 703 591-6154
"Confutatis maledictis, flammis acribus addictis" - background song for a Microsoft sponsored "Where do you want to go from here?" commercial.
Quoted 39 lines · Ron Johnson
Quoted 12 lines · Mike Snitzer
Quoted 4 lines · On Mon, Mar 14 2011 at 12:47pm -0400, Ron Johnson<[email protected]> �wrote:
Hi,
Is there any concern with mixing 4KB-sector drives with 512-byte sector drives in the same LV?
Both LVM2 and Device Mapper have been updated to accommodate stacking such a mix of drives.
Quoted 8 lines
See this for a bit more detail:
http://people.redhat.com/msnitzer/docs/io-limits.txtParticularly, 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
Does this mean that util-linux v2.17.1 fdisk correctly handle AF disks? �(Note that I will *not* be booting off an AF device.)
ftp://ftp.kernel.org/pub/linux/utils/util-linux/v2.17/v2.17.1-ReleaseNotes
fdisk:
� - cleanup alignment, default to 1MiB offset �[Karel Zak] � - don't checkalignment_offsetagainst geometry �[Karel Zak] � - fallback for topology values �[Karel Zak]
� - fixALIGN_UP�[Karel Zak]
� - fixcheck_alignment()�[Karel Zak]
� - fix default first sector �[Karel Zak]
� - use "optimal I/O size" in warnings �[Karel Zak]
� - use 1MiB offset and grain always when possible �[Karel Zak] � - use more elegant way to count and check alignment �[Karel Zak] � - useoptimal_io_size�[Karel Zak]
Quoted 2 lines
--
I prefer banana-flavored energy bars made from tofu.
fdisk now aligns partitions to sector 2048. I know this since it has done that on the last few I formatted.
John
Quoted 10 lines · Mike Snitzer
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.txtParticularly, 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.
Quoted 7 lines · Phillip Susi
Quoted 6 lines · Mike Snitzer
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
Quoted 8 lines
Quoted 4 lines
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
conventional 512 drive:
physical_block_size=512
logical_block_size=512
minimum_io_size=512
optimal_io_size=0
Stacking these drives would result in a logical device that has:
physical_block_size=4096
logical_block_size=512
minimum_io_size=4096
optimal_io_size=0
And yes, there are native 4K "enterprise" class drives (4K physical, 4K logical) in the market.
Mike
Quoted 21 lines · Mike Snitzer
Quoted 8 lines · Mike Snitzer
Quoted 6 lines
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.txtQuoted 8 lines
Quoted 4 lines
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.
Quoted 7 lines
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.
Signature · 2 lines
Les Mikesell [email protected]
Quoted 30 lines · Les Mikesell
Quoted 21 lines · Mike Snitzer
Quoted 8 lines · Mike Snitzer
Quoted 6 lines
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.txtQuoted 8 lines
Quoted 4 lines
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.Quoted 7 lines
If given:
"desktop" class drive:
physical_block_size=4096
logical_block_size=512
minimum_io_size=4096
optimal_io_size=0
Quoted 3 lines
How does the kernel know about the
physical_block_sizewhen 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
Quoted 37 lines · Mike Snitzer
Quoted 30 lines · Les Mikesell
Quoted 21 lines · Mike Snitzer
Quoted 8 lines · Mike Snitzer
Quoted 6 lines
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.txtQuoted 8 lines
Quoted 4 lines
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.Quoted 7 lines
If given:
"desktop" class drive:
physical_block_size=4096
logical_block_size=512
minimum_io_size=4096
optimal_io_size=0Quoted 3 lines
How does the kernel know about the
physical_block_sizewhen the device reports itself as 512? And they handle 512 byte writes, just very slowly.
Quoted 5 lines
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.
I just got Phillips' mail that the drive lies and reports 512/512. (and I read your mail too quickly).
So yeah, the WD EARS drives are scary. Best for WD to defend or explain them.
Mike
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Quoted 3 lines · Mike Snitzer
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.
The kernel has the ability to read it from the drive and report it to the user space tools, which have been patched to use it, but the WD EARS drives lie and claim 512/512 instead of 512/4096.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAk2BUewACgkQJ4UciIs+XuJ9ZwCeKxZGCQ7X3lJjgWrfuK/UVsaX AO8An1nAO9p9wBvy6CxEgGHIXo2vemUc
=YQ0W
-----END PGP SIGNATURE-----
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
"Phillip" == Phillip Susi <[email protected]> writes:
Phillip> The kernel has the ability to read it from the drive and report Phillip> it to the user space tools, which have been patched to use it, Phillip> but the WD EARS drives lie and claim 512/512 instead of Phillip> 512/4096.
The saving grace is that modern util-linux/dm tooling aligns on 1MB by default instead of sector 63.
And yes, there are Advanced Format drives shipping from both Hitachi and Seagate...
Signature · 1 line
Martin K. Petersen Oracle Linux Engineering
Quoted 2 lines · Martin K. Petersen
And yes, there are Advanced Format drives shipping from both Hitachi and Seagate...
And Samsung
Quoted 10 lines · Martin K. Petersen
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
"Phillip" == Phillip Susi<[email protected]> writes:
Phillip> The kernel has the ability to read it from the drive and report Phillip> it to the user space tools, which have been patched to use it, Phillip> but the WD EARS drives lie and claim 512/512 instead of Phillip> 512/4096.The saving grace is that modern util-linux/dm tooling aligns on 1MB by default instead of sector 63.
So, given the correct options ( -c -b 4096 ), v2.17.2 will handle the 2TB WD Caviar Green WD20EARS drives which I just bought for my external backup device... Right?
(Along with a current lvm and kernel.)
https://www.redhat.com/archives/linux-lvm/2011-March/msg00053.html
Signature · 1 line
I prefer banana-flavored energy bars made from tofu.
Quoted 8 lines · Ron Johnson
Quoted 7 lines · Martin K. Petersen
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
"Phillip" == Phillip Susi<[email protected]> writes:
Phillip> The kernel has the ability to read it from the drive and report Phillip> it to the user space tools, which have been patched to use it, Phillip> but the WD EARS drives lie and claim 512/512 instead of Phillip> 512/4096.
Quoted 7 lines
Quoted 3 lines
The saving grace is that modern util-linux/dm tooling aligns on 1MB by default instead of sector 63.
So, given the correct options ( -c -b 4096 ), v2.17.2 will handle the 2TB WD Caviar Green WD20EARS drives which I just bought for my external backup device... Right?
The -b option is usually unnecessary (for v2.17 is the -c enough).
It seems (according to feedback from users) that newer WDxxEARS disks are already fixed.
http://community.wdc.com/t5/Desktop/Problem-with-WD-Advanced-Format-drive-in-LINUX-WD15EARS/m-p/20675#M1245
Try
hdparm -I /dev/<disk>
to see more details, for example:
Logical Sector size: 512 bytes
Physical Sector size: 4096 bytes
and
# cat /sys/block/<disk>/queue/physical_block_size 4096
It's also better to update to util-linux v2.18 or v2.19 where all the new features are enabled by default (so -c is unnecessary too).
Karel
Signature · 2 lines
Karel Zak <[email protected]> http://karelzak.blogspot.com
Quoted 12 lines · Karel Zak
It seems (according to feedback from users) that newer WDxxEARS disks are already fixed.
http://community.wdc.com/t5/Desktop/Problem-with-WD-Advanced-Format-drive-in-LINUX-WD15EARS/m-p/20675#M1245Try
hdparm -I /dev/<disk>
to see more details, for example:
Quoted 7 lines
Logical Sector size: 512 bytes
Physical Sector size: 4096 bytesand
# cat /sys/block/<disk>/queue/physical_block_size 4096
This isn't exactly an LVM issue (but I suppose it could be, and at least some people understand the problem here...). I'd like to do RAID1 with a WD 'Scorpio' laptop-size 750 gig drive which has 4k sectors but reports 512 as both the physical and logical size as one member with a full size Seagate with a matching number of sectors as the other. And I'd like to periodically swap the small drive, rotate offsite, and resync a different one. As things stand, it would take days for this sync to complete so I've been using full size drives for both instances.
Is there some hope of getting the sync time down to 8 hours or so?
And is that going to involve both updating to a fairly recent Linux distro (it's Centos 5.x now) and starting from scratch with new partition alignment?
For full disclosure, this is a backuppc archive with a bizallion hardlinks that would take many days to copy with a file-oriented approach and it's really a 3-member raid1 where 2 drives are always present and one swapped in long enough to resync. But those things shouldn't matter except for the difficulty in changing the partition alignment. The existing one runs to the end of the disk so I can't offset the start and still match up in size.
Signature · 2 lines
Les Mikesell [email protected]