Re: file systems



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.



Relevant Pages

  • Re: file systems
    ... This is true only if you don't have BBWC. ... "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. ... Because constantly flushing an entire 16-64 *GigaByte* battery or flash backed write cache, sitting in front of 2048 SAS drives, because 64 servers on the SAN keep issuing barriers at the rate of 10,000/second, is a mind numbingly dumb thing to do. ... 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." ...
    (Debian-User)
  • Re: file systems
    ... behavior in the face of sudden pwoer loss. ... This is true only if you don't have BBWC. ... With barriers, you a guaranteed to be able to recover to the last barrier. ... You just said you "disagree entirely" and then say 128 threads, ...
    (Debian-User)
  • Re: file systems
    ... XFS only journals metadata not file data. ... Barriers are not used by XFS to guarantee write order. ... Then I'd say you have a problem with your BBWC RAID controller in your desktop. ... Again, with a quality BBWC implementation, using barriers simply decreases performance. ...
    (Debian-User)
  • Re: Ada advocacy
    ... something-like Ada protected objects (without barriers -- that's ... a big loss). ... They did have barriers, but Brinch Hansen and Hoare differed as to whether ... region V await C do ...
    (comp.lang.ada)
  • Re: OUTSTANDING JOB MICHAEL!!
    ... barriers and stopped, in the most gentle fashion without any obvious ... loss of control of either the front or back end, ...
    (rec.autos.sport.f1)