3 ms·

At first I was confused because I thought that someone miraculously implemented compression with no context switching via VDSO. Funny to see how wrong I was ;)

by d33 8y ago

At first I was confused because I thought that someone miraculously implemented compression with no context switching via VDSO. Funny to see how wrong I was ;) Could someone explain how VDO works to me? Based on the example, it looks like another DM backend, like LUKS and such. It exposes a virtual device backed by a real one, adding a layer of compression, am I reading it right? I can also see that we're specifying a "logical size" that is exposed to the user. How much space is really used and how is it allocated? Can I grow the logical size later? Apart from this - what is the status of the patch, is it redhat-only or is it on its way to the upstream?

chr15p 8y ago
> Apart from this - what is the status of the patch, is it redhat-only or is it on its way to the upstream? I had a conversation with some of the RH kernel devs a few weeks ago and from my (hazy) memory, this comes from Red Hats acquisition of permabit so it was closed source, its now GPL'd but needs a fair amount of tidying up and bits rewriting to get it into a state that the kernel developers would accept it (they reimplemented some standard kernel features so they didn't have to link to GPL'd code). So it will be upstreamed but it will take time. In the meantime its released for RHEL only, not even in Fedora. Iirc could be ported to other distros (its 100% GPLed) its just not been.
sweettea 8y ago
> It exposes a virtual device backed by a real one, adding a layer of compression, am I reading it right? And deduplication, yes. >Can I grow the logical size later? Yes; the man page for the program discusses the growLogical subcommand briefly: https://github.com/dm-vdo/vdo/blob/6.1.1.24/vdo-manager/man/vdo.8#L281 https://github.com/dm-vdo/vdo/blob/6.1.1.24/vdo-manager/man/... >I can also see that we're specifying a "logical size" that is exposed to the user. How much space is really used and how is it allocated? There's a vdostats command mentioned in the article that exposes how much actual space is available and used. >Apart from this - what is the status of the patch, is it redhat-only or is it on its way to the upstream? It has not yet been submitted as a kernel patch.
- lotyrin 8y ago
  If I specify a logical size, and that's larger than the physical backing size, then what happens if someone attempts to write unique high-entropy data to fill their logical space?
  - sweettea 8y ago
    VDO will return ENOSPC when it gets a write and has nowhere to store it. The filesystem or other writer is responsible for passing ENOSPC up to the user, just like if dm-thin were to run out of space.
    - d33 8y ago
      OK, that sounds like a convincing reason not to use this feature - it really looks like it covers wrong abstraction. Consider reasons why you could get ENOSPC before: 1. Ran out of disk space, 2. Ran out of inodes, 3. Media reported ENOSPC and it gets propagated, 4. (something else I don't know about?) So now, #3 gets more common. Is it actually something that FS devs think about? "What if I get this weird error message?" Or is it something that could trigger a some destructive edge case in the filesystem and lead to serious data loss? You mention dm-thin doing the same, so I guess that at least the popular filesystems should handle it well. Anyway, when you think about it, how do you debug #3? You checked file size, you checked number of inodes, other than that the FS gives you no feedback. There's no central API to signalling this kind of problems and suggested solutions and I would say that this makes systems much less flexible. You could of course run vdostats (and whatever dm-thin uses to report its resources), but just imagine the amount of delicate code you would need to automatically solve this kind of issues. It's insane, it really looks like crappy engineering to me.
      - rickycook 8y ago
        inodes are a similarly weird reason to be “out of space”. the number of new-to-linux users that i’ve asked “have you checked inodes?” is huge. once you know that, you know that there are more things than just bits on the drive that effect available “space”

by d33 8y ago

chr15p 8y ago

> Apart from this - what is the status of the patch, is it redhat-only or is it on its way to the upstream? I had a conversation with some of the RH kernel devs a few weeks ago and from my (hazy) memory, this comes from Red Hats acquisition of permabit so it was closed source, its now GPL'd but needs a fair amount of tidying up and bits rewriting to get it into a state that the kernel developers would accept it (they reimplemented some standard kernel features so they didn't have to link to GPL'd code). So it will be upstreamed but it will take time. In the meantime its released for RHEL only, not even in Fedora. Iirc could be ported to other distros (its 100% GPLed) its just not been.

sweettea 8y ago

> It exposes a virtual device backed by a real one, adding a layer of compression, am I reading it right? And deduplication, yes. >Can I grow the logical size later? Yes; the man page for the program discusses the growLogical subcommand briefly: https://github.com/dm-vdo/vdo/blob/6.1.1.24/vdo-manager/man/vdo.8#L281 https://github.com/dm-vdo/vdo/blob/6.1.1.24/vdo-manager/man/... >I can also see that we're specifying a "logical size" that is exposed to the user. How much space is really used and how is it allocated? There's a vdostats command mentioned in the article that exposes how much actual space is available and used. >Apart from this - what is the status of the patch, is it redhat-only or is it on its way to the upstream? It has not yet been submitted as a kernel patch.

lotyrin 8y ago
If I specify a logical size, and that's larger than the physical backing size, then what happens if someone attempts to write unique high-entropy data to fill their logical space?
- sweettea 8y ago
  VDO will return ENOSPC when it gets a write and has nowhere to store it. The filesystem or other writer is responsible for passing ENOSPC up to the user, just like if dm-thin were to run out of space.
  - d33 8y ago
    OK, that sounds like a convincing reason not to use this feature - it really looks like it covers wrong abstraction. Consider reasons why you could get ENOSPC before: 1. Ran out of disk space, 2. Ran out of inodes, 3. Media reported ENOSPC and it gets propagated, 4. (something else I don't know about?) So now, #3 gets more common. Is it actually something that FS devs think about? "What if I get this weird error message?" Or is it something that could trigger a some destructive edge case in the filesystem and lead to serious data loss? You mention dm-thin doing the same, so I guess that at least the popular filesystems should handle it well. Anyway, when you think about it, how do you debug #3? You checked file size, you checked number of inodes, other than that the FS gives you no feedback. There's no central API to signalling this kind of problems and suggested solutions and I would say that this makes systems much less flexible. You could of course run vdostats (and whatever dm-thin uses to report its resources), but just imagine the amount of delicate code you would need to automatically solve this kind of issues. It's insane, it really looks like crappy engineering to me.
    - rickycook 8y ago
      inodes are a similarly weird reason to be “out of space”. the number of new-to-linux users that i’ve asked “have you checked inodes?” is huge. once you know that, you know that there are more things than just bits on the drive that effect available “space”