On 12/12/12 10:09, Andrew Worsley wrote: > On 12 December 2012 01:18, Russell Coker <[email protected]> wrote: >> btrfs subvol snapshot -r /home /home/backup/$(date +%Y-%m-%d:%H:%M) >> >> The above command takes more than 10 seconds on a system with an Intel 120G >> SSD but less than 1 second on a system with a hard disk identified as >> "HITACHI >> HTS72201 DC2Z". >> >> Also I've noticed that every system which uses BTRFS on an Intel 120G SSD >> gives very poor performance when installing Debian packages (which calls >> sync()). I'm using the ssd and discard mount options. >> >> Does the Intel SSD just suck for the type of writes that BTRFS does when >> synchronising things or is there some way of tweaking it for performance? > > According to this link fsync is bad on btrfs - perhaps switching to > this latest 3.7 kernel might help? > > http://www.h-online.com/open/features/What-s-new-in-Linux-3-7-1759862.html > Filesystems: > > "...A range of optimisations for the still experimental Btrfs are > designed to speed up Fsync (File Sync). Applications can now use this > command to instruct the kernel to save data that is to be written to > the storage devices instead of keeping it in cache. The developers say > that these optimisations particularly improve the write performance of > virtual machines when the VM images are located on Btrfs filesystems > and the guest frequently requests Fsync; Btrfs previously had a > reputation for offering rather poor performance in such > scenarios....."
That's interesting to know. PostgreSQL always runs like a dog on btrfs, but maybe that was partly to blame. _______________________________________________ luv-main mailing list [email protected] http://lists.luv.asn.au/listinfo/luv-main
