Hey, Phillip. On Thu, Feb 10, 2011 at 01:47:48PM -0500, Phillip Susi wrote: > On 2/10/2011 4:44 AM, Tejun Heo wrote: > > I thought it would be a good and safe compromise for distros which > > don't want to unlock by default but look at where we are. We just > > ended up with failures which are more obscure. Your proposed addition > > will only push things further that direction. It might not > > necessarily be a bad thing. Maybe the level of obscurity then goes > > beyond certain level and we wouldn't have to care about that. > > Exactly. With this additional refinement, it should push the failure > cases so far into the obscure that we don't really need to worry about > it, and there isn't anything that can be done about it anyhow without > causing worse problems. That's a big maybe and the failures would be far more obscure and unpredictable. Think about RAID5. If we're gonna head that way, I would rather just say we're already beyond the necessary obscurity and leave things be. > > But much better solution seems to be exporting the bios size to others > > and letting the ones which understand storage configuration better > > deal with it. At the block or libata layer, we simply don't have > > enough information to make those decisions in a reliable manner. > > Then you are back to doing something that from the perspective of the > standards, the bios, and Windows, is wrong and at least in theory can > cause data loss. Why would that be better than unlocking when there is > good reason to believe that it 1) won't cause data loss, and 2) is > necessary to access user data? But as I wrote before, there are noticeable advantages to unlocking unconditionally - regarding hotplugs, moving hard drives to different machines and general unpredictability of BIOS behaviors, which are far more important than the fringe downsides. Hard drives changing sizes depending on to which machine and when they're connected are simply bad. Confused linux systems are far more grave in my book than confused BIOSen or whatever other operating systems. Besides, as some distros (including ubuntu and openSUSE) are already unlocking hard drives unconditionally, being smarter about auto unlocking doesn't buy us much. We need something which help fakeraid work on those setups. > My personal preference would be to get the HPA and partition table code > out of the kernel entirely and leave it up to udev and friends, which > have the ability to recognize complex situations like the disk being a > fakeraid member, and choose to ignore the partition table on the > underlying disk entirely, but that doesn't seem likely to happen soon. I don't think that's gonna fly. There are cases disks need to be accessed directly by the kernel while userland is still not operational. The suggested solution where disks are always unlocked and the alt size is exported via sysfs allows about the same capability without the downsides of not unlocking HPA. The whole disk is always accessible and userland tools can choose between the two sizes. The problem is updating the tools. Well, we can start by exporting the alt size and not changing unlocking logic for now so that nothing is further broken but the extra information is still available. Down the road, after the tools are all updated, we can flip the switch and unconditionally unlock HPA and kill all the ugly workaround logics. Thanks. -- tejun -- 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
