[Fwd: Re: regarding libata HPA default behavior]

[Scott James Remnant]

-------- Forwarded Message --------
From: Tejun Heo <htejun at gmail.com>
To: Henrique de Moraes Holschuh <hmh at hmh.eng.br>
Cc: Dave Jones <davej at redhat.com>, Jeff Garzik <jgarzik at pobox.com>, Alan
Cox <alan at lxorguk.ukuu.org.uk>, scott at ubuntu.com,
lcapitulino at mandriva.com.br, Hannes Reinecke <hare at suse.de>
Subject: Re: regarding libata HPA default behavior
Date: Tue, 04 Sep 2007 00:56:23 +0900

Henrique de Moraes Holschuh wrote:
> On Mon, 03 Sep 2007, Tejun Heo wrote:
>> The upcoming version of openSUSE is switching over to libata completely
>> and it seems we have some problems with backward compatibility.
>> Mainline libata defaults to not unlocking HPA and we can't change that
>> easily as it breaks compatibility with older libata.  Unfortunately, not
>> unlocking HPA breaks compatibility with IDE drivers.
> 
> Well, since any moves to libata also change from hd* to sd* in Debian, I
> figure we would just document the issue, and tell users how to switch the
> HPA on or off.  I didn't hear of any other plans (or any plan at all,
> actually) so far.
> 
> Documenting the issues requires a warning to the users well in advance, and
> also a very easy way to tell the kernel to unlock the HPA in the command
> line, or somesuch.  Maybe even asking about it on upgrade, and adding that
> command line at that time.

I see.  In SUSE, the biggest headache is that currently there's no way
to dynamically unlock HPA and the partition tool just reports that the
partition table is invalid (reaches outside the end of the device) and
gives up.  We can instruct the user to retry with libata.ignore_hpa=1
but it can be pretty annoying.

>> SUSE is leaning toward unlocking HPA by default as not being able to
> 
> What is the effect in a md volume (and other in-kernel stuff that likes to
> place critical information at the end of a partition/device) that was made
> with the HPA active, when you disable the HPA? If it is "none", then IMO we
> should just unlock the HPA by default in the kernel and be done with that.

I'm not really sure but I bet some of those formats use the end address
as addressing reference.

>> The best way out would be being able to detect whether the current
>> on-disk format requires HPA unlocking and unlock automatically if
>> necessary.  Implementing kernel side of it shouldn't be too difficult
> 
> That is nice as an added sanity check, as long as one can turn it off on the
> kernel command line.  But as you said, it will not cover every scenario.

Yeap.

>> I think it would be nice to have a unified front on this problem as
>> mixing one behavior with the other can be disorienting and there's
>> possibility of mass data loss.  So, how are you guys dealing with this
>> problem?
> 
> Frankly, I don't think anyone in Debian gave any thought to the matter yet,
> but I would be happy to start one of those massive threads in debian-devel
> about it if you want.

The thing is that I'm not really sure what we should do with HPA from
now on.  In the past, unlocking HPA and use the area by default made
sense because in many cases HPA was used to trick dumb BIOSen to work
with large drives and as such unlocking HPA was necessary to use such
devices properly but that isn't the case anymore and the ATA standard
specifically states that HPA is only for system firmware and OS is
supposed to leave it alone.  I wouldn't be too surprised if some
odd-clown xACPI implementation depends on HPA to be in certain state
when it's asked to suspend, shutdown or whatever.

An interesting result of recent reduced popularity of HPA is that we
seem to have more SATA devices which have trouble supporting HPA feature
set (times out on READ_NATIVE_MAX) than PATA ones.

We definitely need to discuss what to do with HPA in the future.  If we
decide to move away from unlocking HPA, ide -> libata transition is
probably a pretty good chance to do it.  Please feel free to start
public discussion - be it debian-devel or linux-ide.  I didn't cc
linux-ide on this thread only because I didn't know how relevant the
discussion would be but if we're gonna discuss general future direction
about HPA, it's certainly relevant.

Thanks.

PS. I won't be able to get online for a few days from now.

-- 
Scott James Remnant
Ubuntu Development Manager
scott at ubuntu.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
URL: <https://lists.ubuntu.com/archives/kernel-team/attachments/20070903/9c56d51e/attachment.sig>