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

[Andrew Morton]

(lots of cc's added)

On Wed, 3 Mar 2010 23:52:20 -0500 foo saa <foosaa@xxxxxxxxx> wrote:

> hi everyone,
> 
> I am in the process of writing a disk erasure application in C. The
> program does zerofill the drive (Good or Bad) before someone destroys
> it. During the erasure process, I need to record the number of bad
> sectors during the zerofill operation.
> 
> The method used to write to the hdd involves opening the appropriate
> /dev block device using open() call with O_WRONLY flag, start issuing
> write() calls to fill the sectors. A 512 byte buffer filled with
> zero's is used. All calls are of 64bit enabled. (I am using
> _LARGEFILE64_SOURCE define).
> 
> The problem is (mostly with the bad hdd's), when the write call
> encounters a bad sector, it takes a bit longer than usual and writes
> the sector without any errors. (dmesg shows a lot of error messages
> embedded in the LIBATA error handling code!). The call never fails for
> any reason.
> 
> I am using 2.6.27-7-generic  and gcc version 4.3.2  on ubuntu 8.10. I
> have tried upto 2.6.30.10 and multiple distros with similar behavior.
> 
> Here is a summary of things I have attempted.
> 
> I know about the bad sector and it's location on the hdd, since it has
> been verified by using Windows based hex editor utilities, DOS based
> erasure applications, MHDD and many other HDD utilities.
> 
> I have tried using O_DIRECT with aligned buffers, but still could not
> identify the bad sectors during the writing process.
> 
> I have tried using fadvise, posix_fadvise functions to get of the
> caching, but still failed.
> 
> I have tried using SG_IO and SAT translation (direct ATA commands with
> device addressing) and it fails too. Raw devices is out of question
> now.
> 
> The libata is not letting / informing the user mode program (executing
> under root) about the media / write errors / bad blocks and failures,
> though it notifies the kernel and logs to syslog. It also tries to
> reallocate, softreset, hardreset the block device which is evident
> from the dmesg logs.
> 
> What has to be done for my program to identify / receive the bad block
> / sector information during the read / write process?
> 
> How can I receive the bad sector / physical and media write errors in
> my program? This is my only requirement and question.
> 
> I am currently out of options unless anyone from here can show some
> new direction!
> 
> My only option is to recompile the kernel with libata customization
> and changes according to my requirement. (Can I instruct to libata to
> skip the error handling process and pass certain errors to my
> program?).
> 
> Is this a good approach and recommended one? If not what should be
> done to achieve it? If yes, can somebody throw some light on it?
> 
> Please let me know if you have any queries in my above explanation.
> 

OK, this is bad.

Did you try running fsync() after a write(), check the return value?

I doubt if this is a VFS bug.  As O_DIRECT writes are also failing to
report errors, I'd suspect that the driver or block layers really are
failing to propagate the error back.

Do the ata guys know of a way of deliberately injecting errors to test
these codepaths?  If we don't have that, something using the
fault-injection code would be nice.  As low-level as possible,
preferably at interrupt time.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/