Programming

Well, you're not doing raw I/O. Really only the kernel can do truly raw I/O, and worrying about write errors is the kernel's job.

If writes don't fail, what about reads? Try reading the data back.

read passes too. It does not return error until the device itself fails.

I just want to catch / count the read / write I/O errors from the program.

With the read atleast i can identify by comparing the data read from the sector to a known pattern of data and if does not match, I can flag the read has failed (round about way!).

yeah. it is not the direct raw i/o, but this is for portability and should work across most of the operating systems.

Unfortunately, AFAIK, the type of raw i/o that you need to meet your requirements is not available at the user level without writing your own device driver. And device drivers by their very nature are not very portable.

thank you.

So, there is no way around it without writing a device driver to handle the read/write operations? Is that right?

I have a utility written in python which able to identify the bad sectors exactly as the same way as the C program. I am not sure, if python would have implemented anything internally (a device driver) to achieve this. I'm currently downloading the python source code to analyse.

I am sure C is more low level then python (which is btw the dumbest statement, i've said ) and should be able to achieve it. It's little weird that the program fails to identify the bad sectors. I have analysed the following programs so far for such an implementation. And all have the same code.

Testdisk, dd, ddrescue, badblocks etc.,.

So does this conclude that the none of the above available usermode linux opensource programs are really doing what they are claiming for? (data recovery / forensics utilities?) All the above program implements O_DIRECT options too.

Well, I guess I am in need of a fix now!

It also sounds a little weird that there are no user mode programs (not even one?) available in linux that can do a direct I/O with the disk. (Except that I am willing to write one using the libata / scsi libraries which can directly talk to the ATA (PATA / SATA) devices using ATA protocol (i've done this in dos using assembly) and SG / SCSI protocol to the scsi devices).

Anyways, thanks for all your input and guidance. Atleast it got me to do the O_DIRECT implementation. Please update this thread if there are any more information to be shared / assisted.

Thanks again for all the help.

The crux is that the kernel doesn't do reads when or how you tell it to. It might bundle it with other reads, feed you data from cache, or make you wait until other reads are done. It may have to do a little or a lot of translation between the device and you. This is true for most multitasking operating systems.

Have you tried doing reads?

it may also be using linux's ancient, soon-to-be-removed obsolete and unportable raw system.

---------- Post updated at 05:21 PM ---------- Previous update was at 05:19 PM ----------

Most of data forensics is reading. Writing to an iffy disk is a very silly thing to do.

Yes. I have tried the read call. It does not return a failure for the read operation on bad sectors.

It returns success. It says it had read the amount of data I request for.

The only way I can identify the error is when I try to compare / analyse the read data with the known pattern.

Thank you.

Another problem is that a failed read can take forever and a day. Most drive access is asynchronous, meaning the drive returns data whenever it feels like it, and can grind for minutes when it hits a sector it doesn't like.

Try getting rid of the cache for that disk with the posix_fadvise function. It might just be returning cache, even with O_DIRECT.