On 2014-04-04 08:48, Swâmi Petaramesh wrote: > Le vendredi 4 avril 2014 08:33:10 Austin S Hemmelgarn a écrit : >>> However I'm still concerned with chronic BTRFS dreadful performance and >>> still find that BRTFS degrades much over time even with periodic defrag >>> and "best practices" etc. >> >> I keep hearing this from people, but i personally don't see this to be >> the case at all. I'm pretty sure the 'big' performance degradation that >> people are seeing is due to how they are using snapshots, not a result >> using BTRFS itself (I don't use them for anything other than ensuring a >> stable system image for rsync and/or tar based backups). > > Maybe I was wrong to suppose that if a feature exists, it is supposed to be > usable... I have used ZFS for years, and on ZFS having *hundreds* of snapshots > of any given FS have exactly zero impact on performance... > > With BTRFS, some time ago I tried to use SuSE "snapper" that passes its time > doing and releasing snapshots, but it soon made my systems unusable... > > Now, I only keep 2-3 manually made snapshots just for keeping a "stable and OK > archive of my machine in a known state" just in case... > > But if even this has a noticeable negative impact on BTRFS performance, then > what the hell are BTRFS snapshots good at ?? > > Kind regards. > I'm not saying that using a few snapshots is a bad thing, I'm saying that thousands of snapshots is a bad thing (I have actually seen people with hat many, including one individual who had almost 32,000 snapshots on the same drive). I personally do keep a few around on my system on a regular basis, even aside from the backups, and have no noticable performance degradation. For reference, the (main) system that I am using has a Intel Celeron 847 running at 1.1GHz, 4G of DDR3-1333 RAM, and a 500G 5400 RPM SATAII hard disk. My root filesystem is BTRFS volume mounted with autodefrag,space_cache,compress-force=lzo,noatime (the noatime improves performance (and power efficency) for btrfs because metadata updates end up cascading up the metadata tree (updating the atime on /etc/foo/bar causes the atime to be updated on /etc/foo, which causes the atime to be updated on /etc, which causes the atime to be updated on /) -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
