NetNews Usenet Archive 1992 #18/NN_1992_18.iso/spool/comp/sys/acorn/8272

Internet Message Format | 1992-08-18 | 4.7 KB

Path: sparky!uunet!mcsun!uknet!acorn!osmith
From: [e-mail] (Owen Smith)
Newsgroups: comp.sys.acorn
Subject: Re: Poor write performance to MS-DOS disks?
Message-ID: <[e-mail]>
Date: 18 Aug 92 11:32:56 GMT
References: <[e-mail]>
Sender: [e-mail]
Organization: Acorn Computers Ltd, Cambridge, England
Lines: 77

In article <[e-mail]> [e-mail] writes:

>In article <[e-mail]>, [e-mail] (Jonathan Roach) writes:
>------------8<------------------8<---------------8<---------------
>> Now, if you apply this scheme to a DOS disc the whole disc starts going
>> 'data lost' and it is altogether horrible for the user and there is much
>> unhappiness. So, to get round this problem buffering on writing was
>> prohibited on DOSFS discs and, in fact on any whole disc exports. This
>> solution was chosen as time was getting short at this stage which kind of
>> ruled out the minor architectural rethink which was appropriate (move the
>> buffering into FileSwitch and split FileCore into 2 halves).
>>
>> So, what we have now is reads being buffered and writes not on DOSFS discs
>> which is why reads are OK in speed, and writes are slow.
>
> I prefer speed to accuracy.....
>
> The PCemulator writes 4 times faster than the #@$%$% desktop, i.e. for a 400k
>file, it takes the desktop 3 mintutes to write (with "Faster" on), c.f. 30 sec
>under the PCemulator; WHAT GIVES?

Jonathan forgot to say that he was merely describing ONE of the reasons for
DOSFS writes being slow, which is natural since its the one that caused him
much pain and angst. Jonathan's comments apply equally to RISC OS 3.10 and
3.00.

You are looking at a combination of factors here. Assuming the DOS disk is
being written with the filer, then you have Filer_Action (the desktop task
doing the multi-tasking copy etc.), FileCore (which handles the actual
reading and writing of the data to the media via. ADFS including
read-ahead/lack-of-write-behind and presents the file '$' ie. the disk to
FileSwitch and hence DOSFS), and DOSFS itself which does file I/O to the
file '$' and understands the format of DOS disks. FileSwitch does a tap
dance in the middle while co-ordinating all of this (working out whether the
file being opened is inside an image and if so opening $ as a file and
presenting that to the image filing system eg. DOSFS). As you can see its a
complex system. Features of one section of the software can have nasty
effects on the others. Jonathan was only really describing the constraints
in FileCore which lead to write-behind being disabled (and of course on 3.00
read-ahead and write-behind are always disabled on ALL disks when you set
ADFSBuffers to 0).

Another problem (which has already been mentioned) is that Filer_Action
tries to keep the desktop interactivity up by reducing the read/write block
size until it takes a short enough time. On RISC OS 3.00 DOSFS, writes are
NEVER as fast as Filer_Action wants them to be, so Filer_Action keeps
reducing the block size without noticing that the small block took just as
long to write as the previous larger block did. Eventually the blocks hit
the minimum size limit, and the transfer takes a lot longer than it would
with bigger blocks. Using the "Faster" option cures this problem. On RISC OS
3.10 (but not 3.00) Filer_Action also keeps the data transfer rate above a
certain level. So when the blocks get too small, it realises that it isn't
getting anywhere fast and bumps the block size back up again. Obviously you
have only seen 3.00 and so can't tell if the write speed is now acceptable.

Also on RISC OS 3.10 DOSFS itself has had quite a bit of work put into it
since 3.00. This also makes things go faster, depending of course on the
exact history of operations, current disk contents and current cache
contents. (DOSFS has a directory cache, and I think it also has a cluster
cache but I might be wrong.)

In conclusion I would ask you to defer judgement until you've upgraded
to RISC OS 3.10 and redone your timings on that.

Remember, it looks simple to the user but underneath you are dealing with a
complex system implemented in six different modules (ADFS, FileCore, DOSFS,
FileSwitch, Filer, Filer_Action) written in two languages (DOSFS and
Filer_Action are in C, the rest are in Assembler) written by different (and
changing) authors and at different times in the history of RISC OS. The
potential for strange and unexpected interactions and side effects is larger
than with much of the rest of RISC OS, and trying to understand all of
in in detail is daunting. Have you noticed how much of the PRMs is devoted
to filing systems?

Owen.

The views expressed are my own and are not necessarily those of Acorn.