On Mon, 2009-03-16 at 10:51 -0400, Greg Freemyer wrote: > On Thu, Feb 26, 2009 at 5:02 PM, H. Peter Anvin <hpa@xxxxxxxxx> wrote: > > Martin K. Petersen wrote: > >>>>>>> > >>>>>>> "hpa" == H Peter Anvin <hpa@xxxxxxxxx> writes: > >> > >>>> Quick answer from one of my contacts. Desktop drives will indeed > >>>> ship with an alignment of 1(*). The alignment is hardwired at time > >>>> of manufacture and can't be changed. > >>>> > >> > >> hpa> Oh God. > >> > >> hpa> This is a disaster. > >> > >> Rationale being that modern Microsoft operating systems know how to > >> interpret the alignment bits. Legacy XP will work without changes > >> thanks to the shifted alignment. And Vista+ will do the right thing to > >> align partition 1 to what the drive reports. > >> > >> Also note that Windows only aligns the first partition. That's > >> something we need to be aware of when setting up dual boot systems. > >> > > > > Yeah, but all of this completely breaks the disk image abstraction, which is > > a very powerful paradigm. > > > > -hpa > > > If the reported geometry of these drives was changed to have sectors / > track be a multiple of 8, wouldn't that fix most of the issues. > > ie. If the drive were to report 56 sectors per track, then a > traditional partitioning tool would start the first partition as > sector 56 and a Vista like partitioning tool would place the first > partition at sector 2048. Both would have the same 4K sector > alignment. > > If my logic is sound, anyway to get this recommendation upstream to > hardware manufacturers. It seems like an almost trivial change for > them. This is Ted Ts'o's proposed fix for the problem as well ... we do the C/H/S translation in scsicam.c and it's then stored in the DOS partition label. The only problems are that changing this on the fly might be problematic for things that believe scsicam_bios_param without first checking the DOS label (because they'll then be mismatched). And also, if the vendors use their power to offset the first 4k block, we'll be mismatched again. Plus, once the values are written in the label we can't update them. > FYI: It sounds to me like partitioning tools should totally drop > efforts to align with cylinders, instead they should start asking what > the unit of atomic read/writes is at the physical layer and if any > offsets are needed to align the partition with the atomic write areas. > > That would fit better for both SSD technology and for this 4K sectors > issue than trying to continue to support cylinders at all. The DOS label is the problematic one ... all the rest have (mostly) more sensible schemes. The problem is that the DOS label is the most prevalent one. James -- To unsubscribe from this list: send the line "unsubscribe linux-ide" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
