Introduced cache_size as alternative to hardware read/write sizes

The introduction of an explicit cache_size configuration allows
customization of the cache buffers independently from the hardware
read/write sizes.

This has been one of littlefs's main handicaps. Without a distinction
between cache units and hardware limitations, littlefs isn't able to
read or program _less_ than the cache size. This leads to the
counter-intuitive case where larger cache sizes can actually be harmful,
since larger read/prog sizes require sending more data over the bus if
we're only accessing a small set of data (for example the CTZ skip-list
traversal).

This is compounded with metadata logging, since a large program size
limits the number of commits we can write out in a single metadata
block. It really doesn't make sense to link program size + cache
size here.

With a separate cache_size configuration, we can be much smarter about
what we actually read/write from disk.

This also simplifies cache handling a bit. Before there were two
possible cache sizes, but these were rarely used. Note that the
cache_size is NOT written to the superblock and can be freely changed
without breaking backwards compatibility.

1 files changed, 5 insertions, 1 deletions

diff --git a/lfs_util.h b/lfs_util.h
index 6a577eb..6dd28da 100644
--- a/lfs_util.h
+++ b/lfs_util.h
@@ -183,8 +183,12 @@ static inline uint16_t lfs_tole16(uint16_t a) {
 }
 
 // Align to nearest multiple of a size
+static inline uint32_t lfs_aligndown(uint32_t a, uint32_t alignment) {
+    return a - (a % alignment);
+}
+
 static inline uint32_t lfs_alignup(uint32_t a, uint32_t alignment) {
-    return (a + alignment-1) - ((a + alignment-1) % alignment);
+    return lfs_aligndown(a + alignment-1, alignment);
 }
 
 // Calculate CRC-32 with polynomial = 0x04c11db7