Re: win32 performance - fsync question

From: Greg Stark <gsstark(at)mit(dot)edu>
To: Evgeny Rodichev <er(at)sai(dot)msu(dot)su>
Cc: Greg Stark <gsstark(at)mit(dot)edu>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: win32 performance - fsync question
Date: 2005-02-18 04:31:37
Message-ID: 87acq2xzdi.fsf@stark.xeocode.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers


Evgeny Rodichev <er(at)sai(dot)msu(dot)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

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Kevin Brown 2005-02-18 05:38:55 Re: Help me recovering data
Previous Message Qingqing Zhou 2005-02-18 03:18:10 Re: win32 performance - fsync question