Re: file systems
- From: "Boyd Stephen Smith Jr." <bss@xxxxxxxxxxxxxxxxx>
- Date: Thu, 5 May 2011 10:53:36 -0500
In <4DC286BF.3060400@xxxxxxxxxxxxxxxxx>, Stan Hoeppner wrote:
On 5/4/2011 6:44 PM, Boyd Stephen Smith Jr. wrote:
In<4DC1E009.30209@xxxxxxxxxxxxxxxxx>, 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@xxxxxxxxxxxxxxxxx ((_/)o o(\_))
ICQ: 514984 YM/AIM: DaTwinkDaddy `-'(. .)`-'
http://iguanasuicide.net/ \_/
Attachment:
signature.asc
Description: This is a digitally signed message part.
- References:
- Re: file systems
- From: Boyd Stephen Smith Jr.
- Re: file systems
- From: Stan Hoeppner
- Re: file systems
- Prev by Date: Re: file systems
- Next by Date: Re: MySQL Server Rebooting Automatically?
- Previous by thread: Re: file systems
- Next by thread: Re: file systems
- Index(es):
Relevant Pages
|