Hi @Jason2866,
With implementation of checking sd_status the reading speeds got a lot slower. Thats because the sd_status check is called every read(). So an example if you want to read 512 bytes of data FILE.read(buf,512); without PR #6456 the fread() will internally call read() for every 128 bytes of data. So the sd_status is called 4 times for chunk of 512 bytes. If we call directly once read() the sd_status is called only once. So for bigger chunks of data its a huge speed improvement. See table below.
With that to improve the speed the most, I implemented the read() to be called when chunks are bigger than 128 bytes (file internal buffer size).

I tested reading different chunks of data to test switching between fread() and read() and I got every time the right data.

But its good that we released the 2.0.3-RC1 and all of you are testing that. I can say that the SDWebServer is not working with switching between read/fread or only when using read(). Its works only with fread() (the previous implementation). I'm testing and sorting out why its not working at all.

I will appriciate any advices or test cases/sketches to be able to test more scenarios.

Answer for @s-hadinger comment in PR. To be able to discuss everything in one place :)

Scenario 1:
open file
read 128 bytes
read 128 bytes
close

# bytes('504B03040A0000000000B8B8755431C19D1968000000680000000B001C006175...')
# bytes('6C6174696E312873697A6529600A0A696D706F727420726F626F746F636F6E64...')

Scenario 2:
open file
read 128 bytes
read 256 bytes
close

# bytes('504B03040A0000000000B8B8755431C19D1968000000680000000B001C006175...')
# bytes('1300207C9004822410900F1004C170003804E626822258748689F0180000200C...')

In scenario 2, the second read of 256 bytes following the first read of 128 bytes provides wrong content
Edit: the second read for 256 bytes actually starts at offset 0x1000 in the file, instead of offset 0x80. I do see a crash later as a hint of corrupt memory.

I have tested this in Arduino and I don't get wrong results as you did, everything is good.

Scenario 1 - read 128 + read 128

bytes('89504E47DA1AA000D49484452003580015A86...')
bytes('9DB367EF3B37EF97FFB9EFE6FF7D2FDF39170C...')

Scenario 2 - read 128 + read 256

bytes('89504E47DA1AA000D49484452003580015A86...')
bytes('9DB367EF3B37EF97FFB9EFE6FF7D2FDF39170C...')

I have some questions:

• __fpending(_f); is normally for the output buffer, not the input buffer. Am I missing something?
• lseek(fileno(_f),(-128+bytesinbuf),SEEK_CUR); why is the file seeked 128 bytes ahead of bytesinbuf? Are we even sure that >bytesinbuf is always greater than 128? If not the substraction is invalid and yields to an overflow.

1. __fpending(_f); - It actually checks how many bytes are in buffer no matter if reading or writing. I need to check the buffer when switching from fread to read. Because fread always read in 128 bytes chunks so if you want to read 200 bytes, it will read 256 and store the 56 left in the buffer so if you call fread again, it will be fastly reader from internal buffer.
   But that's the point where can be a problem when switching to read when bytes are stuck in buffer.
   the read.

I will give a great example - Thanks to @igrr

Now imagine you call fread to read 16 bytes, then call read to read 512 bytes.

1. fread sees that the buffer is empty, calls read and gets 128 bytes, puts them into the FILE* internal buffer
2. fread takes 16 bytes from the internal buffer and returns them to the caller. Then it adjusts the read pointer of the internal buffer.
3. Next, read is called to read 512 bytes. It reads directly from the file, since it doesn't know anything about FILE* internal buffer (it is a lower level function). These 512 bytes are returned to the caller.

So as a result, the first call reads bytes 0-15 from the file, and the next call reads bytes 128-667 from the file, instead of 16-571. Bytes 16-255 are still stuck in FILE* internal buffer.

You can only call read if you have made sure there are no bytes left in the internal buffer of FILE*.
--> Thats why I am clearing the internal buffer by fpurge() and setting the pointer back for number bytes with lseek(fileno(_f),(-128+bytesinbuf),SEEK_CUR); that have been already read and stored in internal buffer by fread() and cleared before read() so they can be read again by read()

I have tested different scenarios where its switches between fread and read and checked what's happening inside buffer and adjusting the pointer. Everything worked fine and I get the right data.

The table below show how bytesinbuf and pointer behave. The read 512 is the only one called that call read directly (size > 128)

2. • lseek(fileno(_f),(-128+bytesinbuf),SEEK_CUR); I can edit that to always check the size of the buffer first. But for me I always had 128 bytes buffer.