Welcome to mirror list, hosted at ThFree Co, Russian Federation.

github.com/littlefs-project/littlefs.git - Unnamed repository; edit this file 'description' to name the repository.
summaryrefslogtreecommitdiff
AgeCommit message (Collapse)Author
2024-01-23Merge pull request #929 from littlefs-project/develHEADv2.9.0v2masterChristopher Haster
Minor release: v2.9
2024-01-19Bumped minor version to v2.9develChristopher Haster
2024-01-19Merge pull request #915 from littlefs-project/well-doneChristopher Haster
Rename internal functions _raw* -> _*_
2024-01-19Renamed internal functions _raw* -> _*_well-doneChristopher Haster
So instead of lfs_file_rawopencfg, it's now lfs_file_opencfg_. The "raw" prefix is annoying, doesn't really add meaning ("internal" would have been better), and gets in the way of finding the relevant function implementations. I have been using _s as suffixes for unimportant name collisions in other codebases, and it seems to work well at reducing wasted brain cycles naming things. Adopting it here avoids the need for "raw" prefixes. It's quite a bit like the use of prime symbols to resolve name collisions in math, e.g. x' = x + 1. Which is even supported in Haskell and is quite nice there. And the main benefit: Now if you search for the public API name, you get the internal function first, which is probably what you care about. Here is the exact script: sed -i 's/_raw\([a-z0-9_]*\)\>/_\1_/g' $(git ls-tree -r HEAD --name-only | grep '.*\.c')
2024-01-19Merge pull request #917 from tomscii/fix_return_value_of_lfs_renameChristopher Haster
Fix return value of lfs_rename()
2024-01-19Merge pull request #916 from littlefs-project/ci-ubuntu-latestChristopher Haster
Change CI to just run on ubuntu-latest
2024-01-19Merge pull request #914 from littlefs-project/inline-maxChristopher Haster
Add inline_max, to optionally limit the size of inlined files
2024-01-19Added inline_max, to optionally limit the size of inlined filesinline-maxChristopher Haster
Inlined files live in metadata and decrease storage requirements, but may be limited to improve metadata-related performance. This is especially important given the current plague of metadata performance. Though decreasing inline_max may make metadata more dense and increase block usage, so it's important to benchmark if optimizing for speed. The underlying limits of inlined files haven't changed: 1. Inlined files need to fit in RAM, so <= cache_size 2. Inlined files need to fit in a single attr, so <= attr_max 3. Inlined files need to fit in 1/8 of a block to avoid metadata overflow issues, this is after limiting by metadata_max, so <= min(metadata_max, block_size)/8 By default, the largest possible inline_max is used. This preserves backwards compatibility and is probably a good default for most use cases. This does have the awkward effect of requiring inline_max=-1 to indicate disabled inlined files, but I don't think there's a good way around this.
2024-01-19Merge pull request #913 from littlefs-project/gc-compactionsChristopher Haster
Extend lfs_fs_gc to compact metadata, compact_thresh
2024-01-19Merge pull request #912 from littlefs-project/relaxed-lookaheadChristopher Haster
Relaxed lookahead alignment, other internal block alloc readability improvements
2024-01-19Extended lfs_fs_gc to compact metadata, compact_threshgc-compactionsChristopher Haster
This extends lfs_fs_gc to now handle three things: 1. Calls mkconsistent if not already consistent 2. Compacts metadata > compact_thresh 3. Populates the block allocator Which should be all of the janitorial work that can be done without additional on-disk data structures. Normally, metadata compaction occurs when an mdir is full, and results in mdirs that are at most block_size/2. Now, if you call lfs_fs_gc, littlefs will eagerly compact any mdirs that exceed the compact_thresh configuration option. Because the resulting mdirs are at most block_size/2, it only makes sense for compact_thresh to be >= block_size/2 and <= block_size. Additionally, there are some special values: - compact_thresh=0 => defaults to ~88% block_size, may change - compact_thresh=-1 => disables metadata compaction during lfs_fs_gc Note that compact_thresh only affects lfs_fs_gc. Normal compactions still only occur when full.
2024-01-19Merge pull request #909 from littlefs-project/easy-util-definesChristopher Haster
Add some easier util overrides: LFS_MALLOC/FREE/CRC
2024-01-19Merge pull request #886 from BrianPugh/macro-sanity-checkChristopher Haster
Add value-range checks for user-definable macros at compile-time
2024-01-17Added tests over rename type errorsChristopher Haster
2024-01-17Fix return value of lfs_rename()Tom Szilagyi
When lfs_rename() is called trying to rename (move) a file to an existing directory, LFS_ERR_ISDIR is (correctly) returned. However, in the opposite case, if one tries to rename (move) a directory to a path currently occupied by a regular file, LFS_ERR_NOTDIR should be returned (since the error is that the destination is NOT a directory), but in reality, LFS_ERR_ISDIR is returned in this case as well. This commit fixes the code so that in the latter case, LFS_ERR_NOTDIR is returned.
2024-01-17Restricted LFS_FILE_MAX to signed 32-bits, <2^31, <=2147483647Christopher Haster
I think realistically no one is using this. It's already only partially supported and untested. Worst case, if someone does depend on this we can always revert.
2024-01-17Rearranged compile-time constant checks to live near lfs_initChristopher Haster
lfs_init handles the checks/asserts of most configuration, moving these checks near lfs_init attempts to keep all of these checks nearby each other. Also updated the comments to avoid somtimes-ambiguous range notation. And removed negative bounds checks. Negative bounds should be obviously incorrect, and 0 is _technically_ not illegal for any define (though admittedly unlikely to be correct).
2024-01-16Relaxed alignment requirements for lfs_mallocrelaxed-lookaheadChristopher Haster
The only reason we needed this alignment was for the lookahead buffer. Now that the lookahead buffer is relaxed to operate on bytes, we can relax our malloc alignment requirement all the way down to the byte level, since we mainly use lfs_malloc to allocate byte-level buffers. This does introduce a risk that we might need word-level mallocs in the future. If that happens we will need to decide if changing the malloc alignment is a breaking change, or gate alignment requirements behind user provided defines. Found by HiFiPhile.
2023-12-21Changed CI to just run on ubuntu-latestci-ubuntu-latestChristopher Haster
If we already have to bump this version as GitHub phases out older Ubuntu runners (which is reasonable), I don't really see the value of pinning a specific version. We might as well just respond to any broken dependencies caused by GitHub's implicit updates as they happen... It's not like CI is truly continuous.
2023-12-21Merge pull request #911 from littlefs-project/fix-release-structsv2.8.2Christopher Haster
Fix struct sizes missing from generated release notes
2023-12-21Merge pull request #910 from littlefs-project/fix-superblock-expansion-threshChristopher Haster
Increase threshold for superblock expansion from ~50% -> ~88% full
2023-12-21Merge pull request #898 from zchen24/patch-1Christopher Haster
Update DESIGN.md minor typo
2023-12-21Update DESIGN.md, fix minor typoZihan Chen
2023-12-20Relaxed lookahead buffer alignmentChristopher Haster
This drops the lookahead buffer from operating on 32-bit words to operating on 8-bit bytes, and removes any alignment requirement. This may have some minor performance impact, but it is unlikely to be significant when you consider IO overhead. The original motivation for 32-bit alignment was an attempt at future-proofing in case we wanted some more complex on-disk data structure. This never happened, and even if it did, it could have been added via additional config options. This has been a significant pain point for users, since providing word-aligned byte-sized buffers in C can be a bit annoying.
2023-12-20Reworked the block allocator so the logic is hopefully simplerChristopher Haster
Some of this is just better documentation, some of this is reworking the logic to be more intention driven... if that makes sense...
2023-12-20Renamed a number of internal block-allocator fieldsChristopher Haster
- Renamed lfs.free -> lfs.lookahead - Renamed lfs.free.off -> lfs.lookahead.start - Renamed lfs.free.i -> lfs.lookahead.next - Renamed lfs.free.ack -> lfs.lookahead.ckpoint - Renamed lfs_alloc_ack -> lfs_alloc_ckpoint These have been named a bit confusingly, and I think the new names make their relevant purposes a bit clearer. At the very it's clear lfs.lookahead is related to the lookahead buffer. (and doesn't imply a closed free-bitmap).
2023-12-20Fixed struct sizes missing from generated release notesfix-release-structsChristopher Haster
This script was missed during a struct -> structs naming change
2023-12-20Increase threshold for superblock expansion from ~50% -> ~88% fullfix-superblock-expansion-threshChristopher Haster
Superblock expansion is an irreversible operation. In an effort to prevent superblock expansion from claiming valuable scratch space (important for small, <~8 block filesystems), littlefs prevents superblock expansion when the disk is "mostly full". In true computer-scientist fashion, this "mostly full" threshold was set to ~50%. As pointed out by gbolgradov and rojer, >~50% utilization is not uncommon, and it can lead to a situation where superblock expansion does not occur in a relatively healthy filesystem, causing focused wear at the root. To remedy this, the threshold is now increased to ~88% (7/8) full. This may change in the future and should probably be eventually user configurable. Found by gbolgradov and rojer
2023-12-19Added LFS_CRC, easier override for lfs_crceasy-util-definesChristopher Haster
Now you can override littlefs's CRC implementation with some simple defines: -DLFS_CRC=lfs_crc The motivation for this is the same for LFS_MALLOC/LFS_FREE. I think these are the main "system-level" utils that users want to override. Don't override with this something that's not CRC32! Your filesystem will no longer be compatible with other tools! This is only intended for provided hardware acceleration!
2023-12-19Added LFS_MALLOC/FREE, easier overrides for lfs_malloc/freeChristopher Haster
Now you can override littlefs's malloc with some simple defines: -DLFS_MALLOC=my_malloc -DLFS_FREE=my_free This is probably what most users expected when wanting to override malloc/free in littlefs, but it hasn't been available, since instead littlefs provides a file-level override of builtin utils. The thinking was that there's just too many builtins that could be overriden, lfs_max/min/alignup/npw2/etc/etc/etc, so allowing users to just override the util file provides the best flexibility without a ton of ifdefs. But it's become clear this is awkward for users that just want to replace malloc. Maybe the original goal was too optimistic, maybe there's a better way to structure this file, or maybe the best API is just a bunch of ifdefs, I have no idea! This will hopefully continue to evolve.
2023-11-26Update DESIGN.md minor typoZihan Chen
2023-10-31Merge pull request #884 from DvdGiessen/static-functionsv2.8.1Christopher Haster
lfs_fs_raw* functions should be static
2023-10-30Replace erroneous LFS_FILE_MAX upper bound 4294967296 to 4294967295Brian Pugh
2023-10-29Add value-range checks for user-definable macrosBrian Pugh
2023-10-24Added -Wmissing-prototypesChristopher Haster
This warning is useful for catching the easy mistake of missing the keyword static on functions intended to be internal-only. Missing the static keyword risks symbol polution and misses potential compiler optimizations. This is an interesting warning, while useful for libraries such as littlefs, it's perfectly valid C to not predeclare all functions, and common in final application binaries. Relatedly, this warning is re-disabled for the test/bench runner. There may be a better way to organize the CFLAGS, maybe into separate LIB/RUNNER CFLAGS, but I'll leave this to future work if our CFLAGS grow more complicated. This was motivated by non-static internal-only functions leaking into a release. Found and fixed by DvdGiessen.
2023-10-23lfs_fs_raw* functions should be staticDaniël van de Giessen
2023-09-22Merge pull request #877 from littlefs-project/develv2.8.0Christopher Haster
Minor release: v2.8
2023-09-21Bumped minor version to v2.8Christopher Haster
2023-09-21Merge pull request #875 from littlefs-project/fs-gcChristopher Haster
Add lfs_fs_gc to enable proactive finding of free blocks
2023-09-21Renamed lfs_fs_findfreeblocks -> lfs_fs_gc, tweaked documentationfs-gcChristopher Haster
The idea is in the future this function may be extended to support other block janitorial work. In such a case calling this lfs_fs_gc provides a more general name that can include other operations. This is currently just wishful thinking, however.
2023-09-21Extended alloc tests to test some properties of lfs_fs_findfreeblocksChristopher Haster
- Test that the code actually runs. - Test that lfs_fs_findfreeblocks does not break block allocations. - Test that lfs_fs_findfreeblocks does not error when no space is available, it should only errors when the block is actually needed.
2023-09-21Added API boilerplate for lfs_fs_findfreeblocks and consistent styleChristopher Haster
This adds the tracing and optional locking for the littlefs API. Also updated to match the code style, and added LFS_READONLY guards where necessary.
2023-09-21Move lookahead buffer offset at the first free block if such block doesn't ↵ondrap
exist move it for whole lookahead size.
2023-09-21Update lfs_find_free_blocks to match the latest changes.ondrap
2023-09-21Merge pull request #872 from littlefs-project/fs-growChristopher Haster
Add lfs_fs_grow to enable limited resizing of the filesystem
2023-09-21Merge pull request #866 from BrianPugh/optional-block-countChristopher Haster
Infer block_count from superblock if not provided in config.
2023-09-12Added lfs_fs_grow for growing the filesystem to a different block_countfs-growChristopher Haster
The initial implementation for this was provided by kaetemi, originally as a mount flag. However, it has been modified here to be self-contained in an explicit runtime function that can be called after mount. The reasons for an explicit function: 1. lfs_mount stays a strictly readonly operation, and avoids pulling in all of the write machinery. 2. filesystem-wide operations such as lfs_fs_grow can be a bit risky, and irreversable. The action of growing the filesystem should be very intentional. --- One concern with this change is that this will be the first function that changes metadata in the superblock. This might break tools that expect the first valid superblock entry to contain the most recent metadata, since only the last superblock in the superblock chain will contain the updated metadata.
2023-09-12Tweaked lfs_fsinfo block_size/block_count fieldsChristopher Haster
Mainly to match superblock ordering and emphasize these are logical blocks.
2023-09-12Added a couple mixed/unknown block_count testsChristopher Haster
These were cherry-picked from some previous work on a related feature.
2023-09-12Adopted erase_size/erase_count config in test block-devices/runnersChristopher Haster
In separating the configuration of littlefs from the physical geometry of the underlying device, we can no longer rely solely on lfs_config to contain all of the information necessary for the simulated block devices we use for testing. This adds a new lfs_*bd_config struct for each of the block devices, and new erase_size/erase_count fields. The erase_* name was chosen since these reflect the (simulated) physical erase size and count of erase-sized blocks, unlike the block_* variants which represent logical block sizes used for littlefs's bookkeeping. It may be worth adopting erase_size/erase_count in littlefs's config at some point in the future, but at the moment doesn't seem necessary. Changing the lfs_bd_config structs to be required is probably a good idea anyways, as it moves us more towards separating the bds from littlefs. Though we can't quite get rid of the lfs_config parameter because of the block-device API in lfs_config. Eventually it would be nice to get rid of it, but that would require API breakage.