On Thu, Nov 6, 2008 at 4:04 PM, Kevin Grittner <Kevin.Grittner@xxxxxxxxxxxx> wrote: >>>> "Scott Marlowe" <scott.marlowe@xxxxxxxxx> wrote: >> On Thu, Nov 6, 2008 at 3:33 PM, Kevin Grittner >> <Kevin.Grittner@xxxxxxxxxxxx> wrote: >>>>>> "Scott Marlowe" <scott.marlowe@xxxxxxxxx> wrote: >>>> I am pretty sure that with no write barriers that even a BBU >>> hardware >>>> caching raid controller cannot guarantee your data. >>> >>> That seems at odds with this: >>> >>> http://oss.sgi.com/projects/xfs/faq.html#wcache_persistent >>> >>> What evidence to you have that the SGI XFS team is wrong? >> >> Without write barriers in my file system an fsync request will >> be immediately returned true, correct? > > Not as I understand it; although it will be pretty fast if it all fits > into the battery backed cache. OK, thought exercise time. There's a limited size for the cache. Let's assume it's much smaller, say 16Megabytes. We turn off write barriers. We start writing data to the RAID array faster than the disks can write it. At some point, the data flowing into the cache is backing up into the OS. Without write barriers, the second we call an fsync it returns true. But the data's not in the cache yet, or on the disk. Machine crashes, data is incoherent. But that's assuming write barriers work as I understand them. -- Sent via pgsql-performance mailing list (pgsql-performance@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-performance
