Re: win32 performance - fsync question - Mailing list pgsql-hackers

From Greg Stark
Subject Re: win32 performance - fsync question
Date
Msg-id 87acq2xzdi.fsf@stark.xeocode.com
Whole thread Raw
In response to Re: win32 performance - fsync question  (Evgeny Rodichev <er@sai.msu.su>)
List pgsql-hackers
Evgeny Rodichev <er@sai.msu.su> writes:

> No, it does. Let's try the simplest test:
> 
> for (i = 0; i < LEN; i++) {
>     write (fd, buf, 512);
>     if (sync) fsync (fd);
> }
> 
> with sync = 0 and 1, and you'll see the difference.

Uh, I'm sure you'll see a difference, one will be limited by the i/o
throughput the IDE interface is capable of, the other will be limited purely
by the memory bandwidth and kernel syscall latency.

Try it with sync=1 and write caching disabled on your IDE drive and you should
see an even larger difference.


However, no filesystem and ide driver combination in linux 2.4 and afaik none
in 2.6 either issue any special ATA commands to force the drive to 


> > There was some talk on linux-kernel of what how they could take advantage
> > of new ATA features planned on new SATA drives coming out now to solve
> > this. But they didn't seem to think it was urgent or worth the performance
> > hit of doing a complete cache flush.
> 
> It was a bit different topic.

Well no way to tell if we're talking about the same threads. But in the
discussion I saw it was clear they were talking about adding an interface to
drivers so for filesystems to issue cache flushes when necessary to guarantee
filesystem integrity. They still didn't seem to get that users cared about
their data too, not just filesystem integrity.

-- 
greg



pgsql-hackers by date:

Previous
From: "Qingqing Zhou"
Date:
Subject: Re: win32 performance - fsync question
Next
From: Kevin Brown
Date:
Subject: Re: Help me recovering data