Skip to content
New issue

Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? # to your account

Removing first block of file #611

Open
DrArmaggedon opened this issue Nov 8, 2021 · 2 comments
Open

Removing first block of file #611

DrArmaggedon opened this issue Nov 8, 2021 · 2 comments

Comments

@DrArmaggedon
Copy link

First of all I should thank you for the great work, saving me a lot of headache.

I use LittleFS in a project to store logs in LIFO style. The issue is that I need the log file to be bounded, that means when the log file size reaches a specific limit, first block of file should be removed before adding new entries. I understand that it's possible to implement a Circular Buffer over a pre-allocated file to do the job but with its own overhead. Also worth mentioning that entries are added to file in a block size chunk.

I wonder if it's possible to simply change meta data to remove the first block of file? Any hints expect for reading the whole spec? ;)

@DrArmaggedon
Copy link
Author

Ok, I have read the Spec, seams that due to backward nature of CTZ-Skip list, removing first block requires a large amount of update (COW) to structure. Is that right?

@geky
Copy link
Member

geky commented Apr 6, 2022

Hi @DrArmaggedon thanks for creating an issue, sorry for the late response.

This is actually a feature I'm personally quite interested in exploring once other pressing issues in the filesystem are sorted out. It would be a nice feature for a common use case of LittleFS : )

Unfortunately the CTZ-skip makes this a bit difficult. You could in theory keep an extra "offset" field that indicates low-numbered blocks are unused and return them to the block allocator, though there are some assumptions about how large the file can ever get and this would break that.

Unrelated to this, #27 indicates that the current data-structure is insufficient for the general case, so I'm planning to adopt a more general purpose B-tree structure in the future. With this I'm hoping to sneak in this feature of dropping the first n-bytes of a file cheaply.


For now the most efficient way to store logs in littlefs is to use a system of rotating files, common in Linux and others. That is to write a file to some fix size, and when it's full rename it to log.2 and start writing a new file. This works well with littlefs's append-friendly file data-structure.

# for free to join this conversation on GitHub. Already have an account? # to comment
Projects
None yet
Development

No branches or pull requests

2 participants