Re: no universally correct setting for fsync
От | Greg Stark |
---|---|
Тема | Re: no universally correct setting for fsync |
Дата | |
Msg-id | u2n407d949e1005101046weac382a6g99a5c932d4c5b736@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: no universally correct setting for fsync ("Kevin Grittner" <Kevin.Grittner@wicourts.gov>) |
Ответы |
Re: no universally correct setting for fsync
Re: no universally correct setting for fsync |
Список | pgsql-hackers |
On Mon, May 10, 2010 at 4:55 PM, Kevin Grittner <Kevin.Grittner@wicourts.gov> wrote: > Robert Haas <robertmhaas@gmail.com> wrote: > >> "It might be safe" is a bit of a waffle. It would be nice if we >> could provide some more clear guidance as to whether it is or is >> not, or how someone could go about testing their hardware to find >> out. > > I think that the issue is that you could have corruption if some, > but not all, disk sectors from a page were written from OS cache to > controller cache when a failure occurred. The window would be small > for a RAM-to-RAM write, but it wouldn't be entirely *safe* unless > there's some OS/driver environment where you could count on all the > sectors making it or none of them making it for every single page. > Does such an environment exist? The reason for the waffle is that the following sentence describes a whole set of environments based the following description: > > ? ? ? ?if you have hardware (such as a battery-backed > > ? ? ? ?disk controller) or file-system software that reduces the risk > > ? ? ? ?of partial page writes to an acceptably low level Depending on which set of hardware and how low the risk is it might be safe. I think with WAFL or ZFS it's entirely safe. There may be other filesystems with similar guarantees. With a BBU the risk might be very low -- but it might not, it would be hard to determine without a detailed analysis of the entire stack from the buffer cache, filesystem, lvm, hardware drivers, BBU design, etc. -- greg
В списке pgsql-hackers по дате отправления: