Thanks for the info Gustin.
At this point I'm just experimenting, but I'm considering converting my main desktop - a quad core 8G system with a 240G Samsung 840 SSD. I also run VMs and I'm hoping the copy on write will help the SSD work reliably for longer. I'd rather use a stock distro so I'll probably wait until Ubuntu/Mint ships with a 3.8 kernel, which won't be until at least 13.10 . Have you tried btrfs in the 3.7 kernel which will be in Ubunti 13.04? ----- Original Message ----- From: "Gustin Johnson" <[email protected]> To: "CLUG General" <[email protected]> Sent: Wednesday, 20 February, 2013 1:51:52 PM Subject: Re: [clug-talk] BTRFS experience I am using BTRFS on my laptop (well, on one of the three SSDs). I am using Ubuntu 12.10 with a custom built 3.8 kernel. On this system BTRFS just flies. It rivals EXT4 in performance, at least with respect to running multiple VMs. I can't do an exact comparison since the SSD that the VMs live on is a better device than the EXT4 device (I have the BTRFS volume on a samsung 840 pro, while EXT4 lives on a Crucial M4 Internal mSATA). If you are using any kind of SD card, I would recommend EXT2 as the filesystem. The performance is going to be worse than a traditional spinning metal disk regardless of the filesystem, even with a Class 10 SD. You really do not want the over head of a journal which will negatively impact the performance and longevity of the SD card. I remember benchmarking the SSD that came with my Acer Aspire One netbook, and I was less than impressed. It was no better than the standard laptop drives of the day. You really want to play on a beefier machine. It does not have to be an extremely powerful PC, but I would stay away from anything Atom based. A core2duo or above should suffice. On Tue, Feb 19, 2013 at 1:26 AM, Greg King < [email protected] > wrote: I see the Mint 14 uses the 3.5 kernel, so I loaded it on the eeePC with btrfs and did the same sequence. It went a lot faster ~3 hours, but it's not an apples to apples comparison since the update load was completely different. btrfs seems to work better with the 3.5 kernel tho, and the btrfs command has many more options so the file system is more complete. Greg From: "Anand Singh" < [email protected] > To: "CLUG General" < [email protected] > Sent: Monday, 18 February, 2013 11:39:31 AM Subject: Re: [clug-talk] BTRFS experience At this point Ext4 is faster than BTRFS. Even under Linux 3.8, which saw significant performance improvements for BTRFS, Ext4 is still faster, especially with random file reads. If you enable LZO compression on btrfs, you will notice a big jump in performance, but I don't know what impact that will have on RAID, snapshots, clones, etc. Note that only files created after compression is enabled will be affected, so it is best to enable this option during installation. It's smart enough to avoid compressing large binaries. In addition to a boost in performance, I appreciate having a few extra bytes available on my tiny SSD. Anyone remember Stacker? Unlike that system, BTRFS compresses files individually, and does not use a compressed volume. Anand. On 2013-02-18 10:46 AM, "Greg King" < [email protected] > wrote: <blockquote> At the last CLUG meeting there was some discussion around btrfs (binary tree file system), a copy on write file system that is friendlier towards SSDs and enables some great features like snapshots and raid. I decided to take it for a spin on my old eeePC 4G. It is one of the original eeePC with 512MB RAM and a 4G internal SSD. Linux Mint 13 (Maya) has outgrown the 4G internal SSD, so I used an 8G SDHC card for the OS. Mint/Ubuntu install lets you select the btrfs file system at install time, or you can convert from ext3/4 afterwards. I chose to install with btrfs and it worked without issues. There is a harmless bug in one of the startup scripts that causes the error message "Sparse file is not allowed" on reboots. It can be easily fixed by commenting out the offending check in the startup script, or installing /boot on an ext3/4 partition. So far everything looked great. Then I ran Mint update to bring the OS up to current software levels. It ran for about 28 hours! I had previously installed Maya on the same system with ext4 and I don't remember how long the update took, but it was no more than 2 or 3 hours at most. It appears as though btrfs needs lots of resources to perform, although it is promoted as higher performance than ext3/4. I haven't used the system much since the install. Even with xfce it is sluggish but usable. Maya is based on the latest Ubuntu long term support 12.04 which has kernel 3.2.0 . btrfs docs recommend the latest kernel possible since btrfs is under heavy development. Both SUSE and Oracle are claiming btrfs is ready for production service. Anyone else have experience with btrfs? How does it perform on more capable hardware? Is there a kernel level below which it should be avoided? _______________________________________________ clug-talk mailing list [email protected] http://clug.ca/mailman/listinfo/clug-talk_clug.ca Mailing List Guidelines ( http://clug.ca/ml_guidelines.php ) **Please remove these lines when replying _______________________________________________ clug-talk mailing list [email protected] http://clug.ca/mailman/listinfo/clug-talk_clug.ca Mailing List Guidelines ( http://clug.ca/ml_guidelines.php ) **Please remove these lines when replying _______________________________________________ clug-talk mailing list [email protected] http://clug.ca/mailman/listinfo/clug-talk_clug.ca Mailing List Guidelines ( http://clug.ca/ml_guidelines.php ) **Please remove these lines when replying </blockquote> _______________________________________________ clug-talk mailing list [email protected] http://clug.ca/mailman/listinfo/clug-talk_clug.ca Mailing List Guidelines (http://clug.ca/ml_guidelines.php) **Please remove these lines when replying
_______________________________________________ clug-talk mailing list [email protected] http://clug.ca/mailman/listinfo/clug-talk_clug.ca Mailing List Guidelines (http://clug.ca/ml_guidelines.php) **Please remove these lines when replying
