filesystems

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.

(For reference, we're using diskop to refer to whatever makes the actual
read() write() etc. calls, and fs to refer to the queueing code/the code that
handles receipt of request from squid, and putting request on "done" list)

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.

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'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.

(Adrian, if I missed anything, please lemme know ;)

We need second (and third, etc) opinions ;)

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 ;)

KevinL

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