[mirian@cosmic.com (Mirian Crzig Lennox) writes:]
>Linux gets a lot of its superior subjective performance from the fact
>that it caches disk writes so aggressively. VSTa, on the other hand, always
>tries to keep the disk in sync.
This is true... it really costs quite a bit of performance. But as an OS
experimenter, I find the hardness of the filesystem to be well worth the
slowdown on the occasional bulk data operations I do.
One other thing to note is that when doing "tar -z..." operations, you're
going through a pipe server which does very, very little buffering. An
interesting project for somebody would be to revisit this design aspect of
VSTa pipes. Right now the pipe server doesn't maintain a private copy of
the data (it blocks the writer until it can point the reader's I/O vectors
directly at the writer's data). This is cool, and shows the flexibility of
vectored I/O messages, but I suspect in the big picture it'd be better for
the pipe server to buffer quite a bit of data, to permit more concurrency
between reader and writer.
>>Also, untarring and gunzipping the vsta_src.tz file never finishes. It
>>always prematurely exits with a 'broken pipe' error.
It probably finished OK... Dave Hudson made the pipe server play with
compressed tar. But it has seemed like there's a race condition in there
somewhere. The few times I've looked, the final file of the archive had
been extracted OK, and thus I never gave much priority to fixing that
spurious error message.
Andy Valencia
Received on Mon Dec 25 08:44:54 2000
This archive was generated by hypermail 2.1.8 : Thu Sep 22 2005 - 15:12:57 PDT