#9 stat.st_blksize does not return hw blocksize. use blockdev instead

[JPT]

man 2 stat says:

The st_blksize field gives the "preferred" blocksize for efficient filesystem I/O. (Writing to a file in smaller chunks may cause an inefficient read-modify-rewrite.)

There is nothing that mentions it was returning the hardware blocksize. Which actually it isn't for floppy drives.

man blockdev says

--getiomin Get minimum I/O size.

$ sudo blockdev --getiomin /dev/sdf
512

This was for a Superfloppy drive (same for disks up to 1.5TB)
I have to check the result on normal floppy drives and huge disks.
Haven't any available right now.

If you have time, could you please look for a solution?
I will continue working on it in the next days.

I should check how you actually do the reading and why it cannot read single sectors even if blocksize is forced to 512.

see also https://sourceforge.net/p/safecopy/discussion/472935/thread/1b22c0c2/

[Eric Price]

if the blocksize is forced to 512, safecopy seek()'s and read()'s data in 512 byte chunks, just as if stat() had reported 512 byte. If it still cannot access that data, then because on kernel level the actual low level driver uses smallest chunks of a bigger size to access the device. It's just a guess, but trying to access the device with the --sync option might possibly have an effect on that. I don't remember how exactly the linux block IO is implemented on the lower levels and if --sync disables buffering even below the block size used in the kernel.

[JPT]

Thanks.
using -b 512 did not help, the bad areas stayed at size 4k.
but --sync -b 512 worked.

Could you please add a hint about this to the man page?

My safecopy 1.6 man page says:

--sync
Use synchronized read calls (disable driver buffering).
Safecopy will use O_DIRECT if supported by the operating system and O_SYNC otherwise.
Default: Asynchronous read buffering.

Which didn't tell me anything, because I didn't know what DIRECT and SYNC means.