Path: utzoo!utgpu!news-server.csri.toronto.edu!rutgers!usc!samsung!munnari.oz.au!metro!cluster!steve
From: steve@cs.su.oz (Stephen Russell)
Newsgroups: comp.os.minix
Subject: Re: FS
Message-ID: <1101@cluster.cs.su.oz>
Date: 19 Jul 90 15:04:42 GMT
References: <877@sce.carleton.ca> <628@philica.ica.philips.nl> <1685@tuvie>
Sender: news@cluster.cs.su.oz
Reply-To: steve@cluster.cs.su.oz (Stephen Russell)
Organization: Basser Dept of Computer Science, University of Sydney, Australia
Lines: 45

In article <628@philica.ica.philips.nl> adrie@beitel.ica.philips.nl (Adrie Koolen) writes:
>                The best solution to this problem would be to re-implement
>the FS as a 'stated' FS which returns to the main FS loop to send or
>receive messages. [...] An easier method would be to create e.g. 3 FS threads.

In article <1685@tuvie> inst182@tuvie.UUCP (Inst.f.Techn.Informatik) replied:
>Yes that's possible, but I think one stated FS with queues is more elegant
>than a fixed number of FS threads.

The main loop of the stated FS is elegant, but the rest of the code is
rather messy. The problem is that a single user transaction may result
in multiple transactions with the device task, and these transactions
often occur in `inconvenient' places.

For example, consider scanning a directory for a matching file name
(the Unix namei() function). This contains a loop that reads blocks.
Somehow we must break out of this loop to get back to the main state
machine, and return to the search loop with the context (the dir
offset, the search string, etc) restored after the IO is completed. I'm
sure the Minix FS contains many other examples of deeply nested IO.

Making this work with a single-thread FS is complicated. Basically, the
_whole_ FS must be rewritten to `flatten' it out, and the context of
each transaction is kept in (static) structures. This is a major
rewrite.

The multi-threaded approach keeps almost all of the existing code, and
lets the OS look after keeping track of the context of each
transaction.  The cost is extra stack space for each thread.

In article <628@philica.ica.philips.nl> adrie@beitel.ica.philips.nl (Adrie Koolen) also wrote:
>A FS thread cannot
>be interrupted by another FS thread, only by tasks. This feature can be
>used to guarantee the consistency of the FS tables.

I'm not sure this is always true, though. It is possible that while one
thread is blocked, the FS state may be changed by another thread in a
way that causes problems.

A new question: can the Minix IO tasks support a multi-thread FS? The
major requirement is the ability to accept all pending requests
messages, pick the `best' one to service, and reply to that request
when it is finished. If not, the whole issue is moot.

Cheers