Announcement

Collapse
No announcement yet.

DM VDO "Virtual Data Optimizer" Merged For Linux 6.9

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

  • #11
    Originally posted by skeevy420 View Post
    I've never been a fan of using DM for one thing, LVM for another, and different file systems for other things when ZFS can do all of that in one package with a hell of a lot more flexibility.
    That's actually Device-Mapper's biggest strength; you can use whatever implementations you want in whatever combination and order you want, with the end result actually being far more flexible and configurable than ZFS. For example, you can use MDADM or DM-RAID (or something else) to drive your RAID; you can use DM-Cache or BCache (or something else) to drive your tiered storage; you can use BTRFS or XFS (or something else) to drive your FS. If one component doesn't have the features you want you can switch it out without affecting any of the other components.

    The custom ordering is also really powerful. For example, you can put DM-Crypt over DM-Integrity for Encrypt-Then-MAC authentication or put DM-Integrity over DM_Crypt for MAC-Then-Encrypt authentication; you can put DM-Integrity over DM-RAID for simple corruption detection or put DM-RAID over DM-Integrity for self-healing corruption detection. I currently have BTRFS over DM-Crypt over BCache over DM-RAID.

    Originally posted by skeevy420 View Post
    Does anyone know how this handles double compression? The times when this will be doing LZ4 and then BTRFS will do Zstd-3. It knows not to do compression twice, right? Will it use LZ4 like OpenZFS uses it for early abort in those cases?


    IIUC the compression and deduplication are transparent to the layers above it; the block device corresponding to a VDO volume just looks like any other block device. It's similar to how DM-Crypt and DM-Cache layers work. Unless BTRFS is checking the block device types, it would have no idea that additional deduplication or compression were happening. So definitely disable compression in BTRFS in that case.

    Comment


    • #12
      Originally posted by byteabit View Post
      How would this even work?
      Through the magic of ✨abstraction✨.

      Comment


      • #13
        I love pooling my drives with dm-stripped, then dm-mirror, then dm-crypt, then dm-integrity, then dm-vdo, then dm-snapshot, then LVM, then XFS.

        Comment


        • #14
          Originally posted by byteabit View Post
          That's neat. If you say its filesystem independent, do you mean its independent if its EXT4 or ZFS or any other filesystem?? How would this even work?
          Same way you can image a disk and then mount it. The filesystem driver sees a file beneath it, and Device Mapper is effectively a wrapper around a file like /dev/sda which transparently unpacks or whatever when you request to read, and transparently packs or whatever when you ask to write.

          Comment


          • #15
            Originally posted by espi View Post
            I love pooling my drives with dm-stripped, then dm-mirror, then dm-crypt, then dm-integrity, then dm-vdo, then dm-snapshot, then LVM, then XFS.
            That's like saying "I love installing Linux, then BTRFS, then SystemD, then Mesa, then Xorg, then Kwin, then SDDM". Just like installing a distro automatically configures those things for you, there are plenty of tools to manage the intermediate storage layers for you. If you want an experience like ZFS just use Stratis and LVM.

            Comment


            • #16
              Originally posted by EphemeralEft View Post

              That's like saying "I love installing Linux, then BTRFS, then SystemD, then Mesa, then Xorg, then Kwin, then SDDM". Just like installing a distro automatically configures those things for you, there are plenty of tools to manage the intermediate storage layers for you. If you want an experience like ZFS just use Stratis and LVM.
              AFAIK Stratis has never even incorporated the verity layer. It was an interesting idea that RH seems to have half assed for half a decade.

              Comment


              • #17
                Not that cool as it seems:

                1) can you run LUKS+VDO without LVM? i guess no
                2) does grub supports VDO? i guess no
                3) how does compression works with deduplication if block one of 16 blocks already inside compressed 1 block will it be decompressed to be deduplicated?
                4) compression btrfs compression vs vdo compression (deduplication)?

                Since here is too many questions it would be really hard to make an optimal solution/choice (FS+VDO)

                Comment


                • #18
                  Originally posted by EphemeralEft View Post

                  That's like saying "I love installing Linux, then BTRFS, then SystemD, then Mesa, then Xorg, then Kwin, then SDDM". Just like installing a distro automatically configures those things for you, there are plenty of tools to manage the intermediate storage layers for you. If you want an experience like ZFS just use Stratis and LVM.
                  Can you share what good tools exist for managing the soup of potential layers besides Stratis (which AFAIK doesn't actually support a bunch of them)?

                  Comment


                  • #19
                    Originally posted by ATLief View Post

                    That's actually Device-Mapper's biggest strength; you can use whatever implementations you want in whatever combination and order you want, with the end result actually being far more flexible and configurable than ZFS. For example, you can use MDADM or DM-RAID (or something else) to drive your RAID; you can use DM-Cache or BCache (or something else) to drive your tiered storage; you can use BTRFS or XFS (or something else) to drive your FS. If one component doesn't have the features you want you can switch it out without affecting any of the other components.

                    The custom ordering is also really powerful. For example, you can put DM-Crypt over DM-Integrity for Encrypt-Then-MAC authentication or put DM-Integrity over DM_Crypt for MAC-Then-Encrypt authentication; you can put DM-Integrity over DM-RAID for simple corruption detection or put DM-RAID over DM-Integrity for self-healing corruption detection. I currently have BTRFS over DM-Crypt over BCache over DM-RAID.



                    IIUC the compression and deduplication are transparent to the layers above it; the block device corresponding to a VDO volume just looks like any other block device. It's similar to how DM-Crypt and DM-Cache layers work. Unless BTRFS is checking the block device types, it would have no idea that additional deduplication or compression were happening. So definitely disable compression in BTRFS in that case.
                    I think it would be cool if the folks in the threads using all of these layers would share their setups. I've seen several posts online where people didn't even have the layers in the right order to achieve what they were hoping for. So some known good setups might be helpful to others.

                    Comment


                    • #20
                      Originally posted by pWe00Iri3e7Z9lHOX2Qx View Post

                      I think it would be cool if the folks in the threads using all of these layers would share their setups. I've seen several posts online where people didn't even have the layers in the right order to achieve what they were hoping for. So some known good setups might be helpful to others.
                      I've thought about making a guide like that a few times, but the "right" order or combination entirely depends on the situation. Even things that are almost always a mistake (like putting DM-Cache above DM-Crypt) have situations where they make sense. Projects like ZFS and Stratis have to make the same choices, but they do it by (presumably) picking values that work well in most situations and only exposing a subset of those choices to the end-user. That of course makes it easier to use and less prone to error, but also creates situations where those technologies don't work as well as they could.

                      I'm definitely not an expert, but I'd be happy to give some recommendations about a particular use-case if you're interested. I'm also going to reply to your previous comment in a bit.

                      Comment

                      Working...
                      X