inline files are 1/4 block or 1/8 block?

[amgross]

In the code it seems like files stop being inline when they are more than 1/8 of block:

littlefs/lfs.c

Lines 4331 to 4345 in 8e251dd

	LFS_ASSERT(lfs->cfg->inline_max == (lfs_size_t)-1
	|| lfs->cfg->inline_max <= ((lfs->cfg->metadata_max)
	? lfs->cfg->metadata_max
	: lfs->cfg->block_size)/8);
	lfs->inline_max = lfs->cfg->inline_max;
	if (lfs->inline_max == (lfs_size_t)-1) {
	lfs->inline_max = 0;
	} else if (lfs->inline_max == 0) {
	lfs->inline_max = lfs_min(
	lfs->cfg->cache_size,
	lfs_min(
	lfs->attr_max,
	((lfs->cfg->metadata_max)
	? lfs->cfg->metadata_max
	: lfs->cfg->block_size)/8));

But in the readme it written that the threshold is 14/ block:

littlefs/DESIGN.md

Lines 1470 to 1472 in 8e251dd

	Once the file exceeds 1/4 the block size, we switch to a CTZ skip-list. This
	means that our files never use more than 4x storage overhead, decreasing as
	the file grows in size.

[geky]

Hi @amgross, good catch.

Looks like the 1/8 check was added in 916b308, before DESIGN.md was rewritten. Clearly whoever wrote DESIGN.md (me) didn't double check the code.

1/4 is theoretically the optimal cutoff, but 1/8 was chosen as a safer cutoff. The concern is that the inline cutoff doesn't include file metadata (file names, types, revision counts, etc), and with the mdirs already splitting at 1/2 the block size, cutoff=1/4 risks only one inline file fitting in each mdir.

Note this was before the user-configurable inline_max was introduced.

Since then, two things:

1. Experiments have shown "wasted" mdir space is not really that big of a concern, since it contributes to logging and defers mdir compaction. (split_thresh should probably be use configurable in the future, but that is a high risk change.)

2. inline_size was added as a configuration option, so if 1/4 is problematic, users can override it now.

---

So I think it's safe to bump this back up to 1/4, but we should probably only make such a change on a minor release. littlefs2 is under a feature-freeze at the moment, so this may take some time.

[geky]

I went ahead and create #1146 to bump this up. Though it will at least be blocked by the current feature freeze.

[amgross]

Thank you very much, I understand littlefs3 that already contains it is not stable enough for in-field product?

[geky]

Thank you very much, I understand littlefs3 that already contains it is not stable enough for in-field product?

Correct. The key issue is that littlefs3's disk format may change without notice, so if you deploy littlefs3, there may be no upgrade path in the future.

The irony is littlefs3 has significantly more testing than littlefs2 ever did. I think it's production ready from that perspective, but the above issue will make it difficult to adopt bug fixes, etc.

The motivation for the feature freeze is to prioritize littlefs3 stabilization. New features in littlefs2 will probably need porting to littlesf3, and the churn really slow things down. Also features have a much higher risk of new bugs in a way bug fixes don't. #1146 is a great example because we won't really know what side-effects inline_max=1/4 will have until users start using it.