Re: filesystems

Kevin Littlejohn wrote:

> These two comments - that the actual I/O on disk is different between disk.c,
> diskd, and aufs - are narrowing in on the source of my confusion, I suspect.
> I was labouring under the belief that it would be possible to create a file,
> like disk.c, that all three ufs-based systems used for the actual talking to
> the disk. I'll go away for a while and try and figure out why aufs's
> aio_do_read is so different to disk.c's diskHandleRead - maybe that'll help me
> look more informed ;)

If you are comparing stuff at that level then sure, the difference is
quite small, but so is the functionality. The main difference is the
context in which the two executes.

Much of disk.c is overly complex and isn't really needed today. disk.c
is kind of a hybrid between syncronous and asyncronous I/O operations

aio_do_read is only a read() in the context of a AIO worker thread.
Can't be compared with much else. The functions you want to compare is
file_read() and aioRead(). They are both very similar in the API, but
differs greatly in the actual implementation (as it should).

The use of file_read/write in "ufs" can be deleted, simply replaced with
calls to read/write. The bulk of the routines in disk.c is overly
complex and not really needed. It is the way it is mostly because of two
reasons:
  a) Initial design wrongly beleived select() was useful for disk I/O..
  b) Async-IO was previously implemented via disk.c.

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.

/Henrik
Received on Thu Mar 29 2001 - 07:25:04 MST