Re: RAID needs more to survive a power hit, different /boot layout for example (was Re: draft howto on making raids for surviving a disk crash)

Linda Walsh
2008-02-05T12:31:19Z

Michael Tokarev wrote:
> note that with some workloads, write caching in
> the drive actually makes write speed worse, not better - namely,
> in case of massive writes.
----
With write barriers enabled, I did a quick test of
a large copy from one backup filesystem to another.
I'm not what you refer to when you say large, but
this disk has 387G used with 975 files, averaging about 406MB/file.

I was copying from /hde (ATA100-750G) to
/sdb (SATA-300-750G) (both, basically underlying model)

Of course your 'mileage may vary', and these were averages over
12 runs each (w/ + w/out wcaching);

(write cache on) write read
dev ave TPS MB/s MB/s
hde ave 64.67 30.94 0.0
sdb ave 249.51 0.24 30.93

(write cache off) write read
dev ave TPS MB/s MB/s
hde ave 45.63 21.81 0.0
xx: ave 177.76 0.24 21.96

write w/cache = (30.94-21.86)/21.86 => 45% faster
w/o write cache = 100-(100*21.81/30.94) => 30% slower

These disks have barrier support, so I'd guess the differences would
have been greater if you didn't worry about losing w-cache contents.

If barrier support doesn't work and one has to disable write-caching,
that is a noticeable performance penalty.

All writes with noatime, nodiratime, logbufs=8.

FWIW...slightly OT, the rates under Win for their write-through (FAT32-perf)
vs. write-back caching (NTFS-perf) were FAT about 60% faster over NTFS or
NTFS ~ 40% slower than FAT32 (with ops for no-last-access and no 3.1
filename creation)