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
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
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
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
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
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
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
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
On Mon, Nov 27, 2006 at 01:30:44PM +, Alan wrote:
> HPA has nothign to do with sector remapping.
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
It appears, as if the drive is really approaching breakdown,
remapping bad sectors and is out of spare sectors. Thus
reducing capacity. The call to determine the native
sectors seems to still count in those remapped sectors,
yielding an effectively bogus number.
Perhaps the drive had
It appears, as if the drive is really approaching breakdown,
remapping bad sectors and is out of spare sectors. Thus
reducing capacity. The call to determine the native
sectors seems to still count in those remapped sectors,
yielding an effectively bogus number.
Perhaps the drive had
On Mon, Nov 27, 2006 at 01:30:44PM +, Alan wrote:
HPA has nothign to do with sector remapping.
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
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
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
14 matches
Mail list logo
