[Fwd: Re: regarding libata HPA default behavior]

[Scott James Remnant]

-------- Forwarded Message --------
From: Henrique de Moraes Holschuh <hmh at hmh.eng.br>
To: Tejun Heo <htejun at gmail.com>
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
Subject: Re: regarding libata HPA default behavior
Date: Mon, 3 Sep 2007 11:09:33 -0300

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.

> 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.

> 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.

> 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.

-- 
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/567b8421/attachment.sig>