Subject: Re: [linux-audio-dev] Re: File writes with O_SYNC slow
From: Benno Senoner (sbenno_AT_gardena.net)
Date: Thu Apr 20 2000 - 11:57:15 EEST
On Thu, 20 Apr 2000, Eric W. Biederman wrote:
> "Benjamin C.R. LaHaise" <blah_AT_kvack.org> writes:
>
> > On Wed, 19 Apr 2000, Karl JH Millar wrote:
> >
> > > Furthermore, doing a write and then a fsync should be *just* as slow as a
> > > synchronous write, but I'm measuring it as over 10 times faster.
> >
> > Doing synchronous writes involves synching metadata for every 4KB of data,
> > not the entire 256KB chunk.
>
> Or more precisely for ever (data or indirect) block appended to the
> file there is a metadata sync. Plus a forced write of the data
> blocks every 32 data blocks written...
>
> The metadata sync will kill you on appends whichever way you slice it.
>
> For the practical effect of keeping dirty buffers down write+fsync
> looks like a better choice than using O_SYNC...
>
> Eric
I tried all combinations using my hdtest.c which I posted yesterday.
I tried O_SYNC and even O_DSYNC on the SGI (Origin 2k),
(D_SYNC syncs only data blocks but not metadata blocks)
both only delivering 3.5MBytes/sec. (plain buffered writes were about
15-16MB/sec).
write() + fsync()/fdatasync() on linux doesn't work well too since the kernel
isn't able to optimize disk writing by using the elevator algorithm.
You can try this in by trying to fsync()/fdatasync() all output descriptors
in the disk_thread routine.
I tried:
A)
for each output file {
write();
fsync() or fdatasync();
}
B)
for each output file {
write();
}
for each output file {
fsync() or fdatasync();
}
C)
for each output file {
write();
}
and every N seconds (I tried with N ranging from 1 to 20),
I call fsync() / fdatasync() or sync() in general,
in order to flush buffers to disk.
all three methods with all combinations of fsync()/fdatasync() failed,
and the IO performance was inferior to the plain write()s
(wihout any data synching).
for example the B) method in the single threaded case gives me
3.5MB/sec instead of 8.5MB/sec without fdatasync()
and the A) method in the multithreaded case, gives me 5MB/sec,
instead of 8MB/sec without fdatasync()
As you can see the performance drop ranges from 30-60% which is simply
not acceptable for demanding applications.
For now if you want to do HD recording on linux with many tracks on an EIDE
disk, (SCSI seems to behave better,standing to Paul's findings) the only chance
to succeed is to buy LOTS of RAM (with 2MB/track you can squeeze out quite the
maximum out of your disk), to overcome to these long lasting (6-8secs)
filesystem stalls.
I still can't believe that windoze uses only 256kb buffers, because there is no
big chance to optimize writes using the elevator algorithm.
I guess that they delivers fewer tracks ( = less total MB/sec throughput)
Benno.
This archive was generated by hypermail 2b28 : Thu Apr 20 2000 - 13:17:43 EEST