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
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 |