Re: filesystems

>>> Henrik Nordstrom wrote
> Today the "aufs" layer has some complexity dealing with asyncronous open
> and concurrent writes. Both these would be beneficial to move down to
> the "async-io" layer to make the FS code of "aufs" less specific of the
> I/O code used, however, doing so would require the introduction of a
> abstract "disk file handle" concept, as there is no filedescriptor until
> the file has been opened.

Agreed with the rest of the post, and I'd figured that much out. However, my
concern with the above is I'm not clearly seeing how moving the async handling
in aufs _down_, into shared code, would be a good thing - aufs is the only
thing that uses the request_queue/request_queue2 structure, and to my mind
_should be_ the only thing that does - otherwise we risk making diskd and ufs
rely on pthreads, don't we?

Surely the request queues are specific to aufs, but most of the rest of the
code is shareable - the actual mechanisms for talking to disk, for instance,
or the creation of request objects/callback data, and the eventual tracking of
what objects exist in the fs?

I can't wrap my head around why we'd want a queueing mechanism in ufs beyond
what it already has, is basically the problem - and what it already has could
be subsumed into aufs as "if (!async) { }" type blocks anyway, it's that
trivial - especially if the _do_read() _do_write() etc. calls were common
(blocking) code.

I kind of envisage something like:

storeRead() gets called to read data - it builds a request object, and either
calls ufs_read() and then the appropriate callback in the case of ufs, or
queues the request obect and returns in the case of aufs. If aufs, then when
the request is taken off the request queue to be handled, it would call
ufs_read(), and then any appropriate callbacks.

So ufs_read() is shared code, as is the construction of request objects and
the handling of callbacks - it's just the queueing mechanism that's specific
to aufs.

diskd gets a similar treatment - it can do what it likes in despatching the
incoming requests, but it'd most likely be using the same underlying functions
for ufs_read(), building request objects, etc - just it's strategy for
deciding exactly which request to honour when (in what process) would be different.

Does that make any sense?

KevinL

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