[ros-kernel] AW: Re: making vfat asynchronous

[Hartmut B. <har...@te...>]

> -----Ursprungliche Nachricht-----
> Von:	Phillip Susi [SMTP:ps...@cf...]
> Gesendet am:	Freitag, 9. November 2001 02:40
> An:	ros...@re...
> Betreff:	[ros-kernel] Re: making vfat asynchronous
>
> At 06:57 PM 11/8/2001 +0100, you wrote:
> >A FSD handle all accesses to files synchronous. There are some 
differences
> >between read/write and paged/nonpaged operations. When the caller can't
> >block, the FSD handle the request in created thread. Why can't a FSD not
> >use the worker queue from kernel?
>
> Our FSD is synchronous, yes, but it should not be.  Implementing async
> behavior by switching to another thread, which then blocks is a very poor 

> kludge.  A while back async IO on Linux was implemented just this way in
> libc, and as a result, noone used it because it sucked.  WSAAsyncSelect() 

> in winsock is also implemented by having another thread call select, 
which
> is why it doesn't scale well either.  Async IO really needs to be done
> anachronously, with no thread switching.  This means that the FSD code
> needs to be rewritten so that if it needs to do IO, it queues up the
> request to the underlying driver, and returns STATUS_PENDING, rather than 

> blocking on sync IO to the underlying device, even if this is done in
> another thread.
>
> When using the other thread blocks kludge, async IO ends up causing a
> thread switch, just so the other thread can queue up the request, and 
then
> switch back.  This adds the overhead of 2 switches per async IO call, and 

> also requires a pool of threads that must literally sit around with their 

> thumbs up their rear ends most of the time.  This finite pool of threads
> then limits the number of pending async IO calls, and wastes resources on 

> threads that do very little work.

Each driver, that will handle i/o asynchronous, needs context switching. 
For a lower level driver, which access hardware directly, is this an 
interrupt service routine or for a polling device a timer dpc. A higher 
level driver use for this worker threads or anything else. Each 
asynchronous i/o has at least two context switches.

> >Correct, the vfat driver must be rewritten. But the driver needs also 
more
> >support from kernel. There is no implementation of a cache manager like 
NT,
>
> I think this is no longer the case.  While David has implemented the ros
> cache manager differently than the way NT does it ( which I vehemently
> disagree with ), didn't you recently add CcCopy* interfaces to the cache
> manager?  So what else is missing?

The current cache manger can only handle small memory segments. This 
results in many calls to the fsd, when there is a read or write with large 
datas, which are not in the cache. The cooperation betwen the cache and the 
memory manger isn't good. Each missing page results in a single call to the 
fsd for 4K page. The cache manager has no read ahead or delayed write 
function. But this is not only the problem of the cache or memory manger. 
Vfatfs must also provide some functions for the cache manager.

> >the security functions doesn't work and many other functions doesn't 
work
>
> Security functions we don't need to worry about just yet, and can easily 
be
> added later with only small changes to the code.

Vfat doesn't need the complete security functions. When a file/directorie 
is created/opened, vfat needs informations over the access and share 
rights. Many kernel components calls the open file function without any 
share access rights. A second open for a dll (msvcrt.dll, ..) will fail, 
when vfat handle access rights.

> What other functions don't work right all of the time, and when do they 
fail?

Some functions, which can handle asynchronos access from user mode, fails. 
They access datas, that are not available after an asynchronous operation 
or they wait for the completion, but the calling function should wait for 
the completion.

When there is a complete/large rewrite for vfat or an other fsd or redir  
ector, the kernel needs also a rewrite. This the reason, why I think, that 
is better, to do some small steps.

- Hartmut

====================================================
= To remove yourself from this mailing list, go to =
= http://www.reactos.com/home/mailing.html         =
====================================================