File systems like EXT4 and XFS. Writes blocks to disk (Could be a Hard Disk or a SSD) along with a checksum.
No, neither file system has data checksums.
When Reading back, if checksum fails, read operation will NOT return data and will indicate error or EOF (or no data).
No. As said, no data checksumming is done, but even if it were, there would be no EOF (that would be wrong!) but an error code EIO would be set.
On a re-boot (even if it is after a abrupt shutdown where OS in-memory pages were not flushed), Linux OS checks the integrity of file blocks using checksum.
No. These are journaling file systems and hence, whole-filesystem checksum checks are usually not necessary. Also, as said, there's no data checksums in either file system (there's checksums for the file metadata, at least in XFS)
Also, no, even for the checksums that exist, and even for the file systems that have data checksums, Linux as operating system will not do a whole-volume check. That would take ages, and is something that can very well be left to user land software. It would also, considering the fact that a broken checksum probably means the storage device is beginning to fail, do more harm than good. As said, complete file system checks are very rarely done on modern file systems. Instead, checks on access are common.
and if an application tries to read a file where such error detected blocks are part of it, read operation will fail when the read reaches the afore mentioned block.
no, because no data checksums are present. But let's assume they were:
If the corruption detected(by Linux OS) block is in the middle of a file. Even if subsequent blocks does NOT contain an error, read operation will fail after reaching the corrupted block and application will never be able to read beyond the corrupted block.
No. I don't think Linux nor POSIX make any guarantees on that, and no reasonable file system driver for a file system with data checksums would read 1GB of data to check checksums when you seek to the position after that 1GB. So, your assumption is wrong.
e.g. Let's say file size is 4KB, and block size 1KB. So this file will be spread across 4 blocks A,B,C and D.
Not in detail how XFS works, and usually also not how ext4 works. You might want to look up what extent-based allocation is.
Let's say Linux detected that block C is corrupted.
Again, even if either file system had data checksums, that would only happen the moment C is read. Not earlier.
Now read operation will be able to provide first 2KB from the file.
Why shouldn't you be able to fseek beyond that?
But but there is no way to read last 1KB even if the application place File position after 3KB.
As explained above, that's wrong.
However,
Application does NOT need to place it's own checksum when writing to a file and verify it when reading back (even after a abrupt OS shutdown)
Yes, placing data integrity in the hands of the application instead of the hands of the block device abstraction would be a bad design mistake.
The whole point of a file system is that applications do not need to be aware of the physical medium they store data on. Keeping that abstraction free from leaking the ugly details of the underlying hardware means that the applications cannot be aware of the error probabilities, the kind of errors that can occur, and their position on the physical medium.
All this, however, would be necessary to make a sensible choice on redundancy information.
In short: When using a file system to store data on a block device, it's the block device layer that guarantees data integrity, not the application layer.
Application can assume provided data from read is what it wrote originally and worst thing that can happen is NOT being able to read data from end of the file
Applications Must assume data read from files is correct, otherwise it also couldn't assume the application is correct, or anything else they do is correct. Again, that's a guarantee that the file system offers to the application. You're using a file system, so you assume that.
Is these assumptions wrong (in OS=Linux RedHat Enterprise Linux 8.X and File system=EXT4,XFS context) ? If so kindly please let me know which of them are wrong.
As seen above, basically all your assumptions were wrong :(
