[Tux3] Refactor filemap.c

[Daniel Phillips]

Hi Hirofumi,

Filemap.c badly needed refactoring.  Now we have get_segs, that fills
an array of segments, which are just like extents but in CPU order.
This is common between kernel and user space.  I used your modified
version of the code for get_segs, which stops at the first hole, so
the behavior in kernel should be the same, if I didn't break anything.

   http://hg.tux3.org/tux3/rev/3193c496333d
   filemap.c |  471 ++++++++++++++++++++++----------------------------------------
   1 file changed, 172 insertions(+), 299 deletions(-)

Now tux3_get_block is a reasonable size, and the get_segs code can be
worked on in user space.  We will be doing quite a lot of work on it,
because atomic commit is centered here.

The handling of offset at the end of get_segs is crude and can be
improved.  Handling of existing, overlapping extents on rewrite is
still broken, I will fix that pretty soon.

Questions:

  * Is i_blocks required to be in sectors?  I thought that was just
    a traditional limitation of Ext2/3.

  * If we mark a buffer new, can b_size be more than one block?

Instead of the loop over segs in tux3_get_block, we can just call with
max_segs = 1.  I don't think there is a case where ->get_block can
handle more than one extent.

Regards,

Daniel

_______________________________________________
Tux3 mailing list
Tux3 at tux3.org
http://mailman.tux3.org/cgi-bin/mailman/listinfo/tux3