Skip to content
New issue

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

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

Already on GitHub? Sign in to your account

feature request: output the free size of a block device #12

Open
hannesm opened this issue Aug 30, 2022 · 2 comments
Open

feature request: output the free size of a block device #12

hannesm opened this issue Aug 30, 2022 · 2 comments

Comments

@hannesm
Copy link

hannesm commented Aug 30, 2022

Please excuse me if I'm wrong, but I was not able to find a way to output the bytes / blocks that are free on a given volume (also not how many are used, how many are there all together).

It would be great to have these statistics to figure out when care should be taken to clean the file system (or add another disk).

Thanks for providing this excellent library :)

@yomimono
Copy link
Owner

yomimono commented Sep 1, 2022

I agree that this would be useful - currently the only way to know the disk is full is to try to write things and see them fail for lack of space.

Free bytes is tricky in LittleFS, but free blocks are fairly easy to report on. Unfortunately there are potentially surprising results there too, like two previously-unused blocks being potentially necessary for a very small file write.

Would answers to the following questions be useful? Both are based on the number of free blocks, but try to handle some FS-specific structure knowledge for the user.

  • "What's the largest file I can currently write without running out of space?"
  • "How many more directories can I make without running out of space?"

Currently, getting the number of free blocks would require a full filesystem traversal each time. This does have to be determined at mount time anyway and I think it can be subsequently kept updated by the block allocator, but I need to think on it a bit more.

This general idea seems like something users of any block-based kv would want to know about, so I wonder whether it'd be better put in RO or RW of Mirage-kv, but the semantics there are even more confusing.

@hannesm
Copy link
Author

hannesm commented Sep 5, 2022

I'd be fine with an approximation: the number of used blocks, and free blocks. If the API is only in bytes, then multiply that with the block size. I don't think we need accurate numbers of how many bytes will fit onto the disk. ;)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants