Re: Allow turning off hpa-checking.
Just a Thank you & EOThread message :-) On Tue, Nov 28, 2006 at 09:24:15PM +0900, Tejun Heo wrote: > Dunno about IDE layer. It has been done that way for long time and not > sure whether adding such option will happen, but for libata, hpa > handling is still not implemented ... I'm now (since 2.6.19) happily using libata instead of ide on that machine, no longer need to apply extra patches and will do so until the harddisk finally dies. > and it will have to be optional when > it gets implemented. So, libata will have such option when it finally > receives implementation for hpa handling. Glad to read that. Thanks for all the patience with me. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Allow turning off hpa-checking.
Andreas Leitgeb wrote: [--snip--] This theory is backed by my observation of a nearly-broken disk, that the quantity "3)" gradually goes down one step after some time. The first such step was, when I noticed the problem about half a year ago, and just recently it stepped down by another one. Okay, if that happens on your drive, you gotta burn that foul thing and run away as fast/far away as you can. ;-) [--snip--] The point I'm really trying to make is, that there should be a boot option, to disable the query for "1)". This *must* be a boot option, because the querying that I want to be able to prevent happens at boot time. My broken drive surely doesn't justify the option (or even this thread), but the third one of the "uses for 3)" mentioned above does. Once the native size is read, I no longer know how many sectors were previously "hidden away" by HPA, except by checking the kernel-log. While Alan has already said, why he thought that this was the wrong approach, the reasoning was based on a misunderstanding of my question, which I here tried to clear up. Dunno about IDE layer. It has been done that way for long time and not sure whether adding such option will happen, but for libata, hpa handling is still not implemented and it will have to be optional when it gets implemented. So, libata will have such option when it finally receives implementation for hpa handling. -- tejun - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Allow turning off hpa-checking.
It seems I was too eagerly deleting context from my mails. This made people misunderstand my questions or answer details that have been clarified in previous mails already. I did learn quite a lot already about harddisks during this thread. "Thank you" to Alan. In particular, about the quantities involved: 1 2 +-+---+ ^-3 There is 1) the "native" size of the disk: strictly constant 2) the spare sectors for remapping bad ones. (not included in 1) 3) An arbitrary quantity, being what the drive advertises as size. Bios thinks 3) is the disks total size. So does Linux before the hpa-check. During that "hpa-check", Linux queries the quantity "1)", which is indeed the disks (constant) size. There seem to be many (in some way conflicting) uses for "3)": - fool the BIOS: because bioses might get upset for too large disks. - fool some old OS: because the OS might get upset ---"--- - reserve some sectors for some non-volatile data hidden to certain systems e.g. for "nanny the user"-purposes. This thread is (for one part) about another appearant use of "3)", namely by the drive to tell that "2)" is exhausted, and less than "1)" sectors are left usable. So quantity "3)" is set to the number of actually physically remaining sectors. This theory is backed by my observation of a nearly-broken disk, that the quantity "3)" gradually goes down one step after some time. The first such step was, when I noticed the problem about half a year ago, and just recently it stepped down by another one. Linux queries the real size "1)", gets read errors on the last two sectors and consequencially turns off dma making the machine awfully slow. But this is not a kernel's problem, because really the disk should be replaced (it doesn't contain precious data, so I keep watching its degrade, till it no longer does anything). The point I'm really trying to make is, that there should be a boot option, to disable the query for "1)". This *must* be a boot option, because the querying that I want to be able to prevent happens at boot time. My broken drive surely doesn't justify the option (or even this thread), but the third one of the "uses for 3)" mentioned above does. Once the native size is read, I no longer know how many sectors were previously "hidden away" by HPA, except by checking the kernel-log. While Alan has already said, why he thought that this was the wrong approach, the reasoning was based on a misunderstanding of my question, which I here tried to clear up. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Allow turning off hpa-checking.
Andreas Leitgeb wrote: On Mon, Nov 27, 2006 at 07:59:40PM +, Alan wrote: size remains still constant, and the exceeding damaged sectors are auto-"hidden" by the drive by means of HPA. Still incorrect? Still incorrect. HPA has nothing to do with damaged sectors. The damaged sectors are replaced from a pool of sectors that are reserved for this purpose. Please re-read my previous mail. I *explicitly* wrote that I'm talking about drives, whose "reserved pool of extra/spare sectors" was already exhausted. Considering that: still incorrect? Yeap, if the drive has run out of spare sectors, bad sectors will no longer get better after being written to. The drive will *never* *ever* get shorter. -- tejun - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Allow turning off hpa-checking.
On Mon, Nov 27, 2006 at 07:59:40PM +, Alan wrote: > > size remains still constant, and the exceeding damaged sectors are > > auto-"hidden" by the drive by means of HPA. > > Still incorrect? > Still incorrect. HPA has nothing to do with damaged sectors. The damaged > sectors are replaced from a pool of sectors that are reserved for this > purpose. Please re-read my previous mail. I *explicitly* wrote that I'm talking about drives, whose "reserved pool of extra/spare sectors" was already exhausted. Considering that: still incorrect? - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Allow turning off hpa-checking.
> size remains still constant, and the exceeding damaged sectors are > auto-"hidden" by the drive by means of HPA. > > Still incorrect? Still incorrect. HPA has nothing to do with damaged sectors. The damaged sectors are replaced from a pool of sectors that are reserved for this purpose. Alan - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Allow turning off hpa-checking.
On Mon, Nov 27, 2006 at 06:10:33PM +, Alan wrote: > > What else (if not sector remapping) could make the "current" > > size gradually smaller between reboots. And why is "native" > > size still constant? And why does now even access to the but-last > > native sector fail? The explanation with block-reads no longer > > works. > The presented size of an ATA disk is constant. It keeps additional space > for error blocks. The HPA merely tells the disk to lie about its size. I was speaking about a disk, whose "additional space" appeared to be already exhausted. After that, it appears as if the native size remains still constant, and the exceeding damaged sectors are auto-"hidden" by the drive by means of HPA. Still incorrect? Then I'm also speaking about not-broken disks, where I just want to be able to tell the driver to believe the drive's "HPA-lie" for whatever reason :-) > > How should the partitioning tool know, if I want to ignore the > > HPA, or respect it (knowing it contains stuff that I might need in > > future). Does there exist any that asks me? > I have no idea. If not perhaps one should be written. Till that happens ... ;-) - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Allow turning off hpa-checking.
> What else (if not sector remapping) could make the "current" > size gradually smaller between reboots. And why is "native" > size still constant? And why does now even access to the but-last > native sector fail? The explanation with block-reads no longer > works. The presented size of an ATA disk is constant. It keeps additional space for error blocks. The HPA merely tells the disk to lie about its size. > > This is a matter for the partitioning tool. You don't know at boot time > > what you wish to do with the HPA so a boot option is inappropriate. > > If I boot linux (e.g. from CD) on some precious windows-machine, > I do know that at boot time. Ditto if I connect a foreign > windows-disk in my machine (ata is afaik not yet hot-pluggable), > I'm also bound to know that at boot time. Some ATA is hot pluggable. The new libata stuff very much so (although it at the moment doesn't handle HPA) > There are also user-land tools (using ioctl) to manipulate > this, in case I change my mind lateron. > > How should the partitioning tool know, if I want to ignore the > HPA, or respect it (knowing it contains stuff that I might need in > future). Does there exist any that asks me? I have no idea. If not perhaps one should be written. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Allow turning off hpa-checking.
On Mon, Nov 27, 2006 at 04:33:28PM +, Alan wrote: > > So after real remaining capacity has dropped > > below original capacity, querying the "native" size still > > returns the original size, which is no longer physically > > backed. > This is incorrect. Please, also give some hints, what actually falsifies my observation-based speculations. I surely don't insist in them being accurate, but I try to understand what's really going on. What else (if not sector remapping) could make the "current" size gradually smaller between reboots. And why is "native" size still constant? And why does now even access to the but-last native sector fail? The explanation with block-reads no longer works. > This is a matter for the partitioning tool. You don't know at boot time > what you wish to do with the HPA so a boot option is inappropriate. If I boot linux (e.g. from CD) on some precious windows-machine, I do know that at boot time. Ditto if I connect a foreign windows-disk in my machine (ata is afaik not yet hot-pluggable), I'm also bound to know that at boot time. There are also user-land tools (using ioctl) to manipulate this, in case I change my mind lateron. How should the partitioning tool know, if I want to ignore the HPA, or respect it (knowing it contains stuff that I might need in future). Does there exist any that asks me? - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Allow turning off hpa-checking.
> What the drive reports as "native" capacity indeed does > *not* take into (negative-)account those sectors, that have > been remapped. So after real remaining capacity has dropped > below original capacity, querying the "native" size still > returns the original size, which is no longer physically > backed. This is incorrect. > I ask for a module/boot-option to allow to skip hpa-checks > generally, or even for specific drives - to be used, if one > needs to be sure that these reserved sectors of a connected > drive are not going to be touched, even when re-partitioning > the disk. Afterall that's why they are reserved in the > first place. This is a matter for the partitioning tool. You don't know at boot time what you wish to do with the HPA so a boot option is inappropriate. Alan - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
