| View previous topic :: View next topic |
| Author |
Message |
devsk
Advocate
Joined: 24 Oct 2003
Posts: 2995
Location: Bay Area, CA
|
 Posted: Sun Dec 27, 2009 1:20 am Post subject: |
 |
|
There are no performance gains over any filesystem that I know of.
It seems stable with 2.6.32 and 2.6.33-rc2. But regular backups and keeping the kernel uptodate may be required.
Out of space is now handled.
No known issues with NFS. I use CIFS and that seems to be working fine.
You wanna use btrfs for its internal RAID management, efficient small file handling (750MB portage dir on ext4 vs 280MB portage dir on btrfs), data checksumming (biggest PLUS because bigger drives mean more chance of hardware errors) and compression related gains (my / size went from 13GB to 7GB). You don't wanna use it for performance enhancements, because there are none. |
|
| Back to top |
|
 |
ToeiRei
Veteran
Joined: 03 Jan 2005
Posts: 1191
Location: Austria
|
| Posted: Sun Dec 27, 2009 11:07 am Post subject: |
|
|
I am running my rootfs on btrfs since quite some time (September 22nd, 2009) and the system is still alive. Cannot say that it was a bad way to go for me... although I am happy to have good backups 
_________________
Please stand by - The mailer daemon is busy burning your messages in hell... |
|
| Back to top |
|
|
BlueFusion
Guru
Joined: 08 Mar 2006
Posts: 371
|
| Posted: Sun Dec 27, 2009 10:13 pm Post subject: |
|
|
Thank you both for your input.
| devsk wrote: | | You don't wanna use it for performance enhancements, because there are none. |
I was under the impression that with btrfs in a RAID-5 like state or whatever different RAID models it may contain, that it speeds up by operating across several disks. I have used ZFS on an X4500 (48 SATA drives) and using RAID-Z was easily able to sustain 300MBps network throughput (yes, MB/sec) because of the drive balancing. I was hoping btrfs has or will have a similar ability.
_________________
i7-940 2.93Ghz | ASUS P6T Deluxe (v.1) | 24GB Triple Channel RAM | nVidia GTX660
4x 4TB Seagate NAS HDD (Btrfs raid5) | 2x 120GB Samsung 850 EVO SSD (Btrfs raid1) |
|
| Back to top |
|
|
devsk
Advocate
Joined: 24 Oct 2003
Posts: 2995
Location: Bay Area, CA
|
| Posted: Sun Dec 27, 2009 11:52 pm Post subject: |
|
|
| BlueFusion wrote: | Thank you both for your input.
| devsk wrote: | | You don't wanna use it for performance enhancements, because there are none. |
I was under the impression that with btrfs in a RAID-5 like state or whatever different RAID models it may contain, that it speeds up by operating across several disks. I have used ZFS on an X4500 (48 SATA drives) and using RAID-Z was easily able to sustain 300MBps network throughput (yes, MB/sec) because of the drive balancing. I was hoping btrfs has or will have a similar ability. |
Of course. As I said, you can use btrfs's internal raid to throw multiple devices at it in a raid0, raid1 or raid10 configuration. RAID will give you much better performance. But that's not apple to apple comparison with ext4, for example. Try running ext4 on software raid vs btrfs raid, and you will either not find a winner or ext4 will come out on top slightly. There is a cost-benefits trade off with checksumming every block. As btrfs becomes mature, performance improvements will come with time! |
|
| Back to top |
|
|
BlueFusion
Guru
Joined: 08 Mar 2006
Posts: 371
|
| Posted: Mon Dec 28, 2009 8:45 pm Post subject: |
|
|
So at the current time, using software RAID and ext4 would yield just about the same performance? Well then if that's the case I guess it will come down to data integrity. I am somewhat familiar with the reason for checksumming, but in reality, does btrfs' checksums or etx4 have better data integrity? Is btrfs as capable of a power failure as ext3/4 is with journalling? I did already have ext4 fail me a few months ago and destroyed all data on my 1TB drive. I had backups, luckily though
_________________
i7-940 2.93Ghz | ASUS P6T Deluxe (v.1) | 24GB Triple Channel RAM | nVidia GTX660
4x 4TB Seagate NAS HDD (Btrfs raid5) | 2x 120GB Samsung 850 EVO SSD (Btrfs raid1) |
|
| Back to top |
|
|
devsk
Advocate
Joined: 24 Oct 2003
Posts: 2995
Location: Bay Area, CA
|
| Posted: Mon Dec 28, 2009 10:13 pm Post subject: |
|
|
| BlueFusion wrote: | | So at the current time, using software RAID and ext4 would yield just about the same performance? Well then if that's the case I guess it will come down to data integrity. I am somewhat familiar with the reason for checksumming, but in reality, does btrfs' checksums or etx4 have better data integrity? Is btrfs as capable of a power failure as ext3/4 is with journalling? I did already have ext4 fail me a few months ago and destroyed all data on my 1TB drive. I had backups, luckily though |
I think I already highlighted the reasons for me to use btrfs:
| Quote: | | You wanna use btrfs for its internal RAID management, efficient small file handling (750MB portage dir on ext4 vs 280MB portage dir on btrfs), data checksumming (biggest PLUS because bigger drives mean more chance of hardware errors) and compression related gains (my / size went from 13GB to 7GB). |
Data checksum is a standout feature for me.
I am using it for my "/" in RAID0 across my SSD drives and its performance is same as I got from ext4 on ISW DMRAID or ext4 on softraid (the MD variety). Highlights of performance differences:
1. Sequential throughput (read/write both) is slightly lower than ext4.
2. Random throughput is about same as ext4.
3. Small file performance (reading/writing) is much better than ext4.
4. Deleting directories containing large number of small files is much better than ext4.
5. Traversing directories (like find or du) containing large number of dirs containing large number of small files is better than ext4.
6. Deleting large files is slightly faster than ext4.
7. Large files get less number of fragments compared to ext4 FS of the same size and free space e.g. 1GB file gets 3-4 fragments in BTRFS, but may get 15-20 fragments in ext4.
I have documented these on this forum/thread somewhere with real data from 'du', 'find', 'rm', 'emerge', 'dd', etc.
I am planning to do a power failure test of this FS and then, I am done. If it passes that, I am good with it. |
|
| Back to top |
|
|
BlueFusion
Guru
Joined: 08 Mar 2006
Posts: 371
|
| Posted: Mon Dec 28, 2009 10:30 pm Post subject: |
|
|
Wow that sums up just about all the questions I have. I will begin compiling the latest kernel now to test out btrfs goodies on a spare drive and expect to soon roll it out across all my drives
Thanks again!
_________________
i7-940 2.93Ghz | ASUS P6T Deluxe (v.1) | 24GB Triple Channel RAM | nVidia GTX660
4x 4TB Seagate NAS HDD (Btrfs raid5) | 2x 120GB Samsung 850 EVO SSD (Btrfs raid1) |
|
| Back to top |
|
|
devsk
Advocate
Joined: 24 Oct 2003
Posts: 2995
Location: Bay Area, CA
|
| Posted: Mon Dec 28, 2009 11:53 pm Post subject: |
|
|
| BlueFusion wrote: | Wow that sums up just about all the questions I have. I will begin compiling the latest kernel now to test out btrfs goodies on a spare drive and expect to soon roll it out across all my drives
Thanks again! |
I haven't rolled it out to all my drives yet. The best test for an FS is '/' and '/home'. I am going to let it cook for a while on '/' (and my /home is same '/') and then roll it out. |
|
| Back to top |
|
|
devsk
Advocate
Joined: 24 Oct 2003
Posts: 2995
Location: Bay Area, CA
|
| Posted: Tue Dec 29, 2009 12:12 am Post subject: |
|
|
| btw, your best bet is vanilla-sources 2.6.33-rc2. Its rock stable here! |
|
| Back to top |
|
|
kernelOfTruth
Watchman
Joined: 20 Dec 2005
Posts: 6111
Location: Vienna, Austria; Germany; hello world :)
|
|
| Back to top |
|
|
Dont Panic
Guru
Joined: 20 Jun 2007
Posts: 322
Location: SouthEast U.S.A.
|
| Posted: Tue Dec 29, 2009 4:24 pm Post subject: |
|
|
The btrfs in the stock 2.6.32.2 kernel is compatible with btrfs v0.16, but you will find several updates (some important IMHO) in the btrfs code for the 2.6.33 rc kernel.
Here's the shortlog for the history of the btrfs code in the stock 2.6.32.2 kernel from kernel.org (Note: I saw the same thing looking at Zen's git history for 2.6.32.2).:
(Edit to note that I see the 2.6.32-zen3 kernel is different thatn the Zen 2.6.32.2 kernel, and has backported the latest changes).
Linux kernel 2.6.32.2 stable fs/btrfs history
There were approximately 18 new git commits for the 2.6.33 rc kernel. The btrfs developers have followed a pattern recently of making the majority of their commits in at the same time, immediately at the start of the rc cycle for the newest kernel.
At this time, I have not noticed any efforts to backport any of their commits to prior versions. However, I have had success manually backporting their latest code to the prior kernel releases (although I have not tried the 2.6.32 kernel yet while waiting in vain for an Edward-official reiser4 patch).
Btrfs is a fast moving target right now, and they still seem to be in a phase of continuous improvement. This makes it a hard choice to use for anything but a testing environment. |
|
| Back to top |
|
|
dufeu
l33t
Joined: 30 Aug 2002
Posts: 924
Location: US-FL-EST
|
| Posted: Tue Dec 29, 2009 8:57 pm Post subject: |
|
|
| devsk wrote: | | btw, your best bet is vanilla-sources 2.6.33-rc2. Its rock stable here! |
I've been following the discussion with intense interest but have not yet brought up a btrfs partition yet. I do have partitions which are chock full of small files so I'm serious about the intense interest.
I have two problems with trying out btrfs at the present time and neither "problem child" has anything to do with btrfs.
The first one is "vmware-workstation". This is a requirement for me which means I need confirmation that it will work on latest kernel.
The second problem child is "ati-drivers". Yeah. I know. But I'm running a new board with a newer GPU chip.
As soon has I'm happy that everything I need will work under the new kernels, I fully intend to migrate to btrfs. For now, I'm sitting on the sidelines.
_________________
People whom think M$ is mediocre, don't know the half of it. |
|
| Back to top |
|
|
devsk
Advocate
Joined: 24 Oct 2003
Posts: 2995
Location: Bay Area, CA
|
| Posted: Tue Dec 29, 2009 9:58 pm Post subject: |
|
|
| dufeu wrote: | | devsk wrote: | | btw, your best bet is vanilla-sources 2.6.33-rc2. Its rock stable here! |
I've been following the discussion with intense interest but have not yet brought up a btrfs partition yet. I do have partitions which are chock full of small files so I'm serious about the intense interest.
I have two problems with trying out btrfs at the present time and neither "problem child" has anything to do with btrfs.
The first one is "vmware-workstation". This is a requirement for me which means I need confirmation that it will work on latest kernel.
The second problem child is "ati-drivers". Yeah. I know. But I'm running a new board with a newer GPU chip.
As soon has I'm happy that everything I need will work under the new kernels, I fully intend to migrate to btrfs. For now, I'm sitting on the sidelines. |
That's a real problem! I moved to VirtualBox (with 3.1.0, the feature set is close or even better in some sense) just because I couldn't really compile vmware modules anymore. I know it will eventually get fixed but its a recurring problem. Somehow, VB folks have figured out how not to break their modules between kernel revisions. Vmware goes deep into kernel voodooland...
As for ati drivers, you are out of luck. You can only wait!
Its strange that such things are hindering the adoption and testing of a beautiful FS. |
|
| Back to top |
|
|
kernelOfTruth
Watchman
Joined: 20 Dec 2005
Posts: 6111
Location: Vienna, Austria; Germany; hello world :)
|
| Posted: Tue Dec 29, 2009 11:56 pm Post subject: |
|
|
| Dont Panic wrote: | The btrfs in the stock 2.6.32.2 kernel is compatible with btrfs v0.16, but you will find several updates (some important IMHO) in the btrfs code for the 2.6.33 rc kernel.
Here's the shortlog for the history of the btrfs code in the stock 2.6.32.2 kernel from kernel.org (Note: I saw the same thing looking at Zen's git history for 2.6.32.2).:
(Edit to note that I see the 2.6.32-zen3 kernel is different thatn the Zen 2.6.32.2 kernel, and has backported the latest changes).
Linux kernel 2.6.32.2 stable fs/btrfs history
There were approximately 18 new git commits for the 2.6.33 rc kernel. The btrfs developers have followed a pattern recently of making the majority of their commits in at the same time, immediately at the start of the rc cycle for the newest kernel.
At this time, I have not noticed any efforts to backport any of their commits to prior versions. However, I have had success manually backporting their latest code to the prior kernel releases (although I have not tried the 2.6.32 kernel yet while waiting in vain for an Edward-official reiser4 patch).
Btrfs is a fast moving target right now, and they still seem to be in a phase of continuous improvement. This makes it a hard choice to use for anything but a testing environment. |
thank you very much, Dont Panic !
seems like I'd be using btrfs now instead of reiser4 on several partitions 
(I know it's not finished yet - so it'll be not so critical partitions)
_________________
https://github.com/kernelOfTruth/ZFS-for-SystemRescueCD/tree/ZFS-for-SysRescCD-4.9.0
https://github.com/kernelOfTruth/pulseaudio-equalizer-ladspa
Hardcore Gentoo Linux user since 2004  |
|
| Back to top |
|
|
ToeiRei
Veteran
Joined: 03 Jan 2005
Posts: 1191
Location: Austria
|
| Posted: Wed Dec 30, 2009 7:27 am Post subject: |
|
|
| kernelOfTruth wrote: | | (I know it's not finished yet - so it'll be not so critical partitions) |
/usr/portage or /var/tmp/portage are always nice test candidates because it doesn't matter if you loose things there. Personally I prefer those directories as testfields as they are actually used...
_________________
Please stand by - The mailer daemon is busy burning your messages in hell... |
|
| Back to top |
|
|
devsk
Advocate
Joined: 24 Oct 2003
Posts: 2995
Location: Bay Area, CA
|
| Posted: Wed Dec 30, 2009 7:57 am Post subject: |
|
|
| ToeiRei wrote: | | kernelOfTruth wrote: | | (I know it's not finished yet - so it'll be not so critical partitions) |
/usr/portage or /var/tmp/portage are always nice test candidates because it doesn't matter if you loose things there. Personally I prefer those directories as testfields as they are actually used... |
Particularly, /usr/portage is nice because it will test the small file capability of the FS very well! And then, its effect is cleanly measurable by timing 'emerge', 'du', 'find' etc. |
|
| Back to top |
|
|
kernelOfTruth
Watchman
Joined: 20 Dec 2005
Posts: 6111
Location: Vienna, Austria; Germany; hello world :)
|
| Posted: Wed Dec 30, 2009 4:01 pm Post subject: |
|
|
| ToeiRei wrote: | | kernelOfTruth wrote: | | (I know it's not finished yet - so it'll be not so critical partitions) |
/usr/portage or /var/tmp/portage are always nice test candidates because it doesn't matter if you loose things there. Personally I prefer those directories as testfields as they are actually used... |
actually I'm going so far to put all my data on it as an additional "backup"-partition (of minor importance) just to see how well it does
in the wiki it says:
| Quote: | | Space efficient packing of small files |
isn't that another word for "tail-packing" ?
I've also read that it stores small files directly in the leaves of a tree so another commonality it shares with reiser*-filesystems (advantages of extents without the disadvantages of extents for small files)
thanks
| devsk wrote: | | ToeiRei wrote: |
/usr/portage or /var/tmp/portage are always nice test candidates because it doesn't matter if you loose things there. Personally I prefer those directories as testfields as they are actually used... |
Particularly, /usr/portage is nice because it will test the small file capability of the FS very well! And then, its effect is cleanly measurable by timing 'emerge', 'du', 'find' etc. |
definitely ! it's comparable to reiser4 when looking at performance and other factors ...
from its behavior:
* performance-wise it seems to be among reiser4, ext4, reiserfs - so very fast
* space-efficiency related it seems to be comparable to reiser4 with lzo-compression or somewhat better than reiserfs
* data-safety wise - I can't say anything yet (but it should be pretty good unless there are still some severe hidden bugs lying underneath)
does anyone know what hash concept btrfs relies on ? how high is the probability of hash collisions ?
I've recently switched from r5-hash (modified rupasov) in reiserfs to tea-hash just to be sure that all my data is intact since I'm having several identical filenames, highly nested folder structures and probably also some identical files
is filesystem-compression enabled by default now ? I read it somewhere therefore I haven't mounted it with the compression command now - if not I need to reformat, mount it with the -o compress option 
thanks
_________________
https://github.com/kernelOfTruth/ZFS-for-SystemRescueCD/tree/ZFS-for-SysRescCD-4.9.0
https://github.com/kernelOfTruth/pulseaudio-equalizer-ladspa
Hardcore Gentoo Linux user since 2004 |
|
| Back to top |
|
|
Dont Panic
Guru
Joined: 20 Jun 2007
Posts: 322
Location: SouthEast U.S.A.
|
| Posted: Wed Dec 30, 2009 5:12 pm Post subject: |
|
|
| kernelOfTruth wrote: |
is filesystem-compression enabled by default now ? I read it somewhere therefore I haven't mounted it with the compression command now - if not I need to reformat, mount it with the -o compress option |
I've been following this project fairly closely, and I can't recall seeing anywhere that compression would be the default option.
I'd be surprised if it was, and I'm pretty sure it would have sparked a visible, spirited discussion on the Mailing List. I think the majority of their target users would value speed over space utilization.
Personally, I'm glad they've provided a compression option. But it doesn't seem to be a high profile feature to the developers. |
|
| Back to top |
|
|
kernelOfTruth
Watchman
Joined: 20 Dec 2005
Posts: 6111
Location: Vienna, Austria; Germany; hello world :)
|
| Posted: Wed Dec 30, 2009 5:20 pm Post subject: |
|
|
| Dont Panic wrote: | | kernelOfTruth wrote: |
is filesystem-compression enabled by default now ? I read it somewhere therefore I haven't mounted it with the compression command now - if not I need to reformat, mount it with the -o compress option |
I've been following this project fairly closely, and I can't recall seeing anywhere that compression would be the default option.
I'd be surprised if it was, and I'm pretty sure it would have sparked a visible, spirited discussion on the Mailing List. I think the majority of their target users would value speed over space utilization.
Personally, I'm glad they've provided a compression option. But it doesn't seem to be a high profile feature to the developers. |
you're right - so I should rely on the "official" sources of information
I just found out that it must NOT be enabled at default because of the following results:
/dev/mapper/portage 4.0G 1.2G 2.8G 31% /usr/gentoo (no compress mount-option)
/dev/mapper/portage 4.0G 1021M 3.0G 26% /usr/gentoo (with compress mount-option)
it also said in dmesg-output:
| Quote: | | [12822.700181] btrfs: use compression |
I don't know if it's only a subjective observation but with compression btrfs "feels" (even) faster during syncing of the portage-tree
seems like I need to reformat my data-partition 
_________________
https://github.com/kernelOfTruth/ZFS-for-SystemRescueCD/tree/ZFS-for-SysRescCD-4.9.0
https://github.com/kernelOfTruth/pulseaudio-equalizer-ladspa
Hardcore Gentoo Linux user since 2004 |
|
| Back to top |
|
|
regomodo
Guru
Joined: 25 Mar 2008
Posts: 445
|
| Posted: Wed Dec 30, 2009 5:42 pm Post subject: |
|
|
[quote="kernelOfTruth"] | Dont Panic wrote: |
I just found out that it must NOT be enabled at default because of the following results:
/dev/mapper/portage 4.0G 1.2G 2.8G 31% /usr/gentoo (no compress mount-option)
/dev/mapper/portage 4.0G 1021M 3.0G 26% /usr/gentoo (with compress mount-option)
|
Are your subvolumes shown via /dev/mapper? |
|
| Back to top |
|
|
kernelOfTruth
Watchman
Joined: 20 Dec 2005
Posts: 6111
Location: Vienna, Austria; Germany; hello world :)
|
|
| Back to top |
|
|
devsk
Advocate
Joined: 24 Oct 2003
Posts: 2995
Location: Bay Area, CA
|
| Posted: Wed Dec 30, 2009 5:52 pm Post subject: |
|
|
| Dont Panic wrote: |
I'd be surprised if it was, and I'm pretty sure it would have sparked a visible, spirited discussion on the Mailing List. I think the majority of their target users would value speed over space utilization.
|
actually, compression is faster AND space efficient. Compression saves on number of IOs you have to do to get the actual data. Try compressing a 500MB text file down to 50MB with gzip and load it in VIM. AND then, try loading the uncompressed text file in VIM. IO is still the bottleneck of modern systems. CPU is not. So, compression is ideal for modern systems where you have really fast CPUs and lot of CPU cycles freely available, but not as much IO bandwidth. If you have a fast SSD, where the IO bandwidth as well as the latency is small, this may not be as beneficial but still better than non-compression. |
|
| Back to top |
|
|
devsk
Advocate
Joined: 24 Oct 2003
Posts: 2995
Location: Bay Area, CA
|
| Posted: Wed Dec 30, 2009 6:17 pm Post subject: |
|
|
| BTW, if you have SSD, you wanna reduce the erase cycles on it because you can only erase a cell 10000 times for MLS and 100000 for SLC. Compression can essentially reduce the number of actual IOs to the device by an order of magnitude. So, compression again is ideal for SSDs. |
|
| Back to top |
|
|
regomodo
Guru
Joined: 25 Mar 2008
Posts: 445
|
| Posted: Thu Dec 31, 2009 11:22 am Post subject: |
|
|
@devsk
Did you ever solve the bootup and Btrfs issue? I've tried 2.6.32 and 2.6.33-rc2 and still get the same issue.
I don't get errors when I do it manually but /etc/fstab always requires me alternating between /dev/sda /dev/sdb for the block device. |
|
| Back to top |
|
|
devsk
Advocate
Joined: 24 Oct 2003
Posts: 2995
Location: Bay Area, CA
|
| Posted: Thu Dec 31, 2009 5:02 pm Post subject: |
|
|
| regomodo wrote: | @devsk
Did you ever solve the bootup and Btrfs issue? I've tried 2.6.32 and 2.6.33-rc2 and still get the same issue.
I don't get errors when I do it manually but /etc/fstab always requires me alternating between /dev/sda /dev/sdb for the block device. |
No, still facing the same issue myself. I think we need to report it upstream. |
|
| Back to top |
|
|
|
Gentoo Chat
