Announcement

Collapse
No announcement yet.

Btrfs On Ubuntu Is Running Well

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

  • #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.
    All opinions are my own not those of my employer if you know who they are.

    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; 02 September 2013, 07:47 PM.

            Comment


            • #16
              Originally posted by Ericg View Post
              filesystem level encryption is a planned feature for Btrfs.
              IRC most if not all of the btrfs developers actually shun filesystem level encryption. They don't think that's where encryption belongs.

              Comment


              • #17
                Originally posted by kernelOfTruth View Post
                http://pastebin.com/S8bP5k8Q (kernel-38-gcc47-1.patch)
                • [PATCH 0/6] ipc_sem.c: performance improvements, FIFO
                By far, the above patchset is the most applicable and best for my use cases. I googled and found the entire patchset (which is actually 7 not 6 - as there was one written after the 6 were released). I had to edit patch 6 to apply properly, but after that it compiled just fine - I haven't done any serious testing yet. But my machine seems to be running faster. (boot time was quicker, certain apps loading quicker, Ardour3 session that i played is lighter on CPU usage too)...

                Originally posted by kernelOfTruth View Post
                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()
                As soon as the rest of my parts for my embedded ITX box show up (and i get the machine running). I am going to test out btrfs again. If these patches (and possibly others haven't been merged by then_ then i will test them out too (I'm not messing around with this machine..lol). It will be interesting to see how Btrfs is shaping up. I should be able to experiment (even hose the install and not care), so that should be a good scenario for testing.

                the rest i haven't gone through (because i only test X number of patches per compilation and had a couple to test on top of the IPC/sem ones above), but again - a couple of them will probably be useful

                cheerz

                Comment


                • #18
                  Originally posted by edensgy8
                  I don't think they are designed for such often updates.



                  @Phoronix

                  This is a bot, not a user; Look at it's Profile, the join date and it's 7 comments. (all the exact same in multiple threads).

                  Comment


                  • #19
                    Originally posted by ninez View Post
                    @Phoronix

                    This is a bot, not a user; Look at it's Profile, the join date and it's 7 comments. (all the exact same in multiple threads).
                    Hit the little triangle icon to the bottom left of the post to report to the mods.

                    Comment


                    • #20
                      Originally posted by smitty3268 View Post
                      Hit the little triangle icon to the bottom left of the post to report to the mods.
                      I'm blind. thx

                      Comment

                      Working...
                      X