Announcement

Collapse
No announcement yet.

Btrfs On Ubuntu Is Running Well

Collapse
X
  • Filter
  • Time
  • Show
Clear All
new posts

  • Btrfs On Ubuntu Is Running Well

    Phoronix: Btrfs On Ubuntu Is Running Well

    For those curious about first-hand stories of using Btrfs in a production environment, Alan Pope of Canonical has written about his positive experiences in running Btrfs on a production server for more than the past year...

    http://www.phoronix.com/vr.php?view=MTQ1MTU

  • #2
    Happily using BTRFS for more than the last year

    Comment


    • #3
      with most recent patches on the ML it now has become the fastest filesystem on linux I have used so far

      seems like they're really speeding up development pace - hopefully integrity-wise they also keep on improving at that pace - will be the best then

      Comment


      • #4
        We've been running btrfs on all our systems for about 14 months now. Single drive, btrfs raid0, and btrfs raid1. We haven't lost a file. I trust btrfs more than ext4 at this point. Do run the latest upstream kernel and btrfs-progs if you are going to use it, to stay ahead of any issues.

        Comment


        • #5
          Originally posted by kernelOfTruth View Post
          with most recent patches on the ML it now has become the fastest filesystem on linux I have used so far
          Benchmarks? (and/or links to specific patches?) ... I ask because that is a bold statement to make (fastest filesystem) without some sort of data to support what you are saying. I'm not saying it isn't possible, but the last time that i checked Btrfs still was pretty slow in a lot of workloads and when i used it in January in one machine -> i was less than impressed by it's 'speed' and certainly not faster than ext4, at that time. (ie: i ditched btrfs in favor of ext4). Then, of course i have seen more recent benchmarks comparing ext4 to btrfs (even a few days ago on Phoronix) and i didn't get the impresion that all of a sudden; btrfs is the fastest filesystem...

          * but don't get me wrong, i would love to see btrfs replace ext4, if/when it's ready to be the (my?) default filesystem, over ext4.

          cheerz

          Comment


          • #6
            I hope Btrfs will pick up some speed soon, and get all planned features stable. We need it, the filesystem is one of Linux's weak spots. The BSD-guys are laughing at us.

            Comment


            • #7
              Originally posted by ninez View Post
              Benchmarks? (and/or links to specific patches?) ... I ask because that is a bold statement to make (fastest filesystem) without some sort of data to support what you are saying. I'm not saying it isn't possible, but the last time that i checked Btrfs still was pretty slow in a lot of workloads and when i used it in January in one machine -> i was less than impressed by it's 'speed' and certainly not faster than ext4, at that time. (ie: i ditched btrfs in favor of ext4). Then, of course i have seen more recent benchmarks comparing ext4 to btrfs (even a few days ago on Phoronix) and i didn't get the impresion that all of a sudden; btrfs is the fastest filesystem...

              * but don't get me wrong, i would love to see btrfs replace ext4, if/when it's ready to be the (my?) default filesystem, over ext4.

              cheerz
              in this case I don't care about benchmarks

              it's a speedup during every usage:

              e.g. browsing folders with lots of files (all different kinds of files) via nemo/nautilus - it's almost suddenly there whereas before it took several seconds to load,

              launching & using virtual machines (virtualbox), launching apps, etc. etc.


              take all of this with a grain of salt (say: it's not only due to btrfs) since I added lots of other patches to cut down latency as low as possible (BFS, adaptive CFQ low-latency behavior, (v2) mm: improve page aging fairness between zones_nodes , and others)

              kernel base is 3.10 - so it's basically a 3.10 custom fork

              Comment


              • #8
                Originally posted by kernelOfTruth View Post
                in this case I don't care about benchmarks

                it's a speedup during every usage:

                e.g. browsing folders with lots of files (all different kinds of files) via nemo/nautilus - it's almost suddenly there whereas before it took several seconds to load,

                launching & using virtual machines (virtualbox), launching apps, etc. etc.
                Ah, okay. I wasn't bugging you for benchmarks out of disbelief or anything, i just (personally) like seeing hard numbers too, when possible...

                Originally posted by kernelOfTruth View Post
                take all of this with a grain of salt (say: it's not only due to btrfs) since I added lots of other patches to cut down latency as low as possible (BFS, adaptive CFQ low-latency behavior, (v2) mm: improve page aging fairness between zones_nodes , and others)

                kernel base is 3.10 - so it's basically a 3.10 custom fork
                do you care to pass on any of these patches? (excluding BFS - since i use a custom build of linux-rt, which is incompatible / i need CFS). I'm always looking for new patches to add to my queue and/or to test/experiment with... the mm paging stuff may be of interest and I'm curious about these "others". (you could just pastebin them?)...

                thx

                Comment


                • #9
                  I don't see any key advantega of btrfs over ext4 that would make me switch now.

                  And it is not clear how can it scale better than existing mdraid+lvm solutions.

                  I run my RAID-5/6 arrays for quite some time without much trouble. During that time i restripped and expanded them a few times, without bad consequnces.

                  Yes, md can be a bitch, but that just means one has to get to know it intimately so he can avoid its "problematic" sides.

                  One generally wants to know how data is being stored and how much redundancy there is and how is it paid for.

                  With RAID-5 i know that i have one equivalent of one drive for checksums. So I can lose one up to one drive. With current striping and CPU+ board combo I use, I have 200+MB/s linear read performance, which is more than enough for a server I accese through GiG-e. With new HW ( kaveri-based) this will jump dramatically.

                  I also know that I have to pay some time of reduced performace when restriping and/or growing. In return, I have high bandwidth of all drives available for all data. For me, RAID-1 or RAID-10 is simply not enough.

                  OTOH, embeded crypto or signature check would really come handy, so one wouldn't have to encrypt whole partition. Alas, Btrfs doesn't offer that.

                  Comment


                  • #10
                    Originally posted by Brane215 View Post
                    I don't see any key advantega of btrfs over ext4 that would make me switch now.
                    Compression, snapshots.

                    Comment


                    • #11
                      Originally posted by Brane215 View Post

                      OTOH, embeded crypto or signature check would really come handy, so one wouldn't have to encrypt whole partition. Alas, Btrfs doesn't offer that.
                      filesystem level encryption is a planned feature for Btrfs.

                      Comment


                      • #12
                        Originally posted by pankkake View Post
                        Compression, snapshots.
                        Compression is not that crucial for me. If I want something compressed, I can do it myself and I don't need to push de/compression into fs infrastructure. And I get to decide what algorithm and how much effort I want to put in it.

                        Snapshots sound much better than they really are, at least for me.

                        FS knows nothing about integrity of structures and their relationship on higher levels.

                        So, for example, if I do a snapshot in the moment when some user was ftp-ing data into some file, snapshot will contain incomplete and most probably corrupted copy.

                        Same with databases etc. So, for useful snapshot I have to control and stop higher level operations on some useful boundary.

                        When I do that, I get to the point when I can achieve the same functionality with simple ( possibly incremental) copy onto backup storage.

                        Comment


                        • #13
                          Originally posted by kernelOfTruth View Post
                          take all of this with a grain of salt (say: it's not only due to btrfs) since I added lots of other patches to cut down latency as low as possible (BFS, adaptive CFQ low-latency behavior, (v2) mm: improve page aging fairness between zones_nodes , and others)
                          I found the above mm subsystem patchset... but i would still like to know about the "others" - if possible....

                          Comment


                          • #14
                            Originally posted by ninez View Post
                            I found the above mm subsystem patchset... but i would still like to know about the "others" - if possible....
                            http://pastebin.com/S8bP5k8Q (kernel-38-gcc47-1.patch)
                            • [PATCH 0/6] ipc_sem.c: performance improvements, FIFO
                            http://pastebin.com/FA71Db2F [PATCH 1/2] ocfs2: Fix llseek() semantics and do some cleanup
                            http://pastebin.com/0P3ZRjAF [PATCH 2/2] btrfs: Cleanup llseek()
                            http://pastebin.com/5jnbjz20 [PATCH] mutex: do not unnecessarily deal with waiters
                            http://pastebin.com/z7pXWPH4 [RFC PATCH] cfq-iosched: limit slice_idle when many busy queues are in idle window
                            http://pastebin.com/114sn4Lw [PATCH] mm, slab_common: add 'unlikely' to size check of kmalloc_slab()
                            http://pastebin.com/Mu1VSqkd [PATCH v2] tile: optimize strnlen using SIMD instructions
                            http://www.spinics.net/lists/linux-mm/msg61386.html [PATCH v6 0/5] zram/zsmalloc promotion <-- using that zram patchset since that one works best & most stable so far
                            • Fix TLB gather virtual address range invalidation corner cases
                            • [PATCH] mm: Fix the TLB range flushed when __tlb_remove_page() runs out of slots
                            http://pastebin.com/Jyf0iz69 [WIP] rcu: Throttle rcu_try_advance_all_cbs() execution
                            http://pastebin.com/eUcHC5qC [PATCH] writeback: Do not sort b_io list only because of block device inode
                            http://pastebin.com/SGBKVmBQ sync: don't block the flusher thread waiting on IO
                            http://pastebin.com/e9DY20d0 readahead-make-context-readahead-more-conservative.patch


                            reached pastebin limit ^^

                            - [PATCH] mm: compaction: Do not compact pgdat for order-0
                            - [PATCH] fs/buffer.c: use lowmem_page_address instead of page_address
                            - [PATCH] mm: fix special swap entry handling on copy mm
                            - [PATCH] Make sure to wake reaper
                            - [PATCH] Avoid useless inodes and dentries reclamation
                            - [PATCH] workqueue: cond_resched() after processing each work item
                            - [patch] block: fix race between request completion and timeout handling
                            - [PATCH v3] mm: remove compressed copy from zram in-memory


                            kernel base is 3.10
                            haven't bothered to update much of 3.10 so far ...

                            ok, so that should be the biggest portion of the used patches

                            don't forget to use BFS since that plays a rather big role in cutting down latency and improving responsiveness

                            Comment


                            • #15
                              Originally posted by kernelOfTruth View Post


                              <...snip...>

                              kernel base is 3.10
                              haven't bothered to update much of 3.10 so far ...

                              ok, so that should be the biggest portion of the used patches

                              don't forget to use BFS since that plays a rather big role in cutting down latency and improving responsiveness
                              Okay, i will have a look through them. But right away, things i can point out; I use a newer version of the gcc kernel patch, yours is outdated; "kernel-310-gcc48-2.patch" is the current iteration. I also have the option of using Zen's xFLAGS patch, in there too. SLAB is 100% useless to me & N/A on -rt kernels, so that's of no interest... The rest of the patches i'm going to have to look at more, closely... although, obviously some stuff 'pops out' at me as possibly being useful, over others. (so thanks, a little investigating for the evening!).

                              Also, as i said - I use *linux-rt* - BFS is NOT applicable, nor even desired (i don't need BFS for low-latency, in the slightest).... BFS is good (don't get me wrong), but PREEMPT_RT_FULL gives a more deterministic system + the "hard-realtime" requirements that i have. -> although, i hate the terminology - standard linux only gives you 'soft-realtime'. (maybe somewhere inbetween these days, in some cases). But using a vanilla or BFS kernel does get you the main features that an -rt patchset provides to Linux. ie: https://rt.wiki.kernel.org/index.php..._patch_work.3F

                              <Note: read the "1.4 How does the CONFIG_PREEMPT_RT patch work?" section, it briefly covers a few of those important changes to Linux>

                              anyway, there still might be some useful patch(es) in there, so thanks again!

                              cheerz
                              Last edited by ninez; 09-02-2013, 07:47 PM.

                              Comment

                              Working...
                              X