| Age | Commit message (Collapse) | Author |
|---|
|
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.
|
|
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.
|
|
Some of this is just better documentation, some of this is reworking the
logic to be more intention driven... if that makes sense...
|
|
- 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).
|
|
lfs_fs_raw* functions should be static
|
|
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.
|
|
|
|
Minor release: v2.8
|
|
|
|
Add lfs_fs_gc to enable proactive finding of free blocks
|
|
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.
|
|
- 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.
|
|
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.
|
|
exist move it for whole lookahead size.
|
|
|
|
Add lfs_fs_grow to enable limited resizing of the filesystem
|
|
Infer block_count from superblock if not provided in config.
|
|
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.
|
|
Mainly to match superblock ordering and emphasize these are logical
blocks.
|
|
These were cherry-picked from some previous work on a related feature.
|
|
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.
|
|
This would result in two passes through the superblock chain during
mount, when we can access everything we need to in one.
|
|
Fix integer conversion warning from Code Composer Studio
|
|
initlize struct lfs_diskoff disk = {0}
|
|
Fix release script breaking if there is no previous version
|
|
|
|
|
|
|
|
|
|
|
|
superblock
|
|
|
|
|
|
Some block-device bound-checks are disabled during superblock search.
|
|
superblock
|
|
|
|
lfs_format
|
|
so we don't use it uninitlized in first run
|
|
Proposed by FiddlingBits
|
|
This can't actually happen in the current state of the littlefs GitHub
repo, but could in theory cause problems if CI is enabled on a fork.
Found while enabling GitHub Actions on littlefs-fuse.
|
|
Minor release: v2.7
|
|
|
|
Add a link to ChaN's FatFS implementation
|
|
Add support for writing previous on-disk minor versions
|
|
Add lfs_fs_stat for access to filesystem status/configuration
|
|
- Added test-multiversion test job
- Added test-lfs2_0 test job
- Added mutliversion size measurement
|
|
The code-cost wasn't that bad: 16556 B -> 16754 B (+1.2%)
But moving write support of older versions behind a compile-time flag
allows us to be a bit more liberal with what gets added to support older
versions, since the cost won't hit most users.
|
|
The intention is to help interop with older minor versions of littlefs.
Unfortunately, since lfs2.0 drivers cannot mount lfs2.1 images, there are
situations where it would be useful to write to write strictly lfs2.0
compatible images. The solution here adds a "disk_version" configuration
option which determines the behavior of lfs2.1 dependent features.
Normally you would expect this to only change write behavior. But since the
main change in lfs2.1 increased validation of erased data, we also need to
skip this extra validation (fcrc) or see terrible slowdowns when writing.
|
|
In terms of ease-of-use, a user familiar with other filesystems expects
block_usage in fsinfo. But in terms of practicality, block_usage can be
expensive to find in littlefs, so if it's not needed in the resulting
fsinfo, that operation is wasteful.
It's not clear to me what the best course of action is, but since
block_usage can always be added to fsinfo later, but not removed without
breaking backwards compatibility, I'm leaving this out for now.
Block usage can still be found by explicitly calling lfs_fs_size.
|
|
ChaN's FAT implementation definitely deserves a mention here, since it
was one of the first open-source microcontroller-oriented filesystem
implementations that I'm aware of, and has a lot of good ideas at the
implementation level.
Honestly I didn't realize this wasn't already linked to from here. If
you're using FAT on a microcontroller, it's most likely this library.
|
