trv: Reverted LFS3_t_NOSPC, forward gbmap repop errors

Note: This affects the blocking lfs3_alloc_repopgbmap as well as
incremental gc/traversal repopulations. Now all repop attempts return
LFS3_ERR_NOSPC when we don't have space for the gbmap, motivation below.

This reverts the previous LFS3_t_NOSPC soft error, in which traversals
were allowed to continue some gc/traversal work when encountering
LFS3_ERR_NOSPC. This results in a simpler implementation and fewer error
cases to worry about.

Observation/motivation:

- The main motivation is noticing that when we're in low-space
  conditions, we just start spamming gbmap repops even if they all fail.

  That's really not great! We might as well just mark the flash as dead
  if we're going to start spamming erases!

  At least with an error the user can call rmgbmap to try to make
  progress.

- If we're in a low-space condition, something else will probably return
  LFS3_ERR_NOSPC anyways. Might as well report this early and simplify
  our system.

- It's a simpler model, and littlefs3 is already much more complicated
  than littlefs2. Maybe we should lean more towards a simpler system
  at the cost of some niche optimizations.

---

This had the side-effect of causing more lfs3_alloc_ckpoints to return
errors during testing, which revealed a bug in our uz/uzd_fuzz tests:

- We weren't flushing after writes to the opened RDWR files, which could
  cause delayed errors to occur during the later read checks in the
  test.

  Fortunately LFS3_O_FLUSH provides a quick and easy fix!

  Note we _don't_ adopt this in all uz/uzd_fuzz tests, only those that
  error. It's good to test both with and without LFS3_O_FLUSH to test
  that read-flushing also works under stress.

Saves a bit of code:

                 code          stack          ctx
  before:       37260           2352          688
  after:        37220 (-0.1%)   2352 (+0.0%)  688 (+0.0%)

                 code          stack          ctx
  gbmap before: 40220           2368          856
  gbmap after:  40184 (-0.1%)   2368 (+0.0%)  856 (+0.0%)
This commit is contained in:
Christopher Haster
2025-10-20 13:55:58 -05:00
parent 9e4bbdf0ad
commit 5d70e47708
11 changed files with 120 additions and 93 deletions
+10 -2
View File
@@ -10822,6 +10822,8 @@ code = '''
# fuzz tests involving many uncreats + zombies, this gets a bit crazy
[cases.test_stickynotes_uz_fuzz]
# you probably need to flush if you expect errors
defines.FLUSH = false
defines.N = [1, 2, 4, 8, 16, 32, 64]
# do more ops than files to encourage file rewrites
defines.OPS = '2*N'
@@ -10897,7 +10899,9 @@ code = '''
char name[256];
sprintf(name, "batman%03x", x);
lfs3_file_open(&lfs3, &sim_files[j]->file, name,
LFS3_O_RDWR | LFS3_O_CREAT) => 0;
LFS3_O_RDWR
| LFS3_O_CREAT
| ((FLUSH) ? LFS3_O_FLUSH : 0)) => 0;
// write some initial data if we don't exist
if (!exist || sticky) {
@@ -11242,6 +11246,8 @@ code = '''
# fuzz tests involving many uncreats + zombies + dirs, this gets a bit crazy
[cases.test_stickynotes_uzd_fuzz]
# you probably need to flush if you expect errors
defines.FLUSH = false
defines.N = [1, 2, 4, 8, 16, 32, 64]
# do more ops than files to encourage file rewrites
defines.OPS = '2*N'
@@ -11321,7 +11327,9 @@ code = '''
char name[256];
sprintf(name, "batman%03x", x);
lfs3_file_open(&lfs3, &sim_files[j]->file, name,
LFS3_O_RDWR | LFS3_O_CREAT) => 0;
LFS3_O_RDWR
| LFS3_O_CREAT
| ((FLUSH) ? LFS3_O_FLUSH : 0)) => 0;
// write some initial data if we don't exist
if (!exist || sticky) {