ATA 4 KiB sector issues.
in [Kernel]
|
Prev: linux-next: build failure after merge of the scsi-post-merge final tree
Next: [PATCH] scripts/kernel-doc: fix empty function description section
From: Tejun Heo on 15 Mar 2010 22:40 Aieee... critical typo. On 03/16/2010 11:30 AM, Tejun Heo wrote: > partition table which some BIOSs actually try to do. The problem is > that to determine the two parameters you need to equations matching ^^ two > CHSs and LBAs -- tejun -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: James Bottomley on 16 Mar 2010 02:20 On Tue, 2010-03-16 at 11:30 +0900, Tejun Heo wrote: > Hello, > > On 03/10/2010 06:14 PM, Denys Vlasenko wrote: > > 63s/255h is more or less "standard" now. > > > > Alignment issues can be solved by picking a good multiple of > > _heads_ or _cylinders_: > > I've got a couple of comments stating that picking a good geometry > parameters can resolve the whole issue but I simply fail to see how it > could. We can pick any parameter we wish, but there is no reliable > way to communicate the custom geometry parameters to others. > > Geometry is determined by two parameters sec/trk and heads/cyl. You > can punch in those numbers if the BIOS has a menu for it (many don't > these days). Or hope that BIOS can somehow figure it out from the > partition table which some BIOSs actually try to do. The problem is > that to determine the two parameters you need to equations matching > CHSs and LBAs and that's available iff the first partition ends before > CHS addressing limit according to the custom geometry, which usually > is not the case. > > So, custom geometry is only useful to trick partitioners which align > using cylinders into using better alignments but doesn't help anything > for compatibility as no one can determine the used geometry reliably > after the partitioning is complete. With compatibility benefit gone, > there simply is no reason to stick to the cylinder abstraction at all. > > Am I missing something? Sort of. As you say, C/H/S doesn't exist for any modern disk. However, the msdos label, for reasons lost in the mists of time, uses cylinders as the units of partition boundaries, so we have to invent a bogus C/H/S geometry for that partition label. Because of the problems with picking C/H/S, most boot loaders take care to ensure that BIOS never cares about it either (by using the block offset I/O routines), so for most linux bootloaders, the BIOS problems with C/H/S is a red herring. So, it is true to say that picking a certain H/S geometry (which is entirely withing the gift of the partitioner) will align msdos label partitions, but will be don't care for all other labels: all other partition labels (like gpt) use block as offset and don't have any truck with the fictitious C/H/S stuff. The big problem is that 99% of the x86 systems out there still use the ancient msdos label for their boot disks, so aligning H/S going forwards will give us a nice "just works" for x86 boxes. James -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Tejun Heo on 16 Mar 2010 02:30 Hello, James. On 03/16/2010 03:14 PM, James Bottomley wrote: > So, it is true to say that picking a certain H/S geometry (which is > entirely withing the gift of the partitioner) will align msdos label > partitions, but will be don't care for all other labels: all other > partition labels (like gpt) use block as offset and don't have any truck > with the fictitious C/H/S stuff. For any modern Linux and Windows, CHS simply doesn't matter. They don't look at it at all. > The big problem is that 99% of the x86 systems out there still use the > ancient msdos label for their boot disks, so aligning H/S going forwards > will give us a nice "just works" for x86 boxes. What I don't get is that how picking up a custom geometry can make things work when there is *no* reliable way to determine which geometry was used during partitioning once the partitioning is complete. Most BIOSs these days will simply report the geometry as being 255/63 regardless of the geometry used during partitioning. So, how can using a custom geometry give that nice "just works" for x86 boxes when nobody knows what geometry is in use? Thanks. -- tejun -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Thomas Chou on 16 Mar 2010 02:30 On 03/16/2010 02:14 PM, James Bottomley wrote: > > The big problem is that 99% of the x86 systems out there still use the > ancient msdos label for their boot disks, so aligning H/S going forwards > will give us a nice "just works" for x86 boxes. > > The key issue is not "just work", but "performance". When unaligned, the write performance can be lower than 50% of the expected rate. - Thomas -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: James Bottomley on 16 Mar 2010 09:30
On Tue, 2010-03-16 at 15:22 +0900, Tejun Heo wrote: > Hello, James. > > On 03/16/2010 03:14 PM, James Bottomley wrote: > > So, it is true to say that picking a certain H/S geometry (which is > > entirely withing the gift of the partitioner) will align msdos label > > partitions, but will be don't care for all other labels: all other > > partition labels (like gpt) use block as offset and don't have any truck > > with the fictitious C/H/S stuff. > > For any modern Linux and Windows, CHS simply doesn't matter. They > don't look at it at all. If they have a msdos label, they do. > > The big problem is that 99% of the x86 systems out there still use the > > ancient msdos label for their boot disks, so aligning H/S going forwards > > will give us a nice "just works" for x86 boxes. > > What I don't get is that how picking up a custom geometry can make > things work when there is *no* reliable way to determine which > geometry was used during partitioning once the partitioning is > complete. For msdos labels, it's embedded in the label ... for all other labels, it's made up on the spot. > Most BIOSs these days will simply report the geometry as > being 255/63 regardless of the geometry used during partitioning. So, > how can using a custom geometry give that nice "just works" for x86 > boxes when nobody knows what geometry is in use? Because the msdos label can only partition in units of cylinders. If you're using an msdos label, picking the right H/S gets you alignment. James -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ |