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 [email protected] http://mailman.tux3.org/cgi-bin/mailman/listinfo/tux3
