On Sun, 25 Jul 1999, Robert de Bath wrote:
> Ok, problem.
>
> Defragmentation is _very_ difficult, if you move a file you'll have to
> renumber the inode, nasty for files with multiple links.
>
> If you use aligned allocation, as you've got a free blocks bitmap it's
> easy, you should be able to avoid the need for defragmentation.
My filesystem breaks a disk into several zones (up to 20 atm). What i am going
to do, whenever a file expands, it tries to allocate a new block from the
same zone as its inode. Whenever a new inode is needed, the filesystem will
allocate it in the first zone that has less than 70% block usage. If all zones
are more than 70% full, it will use the emptiest zone. Also defragmentation
will be reasonably difficult, but not impossible. The best way to do it is
remember where inodes are moved to and at the end just update all the inode
numbers.
> Next a suggestion, I think it'd be a good idea to put a magic number at
> the start of an inode, that way 'lost clusters' can be checked for file
> inodes easily and reattached to lost+found if sane.
Good idea, I will do that :)
> I notice that you've not mentioned how the end of the filesystem is
> marked, you do need this as the filesystem image may be copied to a new
> larger device. In fact it'd be nice if you recorded only the higest
> block that has actually been written to, that way if the filesystem is
> copied to a larger device it will _automatically_ extend to fill the
> device. (really neat with /dev/md devices :-) ) Unfortunatly to shrink
> a filesystem you'd need to solve the defragmentation problem.
Oh, do i have to mark the end of the filesystem. Wat happens is that all zones
are of equal size(except the last one) and the superblock remembers how large
the filesytem really is. To make the filesystem larger, it is simply a case of
enlarging the size of the last zone and adding more zones as needed, and then
telling the superblock how big the new fs is.
> I know 64Mb (actually I'd estimate about 60Mb after the inode info is
> allocated) is more than enough, but you should _specify_ triple indirect
> and possibly larger. Who knows you may want to copy a CDROM one day. :-)
Well, it is ELKS. However, I imagine that eventually I could write an algorthm
that expands to infinite indirectness. (up to MAXLONGINT (4 gig)).
> Compression/encoding: specify hooks and data space for things like
> compression, forward error correction and encryption. (eg encoding
> method field and lseek translation table pointer)
Errk. Sounds like Version 2 stuff :)
> The final things you might want to consider are journeling and other
> "new features people will want for V2"
Journeling, sounds like fun, and complicated :)
Thanks for the ideas Rob.
Beau Kuiper
[EMAIL PROTECTED]
