Github/littlefs
1
Fork 0
Code Actions Activity

Dropped fragmenting blocks > 1 fragment

Browse Source 
So we now keep blocks around until they can be replaced with a single
fragment. This is simpler, cheaper, and reduces the number of commits
needed to graft (though note arbitrary range removals still keep this
unbounded).

---

So, this is a delicate tradeoff.

On one hand, not fully fragmenting blocks risks keeping around bptrs
containing very little data, depending on fragment_size.

On the other hand:

- It's expensive, and disk utilization during random _deletes_ is not
  the biggest of concerns.

  Note our crystallization algorithm should still clean up partial
  blocks _eventually_, so this doesn't really impact random writes.
  The main concerns are lfs3_file_truncate/fruncate, and in the future
  collapserange/punchhole.

- Fragmenting bptrs introduces more commits, which have their own
  prog/erase cost, and it's unclear how this impacts logging operations.

  There's no point in fragmenting blocks at the head of a log if we're
  going to fruncate them eventually.

I figure lets err on minimizing complexity/code size for now, and if
this turns out to be a mistake, we can always revert or introduce
fragmenting >1 fragment blocks as an optional feature in the future.

---

Saves a big chunk of code, stack, and even some ctx (no more
fragment_thresh):

           code          stack          ctx
  before: 37504           2448          656
  after:  37024 (-1.3%)   2416 (-1.3%)  652 (-0.6%)
This commit is contained in:
Christopher Haster
2025-07-03 19:15:10 -05:00
parent 3f2e8b53c5
commit b700c8c819
5 changed files with 11 additions and 100 deletions
Download Patch File Download Diff File Expand all files Collapse all files
lfs3.h
-15
View File
@@ -525,21 +525,6 @@ struct lfs3_config {
#ifndef LFS3_RDONLY
lfs3_size_t crystal_thresh;
#endif
// Threshold for breaking a block into fragments. Smaller values will
// fragment more lazily, reducing random-write cost, but risk higher
// disk usage.
//
// This can be set lower than crystal_thresh to prevent repeated
// compact/break operations in files with heavy random writes, at a
// storage cost. Setting this higher than crystal_thresh is probably not
// a good idea.
//
// 0 will never fragment a block once compacted, while -1 will fragment
// as soon as a block drops below crystal_thresh.
#ifndef LFS3_RDONLY
lfs3_size_t fragment_thresh;
#endif
};
// File info structure