Re: Slow Filesystem I/O

From: Alan Greig (greigaln_at_netscape.net)
Date: 04/24/05 

Date: 24 Apr 2005 13:15:56 -0700

Bill Todd wrote:

>
>
> My (admittedly vague) recollection is that (for obvious reasons)
> Spiralog did not change *default* file system behavior in any
> application-visible way, but rather made a considerably richer set of

> options available (some of which may, of course, have been options to

> change the default behavior manually). So I don't understand how
> Spiralog itself could have affected RMS's default performance nearly
> that much (e.g., when RMS specified that its internal buffer should
be
> written to disk, it had the right to assume that it indeed had been
> written when the QIO completed, so Spiralog would have had to respect

> that right by performing a synchronous disk write: yes, it could
have

Spiralog allowed the user to over-ride the default on a directory
and/or per file basis. If you told it to use 'unsafe' write-back
caching on a file it would. QIO completion in this case meant that the
write had made it to Spiralog but not the physical disk. This was fully
documented and only happened if you explicitly selected the riskiest
option. For a news server where I really didn't care if every last item
made it to disk after a crash it made sense to go for the fastest
option. I also alternated the news item storage across two Spiralog
volumes - reinitialising them often. Another app it really speeded up
was purveyor web cache. Again losing the odd cache item would not be a
problem. Moving some students (it was a university) onto Spiralog
volumes caused a stream of them to turn up at my door asking how I had
speeded up the Alpha so much.

> - bill