Actually here are couple of questions regarding to traditional hard disk.
Is every read / write on disk aligned to the system cache / sector size?
Is every file created on disk aligned to sector? I mean, if I create a file, the starting point of the file will be the same as starting point of a sector?
If my sector size is 4096 and I want to read 4096 bytes from position 10 using fseek ( pFile , 10 , SEEK_SET ); so I end up with reading twice?
I don't have time for an extensive answer, so I will be brief:
Disk sector size on modern disks operates at a lower level than is visible to an application; most of the time even the OS can't trust the numbers reported by disks. It is also largely irrelevant to performance.
Assuming a traditional filesystem, the key alignment is between the disk blocksize and the buffercache. This occurs in the OS/filesystem, and the key constraint on you is that all application-level IO-ops are integral numbers of blocks. Understand that while this persists down onto the disk, extents and the elevator can cause operations to be delayed, split, or reordered.
All modern disks have disk-caches, although more advanced ones may be disabled for performance/reliability reasons. Again, mapping from blocks to sector-equivalents and the on-disk elevator can cause delays, splits, merges, and reorderings; however, most of the time you won't need to worry about this. Just make sure the disk doesn't lie about the current status of the write.
In most filesystems files are aligned to blocks. Given 1-block is the minimum read, sector alignment isn't your concern, and you can't do anything about it anyway. Trust the filesystem/io-subsystem to do this appropriately
It is highly unlikely you will end up reading twice if the blocks are contiguous. You will read two blocks, but given the low inter-track seek times, and sequential read speed of the average disk these days, read-ahead has probably read half-dozen blocks for your single block request so the second block is free. Note: This only applies if the blocks are contiguous. Should there be fragmentation you will get a short or long seek, and that will kill your performance if you do it too many times.
If this is important to you, you need to take time to learn about the filesystems you have available; their tuning parameters; and plan your data-structures accordingly. You should probably also parametrize your structures so you can play with slightly different application-level block/read-buffer/write-buffer sizes.
Just Do It the simplest way that works. Complicating things further than that will cost you dearly (in programming, debugging, and maintenance time), and unless measurements show that this is the bottleneck in your system, it is just wasted effort.