Date: Wed, 9 Feb 2000 13:25:23 -0500
From: [EMAIL PROTECTED]
Yes. Based on my misunderstanding of how BSD did fragments, Ted and I
came up with an interestingly different way of doing fragments. Here's
the basic idea:
Keep the bitmaps of _blocks_ instead of fragments and use a second
bitmap to identify which blocks are non-full fragment blocks. Use the
last fragment in a fragment block as a fragment block descriptor to
indicate which inode each fragment belongs to (exact format still to
be determined). Fragment blocks are kept compact as otherwise we would
have to deal with internal fragmentation.
The further refinement of this plan is to use a always keep the
fragments compacted, and then using an indirection table. So instead of
storing the fragment address in the inode, we store an index into
fragment location table in find the fragment. This makes it trivial to
pack the fragments in the block to avoid internal fragmentation.
Then you don't need a bitmap to keep track of the fragment allocation;
you just need a single entry in the administrative fragment block to
point at the next free fragment.
Note that the idea here is to set the block size to the maximum ideal
transfer size for disks. For modern disks, that's probably something
like 64k or 128k. (i.e., it doesn't take much more time to read 64k
compared to 1k).
The one downside of this plan is that when you delete a file with a
tail, you have to do an extra block read/write to update the allocation
information in the fragment block. In the BSD scheme, you just have to
update the allocation bitmap. This does slow deletions by a small
amount, but that might not be that big of an issue.
The reason why we were considering this sort of thing is because when
the difference between the fragment and block size grows, the potential
problems with internal fragmentation is a real issue.
- Ted
