Re: Create and drop temp table in 8.3.4

On Thu, Nov 6, 2008 at 4:04 PM, Kevin Grittner
<Kevin(dot)Grittner(at)wicourts(dot)gov> wrote:
>>>> "Scott Marlowe" <scott(dot)marlowe(at)gmail(dot)com> wrote:
>> On Thu, Nov 6, 2008 at 3:33 PM, Kevin Grittner
>> <Kevin(dot)Grittner(at)wicourts(dot)gov> wrote:
>>>>>> "Scott Marlowe" <scott(dot)marlowe(at)gmail(dot)com> 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.