In <4dc286bf.3060...@hardwarefreak.com>, Stan Hoeppner wrote: >On 5/4/2011 6:44 PM, Boyd Stephen Smith Jr. wrote: >> In<4dc1e009.30...@hardwarefreak.com>, 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. > >No, it's not. Sorry I didn't find any Debian documentation to prove my >point. I'll use Red Hat docs: > >http://docs.redhat.com/docs/en-US/Red_Hat_Enterprise_Linux/6/html/Storage_Ad >ministration_Guide/writebarrieronoff.html > >"For devices with non-volatile, battery-backed write caches and those >with write-caching disabled, you can safely disable write barriers at >mount time using the -o nobarrier option for mount. However, some >devices do not support write barriers; such devices will log an error >message to /var/log/messages (refer to Table 17.1, “Write barrier error >messages per file system”)." > >"Write barriers are also unnecessary whenever the system uses hardware >RAID controllers with battery-backed write cache. If the system is >equipped with such controllers and if its component drives have write >caches disabled, the controller will advertise itself as a write-through >cache; this will inform the kernel that the write cache data will >survive a power loss."
I stand corrected. >>>> 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. > >Can you kindly point me to your past posts where you discussed this >'extra data loss' problem you experienced? I didn't experience data loss and I didn't mean to imply that I had been the victim of my RAID card. >>>>> 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. > >The multi-thread tests are simply used to show how each filesystem >scales with parallel workloads. Some servers will never see 16 parallel >IO streams, such as most SOHO servers. Some servers will see thousands >of simultaneous IO streams, such as the Linux kernel archives servers. >There is no "correct model". Agreed. -- Boyd Stephen Smith Jr. ,= ,-_-. =. b...@iguanasuicide.net ((_/)o o(\_)) ICQ: 514984 YM/AIM: DaTwinkDaddy `-'(. .)`-' http://iguanasuicide.net/ \_/
signature.asc
Description: This is a digitally signed message part.
