The find_segs/fill_segs factoring of get_segs served its purpose in
allowing us to focus on developing a clean model for what is arguably
the heart of Tux3. But while get_segs presents a very nice interface,
terse, efficient and well suited to its purpose, the internal glue
between find_segs and fill_segs is looking increasingly awkward. This
patch (not committed yet) puts them back together again.
filemap.c | 14 ++-----
kernel/filemap.c | 99 ++++++++++++++++++++++---------------------------------
2 files changed, 44 insertions(+), 69 deletions(-)
The result is a somewhat rambling 180 line function, which is not too
bad considering that it does a similar job to ext2_get_block in
ext2/inode.c. Check that out, and keep in mind that ext2 does not have
to worry about extents or btrees: its ->get_block works one data block
at a time in a simple radix tree.
One reason our code is shorter is, btree.c and dleaf.c hide a lot of
the work behind nice, abstract interfaces. Thanks to Hirofumi for
digging into these and turning my messy prototypes into solid,
readable code!
One thing about ext2_get_block is, its SMP locking is much more
lightweight and parallel than the crude rw semaphore locking I just
added. It uses RW spinlocks (sparingly) and a mutex to exclude against
truncate. As we improve our locking strategy over time, Ext2 is the
efficiency benchmark to measure against.
Filemap is going to evolve a lot over the next phase of development,
Improvements that I think we should do before submitting for review
include:
- Detect opportunities to merge physically contiguous segments
together (->get_block can currently generate lots of wasteful
single block extents)
- Split segments up into multiple extents to handle extent size
limit.
- Add support for redirect on write, needed for atomic commit.
And the big one, a little further away, is:
- Integrate algorithms from version.c
There will also be many opportunities for optimi...
