Re: Changing the default CHS used by Linux partition editors

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

 



On Thu, 2008-12-11 at 17:30 -0500, Theodore Ts'o wrote:
> I attended the IDEMA (International Disk Drive Equipment and Materials
> Association) conference today to give a talk about Linux, and during one
> of the breaks I got buttonholed by someone who asked me if I could help
> make sure Linux would be able to deal with the upcoming HDD sector size
> move from 512 to 4096.  Just coincidentally, I ran across the following
> article from Slashdot, "Which Operating System Is Best For solid-state
> disks":
> 
> http://www.computerworld.com/action/article.do?command=viewArticleBasic&taxonomyName=Storage&articleId=9123140&taxonomyId=19&pageNumber=1
> 
> Quoting from that article, Justin Sykes from Micron Technologies stated:
> 
> 	"NAND [flash memory] fundamentally has native 4K block
> 	sizes. Anything that's not aligned to a 4K block creates extra
> 	challenges," Sykes said. "There ends up being background
> 	operations to garbage-collect that empty space [in larger file
> 	blocks] that isn't fully utilized. And, so that activity is
> 	chewing up your bandwidth in the background, and it adds extra
> 	wear to the NAND [flash memory]."
> 
> I fully expect that perhaps someone from San Disk or Intel will pop up
> and say that "this is just Micron's SSD's suck; *our* SSD's won't have
> this problem".  Perhaps; but HDD's won't be going away any time soon[1],
> and they will be moving to a 4k block size in the next few years.
> 
> So what's the problem?   The main problem seems to be that by default,
> we are using partition tables that cause the partitions to be not
> aligned on 4k boudaries, because of the default hdd geometry used by our
> partition tools and returned by the HDIO_GETGEO ioctl:
> 
> Disk /dev/sda: 255 heads, 63 sectors, 38913 cylinders
> 
> Nr AF  Hd Sec  Cyl  Hd Sec  Cyl     Start      Size ID
>  1 80   1   1    0 254  63  121         63    1959867 83
>  2 00   0   1  122 254  63  619    1959930    8000370 82
>  3 00   0   1  620 254  63 1023    9960300  615177045 05
>  4 00   0   0    0   0   0    0          0          0 00
>  5 00   1   1  620 254  63 1023         63  615176982 8e
> 
> For pretty much all modern systems --- certainly any drive using the
> SATA interface, the boot loader no longer needs to use the original CHS
> INT13 interface, so what we pick for the CHS geometry doesn't matter as
> far as bootloaders are concerned.  Linux only uses LBA's so the bottom
> line is that aside from controlling the alignment of partitions, CHS's
> don't really matter.
> 
> For SSD's and HDD's that use a 4k internal sector size, being 4k aligned
> makes a big difference because it avoids read-modify-write cycles.  We
> can achieve this easily if we simply use a CHS geometry of 56
> sectors/track instead of 63 sectors.  So, I would propose that we change
> the default geometry used by the partitioning tools in util-linux-ng,
> gparted, etc. so the default sectors is 56; furthermore, to catch those
> partitioning tools that use the HDIO_GETGEO ioctl, that we change the
> fantasy geometry generated in drivers/scsi/scsicam.c:scsicam_bios_param()
> and drivers/ata/libata-scsi.c to also use a 255/56 head/sector geometry.
> 
> Does this make sense?  Am I missing some fatal flaw?  Should I send
> patches?

The fatal flaw is that the C/H/S information is used by the msdos disk
label.  Change it on the fly and existing partition tables don't say
what they previously said (this isn't fatal, since the CHS geometry is
actually encoded in the partition table, so as long as you don't
repartition it's preserved).  The other flaw is that the 255/63/X C/H/S
is carefully crafted to let us limp to a 0.5TiB volume size with dos
labels.  If we change that to 255/56/X we can only limp to about 480GiB
meaning you won't be able to put a dos label on the new 0.5TiB SATA 
drives ... or rather you will (since we just silently truncate), but
you'll be surprised to learn your disk shrunk ...

We think Linux will cope just fine with 4k native sectors, we just
haven't managed to get samples out of the manufacturers yet.  These
disks will also require a different partition label than msdos, but that
won't be a problem since we have a large choice on Linux.

The problems being described all come down to 4k sector disks pretending
to be 512b sector ones so as to remain "compatible" in windows.  In this
case it's hard to prevent a user doing the wrong thing since they
naturally use msdos labels and end up with the misalignment.  Note, we
can't even necessarily tell users to turn off windows compat mode on the
disks because most BIOSs aren't 4k ready and so can't boot properly
unless it's enabled.

It's all a bit of a mess.

James


--
To unsubscribe from this list: send the line "unsubscribe util-linux-ng" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[Index of Archives]     [Netdev]     [Ethernet Bridging]     [Linux Wireless]     [Kernel Newbies]     [Security]     [Linux for Hams]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux RAID]     [Linux Admin]     [Samba]

  Powered by Linux