Re: filesystems

KevinL wrote:
>
> Hey all,
>
> Adrian and I have been carrying on a discussion about proposed changes to the
> filesystems - in particular, this note is regarding ufs/aufs/diskd.
>
> The aim of this is to get a single file (or files) containing all the shared
> code between these three fs'es - basically, pull the actual diskop portion out
> of the fs, and make it common between all three.

Que? How do you plan on making diskop common? It is where the difference
is... you must be talking about the FS code here..

> Now, we're at a slight disagreement :) My take on this is that if we develop
> a blocking library - ie. one where a call to file_read() blocks until it's
> completed reading - then the fs'es themselves can be responsible for queueing
> incoming requests, any playing around with request order they might want to
> do, etc.

So how do you plan on implement the asyncronous variants then (i.e.
diskd / aufs)? Remember that Squid isn't threaded and must make use of
callbacks to acheive asyncronous operations. If the API isn't
asyncronous in design then building something asyncronous on-top (or
below) of it is not possible.

> Adrian believes that an async interface to the diskop layer would be better -
> he see's an advantage in genericness, such that plugging other fs'es on top of
> the ufs diskops might be possible. In particular, it means that the ufs
> diskop code could implement, for instance, elevator sorting on requests, and
> the fs layer wouldn't need to know about that.

I agree with adrian. If there is a common "diskop" API for the "ufs"
family of stores then this should be desingned as a asyncronous one. Two
of the three initial implementations will be very much asyncronous.

> I'm also opposed to the concept of another async layer below aufs, as aufs
> goes to great pains to make sure it's queueing is fast - adding another
> request queue under that would be very squirrely.

aufs already have one layer too many (3 in total).

and no, I do not see a need to add another layer. What you would be
doing is to cut aufs in it's already existing layer boundaries (and
hopefully eleminate the unneeded intermediary layer).

> disk.c is a kind of kernel for this work, in concept at least - but disk.c doesn't
> really go far enough, IMNSHO, as we've still got signficant duplication of
> code between the ufs-based fs'es. The base idea is to consolidate diskd,
> aufs, and ufs into one base library of diskop stuff, and separate code for the
> different paths from squid to diskop - immediate call in the case of ufs,
> queued in the case of aufs, and whatever diskd does in it's case ;)

I would start by trying to make a "ufs" library that can be used by the
"diskd/aufs/ufs" stores for the common FS operations (mainly directory
maintenance. I/O operations are very different between the three).

/Henrik
Received on Thu Mar 29 2001 - 03:23:46 MST