[prev in list] [next in list] [prev in thread] [next in thread]
List: debian-user
Subject: Re: file systems
From: "Boyd Stephen Smith Jr." <bss () iguanasuicide ! net>
Date: 2011-05-05 15:53:36
Message-ID: 201105051053.37256.bss () iguanasuicide ! net
[Download RAW message or body]
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:
>
>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. ,= ,-_-. =.
bss@iguanasuicide.net ((_/)o o(\_))
ICQ: 514984 YM/AIM: DaTwinkDaddy `-'(. .)`-'
http://iguanasuicide.net/ \_/
["signature.asc" (application/pgp-signature)]
--
To UNSUBSCRIBE, email to debian-user-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: http://lists.debian.org/201105051053.37256.bss@iguanasuicide.net
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic