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? -- My Main Blog http://etbe.coker.com.au/ My Documents Blog http://doc.coker.com.au/
On 12/12/12 01:18, Russell Coker wrote:
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?
1) Does dropping discard help (some SSDs are awful with that) 2) Do you have the latest firmware on the drive? 3) Which kernel is this with? 4) Have you asked on the btrfs list about this? There are a couple of people there with experience of btrfs on different drives (Marc Merlin especially) who might be able to shed some light. cheers, Chris -- Chris Samuel : http://www.csamuel.org/ : Melbourne, VIC
Chris Samuel <chris@csamuel.org> writes:
On 12/12/12 01:18, Russell Coker wrote:
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?
1) Does dropping discard help (some SSDs are awful with that)
Also check (in /proc/mounts) if btrfs is detecting the SSD as non-rotational correctly. Also try force-unsafe-io in /etc/dpkg/dpkg.cfg if the fs is expendable.
On 12/12/12 11:50, Trent W. Buck wrote:
Also check (in /proc/mounts) if btrfs is detecting the SSD as non-rotational correctly.
Russel had mentioned he was specifying "ssd" as a mount option, so it shouldn't matter. cheers! Chris -- Chris Samuel : http://www.csamuel.org/ : Melbourne, VIC
On Wed, Dec 12, 2012 at 09:25:43AM +1100, Chris Samuel wrote:
On 12/12/12 01:18, Russell Coker wrote:
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?
1) Does dropping discard help (some SSDs are awful with that)
i've found (on xfs and ext4) that running fstrim regularly from cron (daily or weekly is frequent enough) is better for overall performance than turning on automatic trim using the ssd/discard mount options. I've just added fstrim commands to the bottom of my rsync backup scripts, so they get trimmed after every nightly backup run. BTW, fstrim is run on mounted filesystems. Note that when you run fstrim on an ext4 filesystem, ext4 remembers which blocks have already been trimmed, at least until the next time the fs is unmounted and remounted. xfs and btrfs (and presumably others) do not[1], they trim the entire unused block list every time. what this means is that the first trim on a freshly mounted ext4 fs will take much longer than subsequent fstrims. e.g. on an 80G ext4 partition on one of my SSDs, the first fstrim takes about 7 minutes, subsequent runs take seconds. for xfs and btrfs it always takes the same amount of time. [1] http://forums.fedoraforum.org/showthread.php?t=278532 craig ps: this is definitely still true for XFS. I haven't used btrfs in a while so i don't know if recent updates have improved fstrim for btrfs or not - the link above is from April 2012. -- craig sanders <cas@taz.net.au> BOFH excuse #295: The Token fell out of the ring. Call us when you find it.
On 12 December 2012 01:18, Russell Coker <russell@coker.com.au> 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....." Andrew
On 12/12/12 10:09, Andrew Worsley wrote:
On 12 December 2012 01:18, Russell Coker <russell@coker.com.au> 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.
Andrew Worsley writes:
http://www.h-online.com/open/features/What-s-new-in-Linux-3-7-1759862.html
FWIW, I prefer http://kernelnewbies.org/LinuxChanges
On Wed, Dec 12, 2012 at 01:18:20AM +1100, Russell Coker wrote:
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.
I know there was a solution to this, and sorry that my next question is slightly OT: Which file system would you recommend for SSD drive inside a laptop? Planning to have a / and /home partition, and swap for hibernation. Or is this partition scheme bad? Cheers, Dan
On Mon, 17 Dec 2012, Daniel Dalton <d.dalton@iinet.net.au> wrote:
Which file system would you recommend for SSD drive inside a laptop?
Currently I recommend Ext3/4 for /boot and for removable devices that are shared between Linux systems. For reasonably new systems I recommend BTRFS for every situation where ZFS isn't better, which mostly means every situation where you have only 2 disks or less than 8G of RAM.
Planning to have a / and /home partition, and swap for hibernation. Or is this partition scheme bad?
If you use BTRFS then I think that a single partition with multiple subvolumes is the better option. Swap has to be separate because BTRFS didn't support swap files last time I checked. -- My Main Blog http://etbe.coker.com.au/ My Documents Blog http://doc.coker.com.au/
participants (7)
-
Andrew Worsley -
Chris Samuel -
Craig Sanders -
Daniel Dalton -
Russell Coker -
Toby Corkindale -
trentbuck＠gmail.com