Subject: LFS v2 layout
To: None <tech-kern@netbsd.org>
From: Konrad Schroder <perseant@hhhh.org>
List: tech-kern
Date: 12/06/2000 14:55:04
There are some changes to LFS that have been waiting for a while because
they require changes to the on-disk data structures. I've had the code to
do most of this for a while, but I want to make sure that all reasonable
disk format changes make it in at one time as "lfs_version = 2", so I'd
like to solicit suggestions for any other desired changes.
(Note that I'm only talking about on-disk data structure changes, not
functionality changes for the most part, though I'd gladly hear about
desired functionality changes as well.)
This is what I've got down so far:
+ Better support for RAID:
- segment sizes allowed to be non-PO2, non-multiples of fs block size
(so they can be stripe-sized)
- segments aligned to the start of the partition, rather than to
the first superblock (so they can be stripe-aligned)
+ allow segment summary size to be parametrized at newfs time, to
support non-512-byte-sectored disks (requires more work to do any
good, but the parameter is there anyway)
+ allow inode block size to be parametrized at newfs time, since they
seem to be almost empty a lot of the time
+ keep the head of the inode free list in the Ifile, instead of on the
superblock (so we don't have to take the seglock for lfs_valloc)
+ use serial numbers for segment summaries, instead of time stamps
(so clock stepping doesn't bork roll-forward)
+ atime information kept on the Ifile (previously this was a #define)
There are some other possibly useful things I've thought of, but which I
don't think are useful enough to make it into this round:
+ convert all addressing and accounting into fragment-sized units,
instead of disk-block-sized units (ufs i_ffs_blocks is defined in db!)
+ put key info from the lfs superblock at the same offset as it is
in the ffs superblock, to make merged utilities easier/smaller
(this and the above should make at least boot blocks and dump_ffs
"just work" on LFSs)
+ various things to support hole-plugging cleaning (multiple
partial-segment headers, individual block headers, etc.)
Is there anything I've missed?
Konrad Schroder
perseant@hhhh.org