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

FS types whose size are not known at compile time #610

Open
travis1829 opened this issue Mar 8, 2022 · 0 comments
Open

FS types whose size are not known at compile time #610

travis1829 opened this issue Mar 8, 2022 · 0 comments

Comments

@travis1829
Copy link
Collaborator

In Lfs,

  • Based on the max number of inodes n,
    • The size of the in-memory Imap should be (n + 255) / 256 * 4 bytes to store the mapping for all inodes.
  • Based on the total number of segments s of the disk,
    • The size of the in-memory SegTable should be (s + 7) / 8 bytes to store the mapping for all segments.

The problem is, n or s are not known at compile time, and hence, the size of the in-memory Imap or SegTable are also not known at compile time. Note that the Ufs also had a similar problem and solved this by limiting the max number of inodes to 200 for all disks.

To solve this, we should

  • Allocate the Imap and SegTable at a page instead of placing it on the Kernel. (At booting or every time we mount a disk)
  • Make the Imap or SegTable big enough so that any n or s should work.
    • We should have a reasonable limit for n or s.
    • This could be a small waste of memory if n or b is actually small for 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

1 participant