Here is a useful link when using UBI:FS, but as it's the official documentation, you've probably already read it.
The first thing to know is that UBI behavior depends on MTD, which rely on your NAND controller driver. I will try to answer using NAND flash requirements, MTD ones and UBI ones.
According to NAND datasheets, (here, I have a Toshiba SLC NAND, 8-bits ECC, but it's a common recommendation amongst Micron, Hynix, Samsung), if a block erase fails, the block should be marked as bad. If a page write fails, the block should be marked as bad. The definition of "fails" evolved with technology. With 4 and 8 bits ECC Flashs, it is common to have some bits sticked to 0 or 1. A write is commonly regarded as OK if, when reading the page just after the write, there is strictly less bitflips than acceptable. You may choose also to reduce your acceptance threshold to improve robustness, but being to restrictive restricts the number of blocks you use, and reduce the life length of your part, as wear is leveled on less blocks, and blocks are marked bad sooner.
Read disturb may also happen later. NAND flashs are made with floating gate transistors, which may discharge over time, or due to the activity on the current page, or even the other pages of the block. This is a known behavior of the NAND flash, and this is why flash filesystems should read every data often: to detect when some pages reach the maximum number of correctable bitflips. In such case, the page should be relocated, but the block isn't bad.
You may also get traces if ECC correction happen, even if this doesn't trigger the relocation. It depends on your driver.
And, at last, an erase page may contain some bits sticked to 0. In that case, ECC correction on read fails, while the page is OK. To avoid this issue, there is often a "page written" market added in the spare area, bigger than 2 times the maximum bitflips number for the NAND, which allow to ignore ECC errors on unwritten pages. In this case, your driver may fix bitflips before returning the page to the upper layers, resulting in a "read disturb" notice and no error reports to the upper layer.
As you may see, the behavior mainly depends on your NAND controller driver. Maybe your driver is open-source ? This would allow to get the actual behavior.
I can't speak to FreeRTOS f_read() call, but for some operating systems, f_read() can only read up the the boundary of the sector size of the underlying media, typically 512 or 2048 bytes. To read more data than that, the f_read() call would need to implement a gather function, reading data from multiple sectors.
We've seen this behavior in nuttx, and I suspect FreeRTOS does the same. To read a larger file, try reading it in blocks sized to your media.
Best Answer
FATFS is a bad choice to use directly on a flash chip without any intermediate translation layer, as writing the FAT will overwrite the same sector again and again, causing these cells to wear out quickly.
You cannot reliably determine whether a certain block has been erased. If it reads back as only ones, the chance is fairly high that this is an empty, usable block, but it could also be a block that was in the process of being erased when the power went out, so some of the bits might be unstable. A flash file system should be aware of this, and explicitly mark blocks it has successfully erased with a specific marker.
The only way to be sure is to either perform an erase immediately before, or to have a note somewhere that a certain block has been erased.
You will erase the entire block, which contains 8 sectors. If any of these sectors already contains data, it will be erased as well, which you want to avoid.
As said, FAT is not suitable for use in this way.