Re: [patch 07/12] rfc: 2fsprogs update

Theodore Tso
2006-09-27T14:37:58Z

On Wed, Sep 27, 2006 at 03:36:42PM +0200, Alexandre Ratchov wrote:
> Perhaps it's not obvious, but thats my approach to get all of the
> conversions right without rewriting everything from scratch ;-). I'm still
> open to other approches.

Yes, and I appreciate that concern. However, given that we need to
support an extents-based iterator anyway, and given that we need to
break the bitmap code anyway so that it gets away from using inline
functions and can __eventually__ support multiple back-end
implementation, we will end up needing to breaking and reimplementing
the interfaces anyway.... and for the other bits of code, simply
defining a new interface and changing blk_t to blk64_t isn't that hard
and isn't want I would call "rewriting".

The other thing I would mention is that my plan for the extent
iterator is that if the inode uses indirect blocks, what the extent
iterator would do is call the block iterator function, and then
coalesce the results into extents and call the extent callback
function. So the question of when to use __u32 pointers wouldn't
arise, since we would use the existing code to iterate through the
indirect blocks. Easy!

Similarly, what I would do for the block_iterator is *if* the inode is
extent based, and *if* the filesystem is less than 2**32 blocks, then
the block iterator would call the extent_iterator, and then translate
the extents into blocks and call the block iterator's callback
function multiple times. This would be a backwards compatibility
scaffolding, until other portions of the library were converted over
use the extent iterator directly.

So in this fashion it's possible to minimize the amount of code that
we need to maintain in parallel; each functionality is only
implemented in one place, and yet the result still has as much
backwards compatibility as possible.

- Ted