Programming

okey. will try posix_fadvise() now.

You could also see if the position of the file descriptor matches what it ought to be by checking with lseek64.

Just attempting to read a disk sector is completely different than attempting to write a disk sector following by attempting to read the same disk sector. That is why disk vendors have what are typically called low level utilities for bad disk sector scanning and the like.

yep. you are right. For (IDE) PATA / SATA (t13.org) disks there are the ATA / ATAPI standards which specifies how to query the device directly and SCSI has a loads of standards (t10.org) for interfacing with the drives. The ATA part can be easily coded in DOS / FreeDOS with Assembly / C counterparts.

Win32 support is available too for direct querying / interfacing of the devices (with DDK/SDK apis) and device ioctl calls. There are multiple utilities from various HDD vendors which either falls in either of the above two categories (DOS or WINDOWS).

I would like to know if Linux has anything like that? If I call libata calls directly in my program would it allow me to talk to the drive directly? At least for the (IDE) PATA / SATA drives?

Though Linux is programmer friendly, I feel not much control is given to the programmer (well, it also relates to the security feature! and unlike windows, where there are many security exploits / overflows when the kernel address space is hacked from user space leading to privilege escalations, and loads of other issues, not to mention BSOD! ).

I don't know if I am going into a vicious circle of kernel hacking / Linux abuse mode, but I just don't feel some things are right with Linux!

I certainly mean no offense with my above words and for the great minds here. The above words are purely because of my frustration in trying to get the program to work partially at least if not completely.

Now for update:

I have tried posix_fadvise, but the read / write calls are locking up on the bad sectors as said by you.

I have removed the O_DIRECT and using O_WRONLY mode with posix_fadvise on the handle with POSIX_FADV_DONTNEED flag for the entire device starting from sector 0 to (last sector * 512). Is that the right option to be used?

Is there any timeout option that can be set on the Read / Write operations to say to the program / kernel to move on to the next sector / block based on the timeout (time consumed for the current sector)?

I tried with the FDSET , but i believe it is only for socket descriptors and not for file handles. (So dumb of myself! )

Thanks for the replies.

you don't "call" libata. It's a device driver. Au contraire. You can dump ISO images direct from CDROM drives. You can write to memory raw, and talk to raw I/O ports. In windows, this takes a device driver. In Linux, all it needs is device permissions. It's just more generally recognized in UNIX circles that this is a horrible idea in general, while old-fashioned Windows programmers are still reeling from the shock and betrayal of having to give up real mode at gunpoint ;p Tell me, what does raw I/O even mean with a hard drive? Are you going to play with the DMA controller, set up interrupts, and send asynchronous requests yourself? Your idea of "raw I/O" hasn't much to do with what the drive is actually doing. Try the linux kernel mailing list if you're interested in truly raw I/O. Congratulations, it's working. It's not the program that's locking up. The drive itself is trying to read the sector, failing, and taking many minutes of retrying before it gives up and informs the computer it can't. The timeout is in the drive hardware itself. If it's configurable at all it might be one of the many things hdparm can do. Which incidentally might be something interesting to look at the source of for talking to drives on a low level.

Wow! It's all I can say!

That was a fantastic reply straight to temple!

Yup! I read about the Libata stuff implementation and got to know that I cannot implement it in a program as you have pointed out!

You are right. Just that my requirement is to have a raw I/O with the drive, and I don't see a point in kernel to have it as it will not be used by anybody.

And well said about the windows programmers. rofl!! (seriously no offense windows programmers!) (me neither! )

hdparm only works for IDE/SATA drives and on certain systems, it fails to send commands to the HDD. If the drive is in really bad state, i.e., SMART failure is detected and / or if the BIOS restricts certain features based on SMART values (On certain IBM / HP / DELL Systems), hdparm is unable to send commands. And sdparm does not have certain key options for scsi drives as well (such as setting / clearing low level parameters).

Also, according to the ata specifications, timeout would be only for certain operations and ranges in the order of nanaseconds (400ns is default i believe).
And might not work in this case as it has to pass through the kernel / driver layers.

In one of the earlier posts, you pointed out about the option of having a driver for talking to the drives. Is there any generic direction / pointers you can point to or I should start at libata / scsi drivers?

I am extremely grateful for all the help / advice.

I think you're looking at the over-the-cable protocol, not how data is communicated. It's not synchronous -- after all, one seek alone might take considerably longer than 400 nanoseconds. So the computer can tell the drive "do a big DMA transfer and send an interrupt once the data's actually in memory." and the drive will answer in 400 nanoseconds, "OK I will do a big DMA transfer". But the transfer itself can take an unspecified amount of time. I was not being facetous when I suggested the linux kernel mailing list. They'd know far better than we would about low-level I/O.

Yes, hdparm only works for SATA and IDE. You want raw I/O, so you'll have to speak the drive's language.