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)
-
To unsubscribe from this list: send the line "unsubscribe linux-raid" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
