Re: Linux kernel - Libata bad block error handling to user mode program

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

 



Had some issues with the libata in 2.6.27 kernel's libata code, but
believe the issues were fixed in the subsequent versions. Atleast one
prominent issue was with a Western Digital HDD of 40 GB size. The
manufacturer specific LBA was 78125000 and was reported as correctly
in Win32 and DOS applications. But the 2.6.27 kernel was reporting
~40000 sectors more. But the problem dissappeared with the 2.6.3x
kernel and I did not bother to check the patches due to lack of time.
But still, the write's failure is not being seen by the application. I
can understand the fact of not checking the media errors during the
write operation, and had posted a request for a quick suggestions of
the locations which needs to be changed / checked for the return
value. ( Should it be handled at the vfs or at the libata code?). Will
surely update the testing results with the new kernel (Well, not
exactly as I am not using the latest version though! Currently trying
with 2.6.31). Thank you all for suggestions.
-
SP

On Thu, Mar 11, 2010 at 1:29 PM, Greg Freemyer <greg.freemyer@xxxxxxxxx> wrote:
>>
>> But really.. isn't "hdparm --security-erase NULL /dev/sdX" good enough ???
>>
>
> This thread seems to have died off.  If there is a real problem, I
> hope it picks back up.
>
> Mark, as to your question the few times I've tried that the bios on
> the test machine blocked the command.  So it may have some specific
> utility, but it's a not a generic solution in my mind.
>
> Greg
>

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@xxxxxxxxxx  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href

[Index of Archives]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [IETF Annouce]     [Bugtraq]     [Linux]     [Linux OMAP]     [Linux MIPS]     [ECOS]     [Asterisk Internet PBX]     [Linux API]