You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
The text was updated successfully, but these errors were encountered:
In Lfs,
n
,Imap
should be(n + 255) / 256 * 4
bytes to store the mapping for all inodes.s
of the disk,SegTable
should be(s + 7) / 8
bytes to store the mapping for all segments.The problem is,
n
ors
are not known at compile time, and hence, the size of the in-memoryImap
orSegTable
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
Imap
andSegTable
at a page instead of placing it on theKernel
. (At booting or every time we mount a disk)Imap
orSegTable
big enough so that anyn
ors
should work.n
ors
.n
orb
is actually small for the disk.The text was updated successfully, but these errors were encountered: