Re: fs work - request structure

>>> Henrik Nordstrom wrote
> KevinL wrote:
>
> > What I'm finding, tho, is that aufs keeps it's callback data in ctrl, whereas
> > ufs keeps it in sio - and unless I can merge those somehow, the code cannot be
> > nicely shared between them. What I'd like to do, ideally, is move the
> > callback data out of ctrl into requestp. Are there any reasons I shouldn't do
> > that?
>
> The intermediary layer in aufs should be killed. There is no need for

Alright, that's exactly what I was hoping to hear, and that is the direction
I'm moving. It's a fair sized shuffle, but it _is_ underway - I'll hopefully
commit something end of tomorrow to show what I'm doing.

> three layers, at most two is needed. This has been on the todo for a
> year or more, together with rewriting async-io to use macro operations
> such as
> * Open file A and give me the first X KB of data, and close the file
> if there is no more data.
> * Open file B and write these Y KB of data, then close the file if no
> more data is expected.

I love this idea, but will hold off until the new IO-layer stuff is in and
aufs has been cleaned up to fit with ufs properly - I can vaguely see where it
all fits now, but it's a fair bit of coding away.

> This reasoning also applies to diskd.
>
> Why: From a performance point of view IPC is a bad thing (being it over
> shared memory, pipes, thread message queues or whatever), and having
> many IPC calls for small related operations is not a very wise thing to
> do. What we are interested in here is the data, we do not actually care
> when the files are opened/closed, it is only a evil requirement for
> beeing able to perform the data operations.

Yup, agreed. Alright, thanks, I'm happy I'm on the right track. More
tomorrow.

KevinL

-- 
Internet techie, Obsidian Consulting Group
Specialising in proxy issues and traffic measuring/billing.