[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: file systems

In <4DC286BF.3060400@hardwarefreak.com>, Stan Hoeppner wrote:
>On 5/4/2011 6:44 PM, Boyd Stephen Smith Jr. wrote:
>> In<4DC1E009.30209@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:
>"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".

Boyd Stephen Smith Jr.                   ,= ,-_-. =.
bss@iguanasuicide.net                   ((_/)o o(\_))
ICQ: 514984 YM/AIM: DaTwinkDaddy         `-'(. .)`-'
http://iguanasuicide.net/                    \_/

Attachment: signature.asc
Description: This is a digitally signed message part.

Reply to: