[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <1237386819.3350.15.camel@localhost.localdomain>
Date: Wed, 18 Mar 2009 14:33:39 +0000
From: James Bottomley <James.Bottomley@...senPartnership.com>
To: Greg Freemyer <greg.freemyer@...il.com>
Cc: "H. Peter Anvin" <hpa@...or.com>,
"Martin K. Petersen" <martin.petersen@...cle.com>,
Matthew Wilcox <matthew@....cx>, Theodore Tso <tytso@....edu>,
linux-ide@...r.kernel.org, linux-kernel@...r.kernel.org,
sandeen@...hat.com
Subject: Re: ATA support for 4k sector size
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@...or.com> wrote:
> > Martin K. Petersen wrote:
> >>>>>>>
> >>>>>>> "hpa" == H Peter Anvin <hpa@...or.com> 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-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists