Page 2 of 5 FirstFirst 1234 ... LastLast
Results 11 to 20 of 46

Thread: Btrfs On Ubuntu Is Running Well

  1. #11
    Join Date
    Aug 2012
    Location
    Pennsylvania, United States
    Posts
    1,748

    Default

    Quote 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.

  2. #12
    Join Date
    Jul 2012
    Posts
    110

    Default

    Quote 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.

  3. #13
    Join Date
    Jun 2011
    Posts
    809

    Default

    Quote 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....

  4. #14
    Join Date
    Jan 2009
    Location
    Vienna, Austria; Germany; hello world :)
    Posts
    607

    Default

    Quote 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

  5. #15
    Join Date
    Jun 2011
    Posts
    809

    Default

    Quote 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 at 07:47 PM.

  6. #16
    Join Date
    Nov 2010
    Posts
    100

    Default

    Quote 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.

  7. #17
    Join Date
    Jun 2011
    Posts
    809

    Default

    Quote 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)...

    Quote 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

  8. #18
    Join Date
    Jun 2011
    Posts
    809

    Default

    Quote Originally Posted by edensgy8 View Post
    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).

  9. #19
    Join Date
    Oct 2008
    Posts
    2,911

    Default

    Quote 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.

  10. #20
    Join Date
    Jun 2011
    Posts
    809

    Default

    Quote 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

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •