Axel Dörfler wrote:
Joseph Galbraith <galb@xxxxxxxxxxx> wrote:I don't know, but I suspect that this highly asynchronous model isn't handled by the existing code base for linux / BeOS, and that introducing it would account for much of the estimated time.
I also suspect it would make it pretty difficult to write a BeOS-fs emulation layer.
Unless I'm utterly wrong about filesystem I/O being pretty much synchronous for linux and BeOS?
BeOS device and file system I/O is synchronous only. But since a file system must be thread-safe and reentrant in BeOS anyway, having an asynchronous "backend" would probably be not that hard to support.
I expect the problematic fields in the cache and VM area, although I can't really say since I haven't seen the Windows API. But porting to/
from Linux is probably harder than it is to port to/from Windows.
So, if I understand correctly, during a read operation (grossly simplified) it would work something like this.
1. App calls read 2. Read syscall calls BeOS-fs layer (vfs layer?) 3. vfs layer calls file system driver's read interface 4. file system driver calls disk driver 5. disk driver programs controller and waits for data (blocking current thread.) 6. OS runs other threads while controller thinks. 7. Eventually controller interrupts saying data ready. 8. Thread is unblocked and disk driver returns to file system driver, which returns to vfs, which returns to read syscall which returns to application.
Under windows this looks like:
1. App calls read 2. Read syscall calls I/O manager 3. I/O manager calls file system driver's read interface 4. Read interface calls disk driver, passing in a function pointer to call when I/O is complete. 5. Disk driver programs controller and returns immediately with STATUS_PENDING (and no data.) 6. File system driver returns STATUS_PENDING to I/O manager, which propagates to the calling application. 7. Eventually the controller interrupts saying data is ready. 8. Disk driver calls I/O completion function in file system driver. 9. File system driver notifies the I/O manager that the I/O is complete. 9. I/O manager notifies application that I/O is complete.
So, in order for existing BeFS file system driver code to work on windows, it has to be changed to expect function return from the disk driver with no data, to return to it's caller w/ no data, and to expect the disk driver to call it at some other entry point, later, with the data.
If BeFS could really be rearchitected to handle this kind of thing without too much trouble, a port might not be that bad. (And don't get me wrong, a BeFS file system driver for windows would be way cool.)
Trying to do a wrapper which emulates the VFS code so that the BeFS filesystem code can run unchanged is even more problematic... it could be done, but since the BeFS filesystem code wants to block the thread, and windows doesn't want the thread blocked, everything would have to be marshaled into a thread that the wrapper layer owns (and can safely block.) I don't think this is going to win any performance contests, though it might not be too bad.
(The files system can block waiting for the disk driver to call it's completion routine; it just isn't allowed to block the calling thread in certain circumstances... in other words, it isn't hard to turn the asynchronous model into a synchronous one when permitted and convenient.)