In <4DC1E009.firstname.lastname@example.org>, Stan Hoeppner wrote: >On 5/2/2011 4:02 PM, Boyd Stephen Smith Jr. wrote: >> They are also essential for any journaled filesystem to have correct >> behavior in the face of sudden pwoer loss. > >This is true only if you don't have BBWC. No. It is true even with BBWC. >> Even with a a battery-packed RAID cache, like I have in my desktop, >> executing without barrier can result in extra data loss that executing >> with a barrier prevents. > >Then I'd say you have a problem with your BBWC RAID controller in your >desktop. Which BBWC RAID card do you have? Areca ARC-1160. >> Of course, even with out barriers a properly journaled or log-structed >> filesystem should be able to immediately and silently recover. > >This contradicts what you stated above. No, it doesn't. The filesystem can recover by dropping or replaying journal / log entries that were not yet flushed to disk. That doesn't mean you haven't lost any data, if parts of the journal that existed in cache before the power failure. With barriers, you a guaranteed to be able to recover to the last barrier. Without them, the hardware many have fully, partially, of not-at-all completed virtually any I/O. >This is why (good) BBWC enabled RAID cards automatically disable the >caches on all the drives, Mine provides the option. I can't remember what setting I'm using right now. IIRC, I continue to use the drives write cache because I have a UPS that provides enough time for a clean shutdown, even when under load. >and thus why it is recommended to disable >barriers for filesystems on BBWC RAID cards. By whom? Reference please. >>> The nobarrier results are far more relevant than the barrier results, >>> especially the 16 and 128 thread results, for those SAs with high >>> performance persistent storage. >> >> I disagree entirely. You should be looking at the threaded results, >> probably 128 threads (depending on what the server does), but you should >> also be using barriers. > >You just said you "disagree entirely" and then say 128 threads, same >thing I said. But then you recommend barriers, which is the disagreement. You said 128 threads unconditionally, I admitted that there are certain workloads where 16 threads is a more correct model. -- Boyd Stephen Smith Jr. ,= ,-_-. =. email@example.com ((_/)o o(\_)) ICQ: 514984 YM/AIM: DaTwinkDaddy `-'(. .)`-' http://iguanasuicide.net/ \_/
Description: This is a digitally signed message part.