Adrian Chadd wrote:
> Hrm. Thats what I had initially for callback and sync due to AUFS. If
> people think that having sync and callback per-fs type rather than per-fs
> instance then I'll go through and change the API back. If we do this then
> it'll be up to the fs code to maintain a list of swapdirs of their type,
> or they have to walk the swapDir array and strcmp("type", SD->type) to
> figure out whether is a swapdir of theirs.
> Votes please.
AUFS only have a global callback (and sync) function, and calling it
multiple times is supposedly only a big of CPU cycles, but it can
probably be massaged into Duanes approach to do incremental computing.
As I see it there are three possibilities:
a) Per FS-type callbacks
+ Gives good flexibility on ordering to the FS-type implementation. Best
suited when the FS-type implementation does not have to care about the
FS instences for performing the action (i.e. AUFS)
- May require the FS implementation to keep track of the FS instances
somehow
b) Incremental per FS callbacks with return status "requires more work",
not "did something".
+ Very flexible
- Wastes some CPU time if the FS-type have global resources that needs
to be "polled". However, looking into the current async-io
implementation this is not an issue (the CPU time is mostly wasted
anyway).
c) Both
My wote was initially c, but I have now settled for b (incremental per
FS-instance).
I have already an good idea how aufs might be massaged into the
incremental model and yet perform better than todays implementation.
/Henrik
Received on Tue May 16 2000 - 01:40:42 MDT
This archive was generated by hypermail pre-2.1.9 : Tue Dec 09 2003 - 16:12:26 MST