Re: Fwd: Apple Darwin disabled fsync?
От | Jim C. Nasby |
---|---|
Тема | Re: Fwd: Apple Darwin disabled fsync? |
Дата | |
Msg-id | 20050222053741.GL86914@decibel.org обсуждение исходный текст |
Ответ на | Re: Fwd: Apple Darwin disabled fsync? (Greg Stark <gsstark@mit.edu>) |
Ответы |
New wal_sync_method for Darwin?
|
Список | pgsql-hackers |
On Sun, Feb 20, 2005 at 10:50:35PM -0500, Greg Stark wrote: > > Peter Bierman <bierman@apple.com> writes: > > > I think the intent of fsync() is closer to what you describe, but the > > convention is that fsync() hands responsibility to the disk hardware. > > The "convention" was also that the hardware didn't confirm the command until > it had actually been executed... > > None of this matters to the application. A specification for fsync(2) that > says it forces the data to be shuffled around under the hood but fundamentally > the doesn't change the semantics (that the data isn't guaranteed to be in > non-volatile storage) means that fsync didn't really do anything. The real issue is this isn't specific to OS X. I know FreeBSD enables write-caching on IDE drives by default, and I suspect linux does as well. It's probably worth adding a big, fat WARNING in the docs in strategic places about this. -- Jim C. Nasby, Database Consultant decibel@decibel.org Give your computer some brain candy! www.distributed.net Team #1828 Windows: "Where do you want to go today?" Linux: "Where do you want to go tomorrow?" FreeBSD: "Are you guys coming, or what?"
В списке pgsql-hackers по дате отправления: