I have re-run the raid tests with re-creating the fileset between each
of the random write workloads and performance does now match the
previous newformat results. The bad news is that the huge gain that I
had attributed to the newformat release, does not really exist. All of
the previous results(except for the newformat run) were not re-creating
the fileset, so the gain in performance was due only to having a fresh
set of files, not any code changes.
So, I have done 2 new sets of runs to look into this further. One is a 3
hour run of single threaded random write to the RAID system. I have
compared this to ext3. Performance results are here:
http://btrfs.boxacle.net/repository/raid/longwrite/longwrite/Longrandomwrite.html
and graphing of all the iostat data can be found here:
http://btrfs.boxacle.net/repository/raid/longwrite/summary.html
The iostat graphs for btrfs are interesting for a number of reasons.
First, it takes about 3000 seconds (or 50 minutes) for btrfs to reach
steady state. Second, if you look at write throughput from the device
view vs. the btrfs/application view, we see that for a application
throughput of 21.5MB/sec it requires 63MB/sec of actual disk writes.
That is an overhead of 3 to 1 vs an overhead of ~0 for ext3. Also,
looking at the change in iops vs MB/sec, we see that while btrfs starts
out with reasonable size IOs, it quickly deteriorate to an average IO
size of only 13kb. Remember, the starting file set is only 100GB on a
2.1TB filesystem, and all data is overwrite, and this is single
threaded, so there is no reason this should fragment. It seems like the
allocator is having a problem doing sequential allocations.
Another set of runs I did was to do repetitive 5 minute random write
runs. Results are here:
http://btrfs.boxacle.net/repository/raid/repeat/repeat/repeat.html
This shows the dramatic degredation after just a short time, but I
believe there is a fair amount of overhead in btrfs after newly mounting
the FS (which this test did between each run) so I repeated without
unmounting and remounting and results are here:
http://btrfs.boxacle.net/repository/raid/repeat-nomount/repeat/repeat-nomount.html
These results show a much less dramatic degradation, but btrfs still
degrades by over 40% in just 30 minutes of run time. In fact, it was
still degrading by 10% every 5 minutes when this test ended.
Steve
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
