[PATCH rtems 0/2] Add Peek Support to libblock and use in dosfs

Christian Mauderer christian.mauderer at embedded-brains.de
Fri Jan 22 13:24:27 UTC 2021


the first patch allows filesystems to have an influence on the read
ahead of libblock. The second one uses it in our FAT implementation
during reads.

I tested the patches on a SD card attached to an i.MX6ULL based system.
To test it I used an empty 16 MB FAT partition. The bdbuf cache in the
test application has been 1MB. First I wrote one big file (which should
have nearly no fragments, because the partition has been empty before
the write) and tested how long it takes to read the entire file. My read
speed increased from 2040 kiByte/s to 2070 kiByte/s for the first read
of the file (about 1.5 percent faster). For all consecutive reads it
increased from about 3230 kiByte/s to 3340 kiByte/s which is 3 to 4
percent faster for all follow up reads.

As a second test I first filled the partition with lots of small
(about 8000 with only a few bytes per file). Then I removed one random
file at a time and filled the space up by attaching data to a big file.
I did that for about a third of the files. With that I created a heavily
fragmented file. Linux "filefrag" tool tells me that my 5.3 MiB file has
2680 fragments which is about 2kiB per fragment.

The read speed for this big fragmented file increased from 2530 kiByte/s
to 2920 kiByte/s for the first read (about 15 percent faster). For
consecutive reads it increased from 2910 kiByte/s to 3170 kiByte/s which
is nearly 9 percent faster.

I didn't analyze why the first read is allways a bit slower. Either for
the consecutive reads some blocks are still in the cache or some
resources are allocated during that time. It's also possible that the SD
card has some internal cache that causes this.

These results have been reached when optimizing BSP, libbsd and
application with -O2. For an unoptimized build (-O0) it was more in the
range of 25 percent faster for a fragmented file.

If the patch set is OK, I'll create a ticket for it (with the
information from this mail) and push it to RTEMS master.

Best regards


More information about the devel mailing list