I have not had a stock kernel in quite a while. I imagine that there are some fixes in 3.7, but 3.8 is where all the awesome is (particularly on the GPU front).
At this point I would not consider BTRFS for stability, performance, nor longevity, due to the beta nature of it. I have not had any problems, and it seems to work well, but I believe it is still to early to make a judgement call. If you care about the data, use EXT4 for now. On Wed, Feb 20, 2013 at 2:56 PM, Greg King <[email protected]> wrote: > 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? > > ------------------------------ > *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: >> >>> 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 >> > > > _______________________________________________ > 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
