From: | Greg Stark <gsstark(at)mit(dot)edu> |
---|---|
To: | pgsql-general(at)postgresql(dot)org |
Subject: | Re: Recomended FS |
Date: | 2003-10-27 16:36:10 |
Message-ID: | 87ismay6x1.fsf@stark.dyndns.tv |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
"scott.marlowe" <scott(dot)marlowe(at)ihs(dot)com> writes:
> Sweet. It may be that the promise is turning off the cache, or that the
> new generation of IDE drives is finally reporting fsync correctly. Was
> there a performance difference in the set with write cache on or off?
Check out this thread. It seems the ATA standard does not include any way to
make fsync work properly without destroying performance. At least on linux
even that much is impossible without disabling caching entirely as the
operation required isn't exposed to user-space. There is some hope for the
future though.
http://www.ussg.iu.edu/hypermail/linux/kernel/0310.2/0163.html
> > The other interesting possibility is that Freebsd with soft updates
> > helped things remain salvageable in the cache enabled case (as some
> > writes *must* be lost at power off in this case)....
>
> Free BSD may be the reason here. If it's softupdates are ordered in the
> right way, it may be that even with write caching on, the drives "do the
> right thing" under BSD. Time to get out my 5.0 disks and start playing
> with my test server. Thanks for the test!
I thought soft updates applied only to directory metadata changes.
--
greg
From | Date | Subject | |
---|---|---|---|
Next Message | Christoph Haller | 2003-10-27 16:39:36 | Re: extend INSERT by 'INSERT INTO table FETCH ... FROM cursor' syntax |
Previous Message | Grant Rutherford | 2003-10-27 16:30:41 | PostgreSQL with MS Query? |