On 05/09/11 14:51, � wrote: > Given 4 laptops, the most powerful of which was running BTRFS and the others > ext3 or ext4, all machines running Ubuntu 11.04 Natty 32-bit with a stock > Ubuntu 2.6.38-11 kernel, all machines were given the following FS-intensive > task :
(dpkg-intensive workload) > All 3 ext3 / ext4 machines took between 60 and 90 minutes to complete their > upgrade. > > BTRFS machine took 20 HOURS so far, still counting (ETA 15 minutes left). > > Wow. Impressive. I see similar behaviour on a single-disk workstation. This is a consequence of dpkg's heavy use of fsync() to ensure that changes to the filesystem are done safely, to try to ensure that a sudden crash or power interruption doesn't leave the machine in an inconsistent or unrecoverable state. (You can see that btrfs performs speedily if fsync is disabled via, for example, `eatmydata`. Which is not a production-worthy workaround for the majority of cases, but usefully highlights what's going wrong.) See also: https://bugs.launchpad.net/ubuntu/+source/dpkg/+bug/607632 http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=635993 Now, I don't know why btrfs is particularly slow with a (relatively?) fsync-heavy workload, though I do note that a commit went into 3.0 that improved some fsync workloads; see commit: 8e531cdfeb75269c6c5aae33651cca39707848da However, in my own testing, it doesn't seem to have improved matters significantly. There were also a number of fsync-related improvements made in 2.6.32; perhaps there have been regressions since then? It seems clear that the dpkg developers consider this to be reasonable behaviour on their part; is there any scope for improvements to be made to btrfs to cope better with this kind of workload? Or is this an unavoidable property of the datastructures it's using? Cheers, David -- David McBride <[email protected]> Department of Computing, Imperial College, London -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
