EXT4 Gets A Nice Batch Of Fixes For Linux 5.8

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts
  • kloczek
    Senior Member
    • Feb 2020
    • 162

    #61
    Originally posted by pal666 View Post
    as long as zfs doesn't use btrees, it can't be considered real file system
    ZFS is using special type of btrees which called AVL trees. AVL trees are so special because on update single leaf you dont need to update all branches up to root block.
    btrfs still has on its todo list switching from regular BTree to AVL. Why it it is needed? To optimise all COW operations.
    At the moment ALL COW FSess which are not using AVL are screwed by design.

    COW is VERY important because it allows convert many random write operations to sometimes single or fewer sequential write IOs. It is a bit less important today on SATA SSDs or NVMe devices but it still allows reduce number of IOs and by this number IRQs/s (interrupts per second) which in many cases is today main bottleneck after unclogging block devices using flash memory.

    Comment

    • kloczek
      Senior Member
      • Feb 2020
      • 162

      #62
      Originally posted by pal666 View Post
      if someone is forcing you, call police. you don't have to mount btrfs snapshots. zfs zealots look like flat earthers
      really? I can create btrfs snapshot without specify dest? Just made test. I have my home directory on btrfs ..
      Code:
      [root@barrel ~]# btrfs subvolume snapshot /home/tkloczko/test
      btrfs subvolume snapshot: exactly 2 arguments expected, 1 given
      ops .. seems like you are wrong.

      Comment

      • Almindor
        Senior Member
        • Jul 2008
        • 480

        #63
        Originally posted by pal666 View Post
        there's no kernel drama for btrfs, no need to punish yourself with snapshotless life
        In all honest there were very few cases where snapshots would've helped me so far, including for the servers I ran. Overall I've had good luck with disks.

        Comment

        • Almindor
          Senior Member
          • Jul 2008
          • 480

          #64
          Originally posted by kreijack View Post

          For a non esoteric setup BTRFS is quite stable (I used it from ~2009) . The worst thing that could happen is low performance for some workload. I.e. doing an "apt update" on a BTRFS filesystem stored in an HDD is slow.

          However there are some workaround that could increase the performance.
          I don't think I need the functionality, as I mentioned in another reply, I had good luck with disks before. Anything critical I keep syncthing-ed accross my machines (it's mostly documents etc.) and for big stuff I have 1 more copy over on a remote drive. If something happened to my home sure a snapshot would be nice, but not worth re-doing things now or for the price of performance issues.

          Comment

          • DanL
            Senior Member
            • Oct 2007
            • 3126

            #65
            Originally posted by pal666 View Post
            if you have performance issues with btrfs, you are doing it wrong
            You're the one who's doing it wrong (making 20 posts in a row to tell everyone else they're wrong as you usually do).
            You also seem to struggle with reading comprehension: https://www.phoronix.com/scan.php?pa...esystems&num=1

            Comment

            • Old Grouch
              Senior Member
              • Apr 2020
              • 696

              #66
              Originally posted by kloczek View Post

              I have no idea what it is NILLFS however if that FS still is using allocation structures and not like ZFS free lists still it will not be able to beat ZFS on any snapshots operations.
              You can partially remedy your ignorance by reading the Wikipedia article on NILFS. Spinning up a loop-fs on a file and formatting it as nilfs2 will give you something to play with and learn by doing. I make no claim for it being better than btrfs, zfs, or even lvm snapshots, merely another option that might be interesting or serve a use-case for you. It happens to suit my current purposes.
              I am intrigued by how you argue from ignorance that NILFS cannot beat ZFS on any snapshot operations. That's a strong statement, and I would be grateful if you could provide links to resources where that is documented or demonstrated.

              Comment

              • kloczek
                Senior Member
                • Feb 2020
                • 162

                #67
                Originally posted by Old Grouch View Post

                You can partially remedy your ignorance by reading the Wikipedia article on NILFS. Spinning up a loop-fs on a file and formatting it as nilfs2 will give you something to play with and learn by doing. I make no claim for it being better than btrfs, zfs, or even lvm snapshots, merely another option that might be interesting or serve a use-case for you. It happens to suit my current purposes.
                I am intrigued by how you argue from ignorance that NILFS cannot beat ZFS on any snapshot operations. That's a strong statement, and I would be grateful if you could provide links to resources where that is documented or demonstrated.
                After short lecture I see that this FS main focus is to have transnational file system.
                Just to let you know: ZFS is fully transnational FS and snapshot it is nothing more than transaction number + volume directories root block.
                For example if for some reason system with ZFS will crash and some data or metadata of the last transaction will be inconsistent it is possible to import zpool in state of the translation -1, -2 and soo on.
                NILFS is not using free list so this is still classic FS.
                In other words NILFS still is +15 years behind of ZFS.
                Every FS which is not using free list and uses allocation structures is by definition slower, less saleable than ZFS .. BY DESIGN.
                Using allocation structures to describe what is allocated on raw device space will always require more physical IOs than solution which will be using free list (whatever is not on free list is already allocated). If you don;t believe in that try to think that using free lists on memory management RAM management it is what makes this fastest possible.
                At the moment biggest bottleneck is not bandwidth to the the block device or number of IOs/s but number of interrupts/s of the motherboard.

                On top of that looks like not to many people is using it so using it on production is more risky than ext or xfs.
                So .. again: thank you but NILFS is not even close to what ZFS provided 15 years ago.

                And to let you know. ZFS does not need LVM. It is as well hierahical storage management which can use two layers of caching and can combine slow and fast storage to provide cheap storage AND fastest possible acces.
                ZFS caching consist from: in memory ARC (Adaptive Reclain Chache) and L2ARC (Level 2 ARC) which can cache FRU/MRU (Most Recently/Frequently Used) data on fast storage like NVMe. With that you can have petabytes data pool organised on top of cheap spindles and MRU/MFU data cahed in ZIL vdev (ZFS Intent Log).
                ARC and L2ARC can keep compressed data so with that physical memory works like the same memory multiplied by all used blocks compression ration.

                ZFS is waaaay more than FS and block devices management which can experience on any Linux FS and still code of the ZFS is even smaller than any FS + LVM/MD.
                All because ZFS is not generic FS which is using generic block layer. On combining those two layers together was possible to redesign many things to make actual binary and source code smaller than any classic FS+VM.

                Comment

                • S.Pam
                  Senior Member
                  • Oct 2018
                  • 687

                  #68
                  kloczek why are you so angry?

                  Just from my personal experience, I've had some use-cases that btrfs helped me solve:

                  Shrinking a pool to remove a disk
                  converting from raid to single
                  Adding new disks
                  Converting between raid levels
                  Exporting snapshots as shadow copies to Windows clients

                  Some of these cases I believe would not have been possible with ZFS. Perhaps that's changed recently?

                  Also, why is it inherently bad to have the possibility to choose exactly where you want to store your snapshots? You can choose to put them in a .dot folder too if that's what you want.

                  Lastly, the ZOL license is not compatible with GPL. This is a fact and a blocker for inclusion in the Linux kernel.
                  Last edited by S.Pam; 07 June 2020, 12:33 AM.

                  Comment

                  • Volta
                    Senior Member
                    • Apr 2019
                    • 2284

                    #69
                    zfs is bloated crap. It will die in near future.

                    Comment

                    • Volta
                      Senior Member
                      • Apr 2019
                      • 2284

                      #70
                      Originally posted by kloczek View Post

                      Yep .. and this is why today Linux needs today desperately needs ZSF because NONE of the Linux solutions can provide what ZFS has provided in his first official Solaris version.
                      You made my day dude
                      And slowlaris is dead, so your point is flawed. The same about your reasoning. Do you see FreeBSD ZFS somewhere in enterprise?

                      If you will go back to the time when Solaris 10 was released you will find that before making whole Solaris code open sourced under CDDL license first two chunks published Solaris code was DTrace and ZFS. Sun gave chance to copy/mimic ZFS in own implementation. *BSD took that code and within ~year they had first implementation integrated in FreeBSD. Linux choose its normal NIH syndrome way (NIH -> Not Invented Here) and eveb today bpftrace still is not Linux DTrace and btrfs because under neath is not using free list still is not able to provide 20-20% of the ZFS initial version functionalities.
                      Linux tracing tools easily beat dtrace today (what's more funny neither dtrace nor zfs saved slowlaris, so it seems it was more about marketing than real use cases; or it failed in other areas) Furthermore, you're either dumb or trolling, because you can't mainline cddl code with GPL licensed kernel. Furthermore, like mentioned before neither zfs nor dtrace helped slowlaris to stay alive, so it seems Linux kernel developers didn't want to waste their time on porting such features.
                      Last edited by Volta; 07 June 2020, 02:35 AM.

                      Comment

                      Working...
                      X