Re: libata: implement on-demand HPA unlocking

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



> better solution because aside from the problems it causes to fakeraid,
> unlocking the HPA defies the relevant standards and will trash whatever

Unlocking the HPA is actually necessary for sanity on a lot of systems
too, and there are really no standards. Remember the primary use of HPA
has actually been to hide most of the disk from buggy BIOSen so that the
OS can then unlock it after the BIOS has stopped looking.

> data the bios is storing there, which is not good either.  Hence why I
> am in favor of the idea of only unlocking the HPA if it is clear that
> the disk was partitioned with a previously broken kernel and so it must

We cannot create a situation where any system that now unlocks the HPA
ceases to do so, that breaks back compat in a potentially catastrophic
way.

> be unlocked to access existing user data.  That is why I like this
> commit, but it misses the mark in raid situations where the MBR is
> visible on the raw disk, but really is supposed to apply to the whole raid.

Probably the fakeraid layers need a way to see the geometry reported
before unlock, then they can make their own decisions. The lock/unlock in
hardware is just a hardware hack. We can still do the unlocking of
hardware and using whatever values we choose in software at different
points.

"Should we unlock" is almost an academic debate given we are the OS and
control the commands sent to the drive anyway.

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


[Index of Archives]     [Linux Filesystems]     [Linux SCSI]     [Linux RAID]     [Git]     [Kernel Newbies]     [Linux Newbie]     [Security]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Samba]     [Device Mapper]

  Powered by Linux