[Vdo-devel] [BUG] Discard not working

[Michael Niewöhner]

On Fri, 2018-08-10 at 18:17 -0700, Louis Imershein wrote:
> The main reason that VDO doesn't pass down discards directly is that it's
> complex to do this with deduplication. One challenge is, when should a logical
> discard be mapped to a physical one? A second one is how do you amortize
> discards for good performance as your physical address space gets fragmented. 

A logical discard should be passed down when the last mapping to the physical
block is removed. Discards on unmapped space do nothing.
Example with two mappings A, B to physical block X.
- A gets discarded
- if there is another mapping to X discard it, else do nothing
- there is B->X; do nothing
- B gets discarded
- if there is another mapping to X discard it, else do nothing
- no more mapping to X; pass discard to lower layer

Indeed, performance is an issue but we should start somewhere to see how big the
impact really is. IMHO performance optimization is step two.

> VDO is very good at managing allocation in flash-friendly ways and if you've
> got good dedupe rates the loss of performance won't be as bad as you think,
> but as usual try it.

I was worried more about wear-leveling than performance. I tried to find out
more about that topic and it seems wear-leveling works correct even without TRIM
when there is enough free space.

> Discards at the physical layer are definitely an issue the team is interested
> in eventually addressing.

Great :-) I will try (!) to implement the basic stuff for testing purpose in the
next days / weeks... If there is any success I'll let you know.

> As for the comments about VDO vs ZFS compression, I'd agree for large
> sequential IOs, use your native filesystem compresdion. For small 4K random
> IO, use VDO compression. Both have there uses for compressible data under
> different workloads.

Currently I don't really care about compression in my specific use case.
My final setup will be disks->ZFS/raidz1->ZVOL->LUKS->VDO(dedup+comp)->LVM->...
Main reason for that more or less complicated setup is that I don't trust ZFS'
native encryption, yet. It is just too new.
The second reason is memory requirement of ZFS dedup. This is why I want to use
VDO.

There is just one big limitation. As I mentioned before ZFS will sync only
mapped space in case of disk replacement. When discards don't get passed down
the ZVOL will not unmap any space resulting in sync of unmapped space (from
VDO's perspective) and thus resulting in increasing risk of a second disk
failure during sync.

> 
> LOUIS IMERSHEIN
> 
> PRINCIPAL PRODUCT MANAGER, DATA REDUCTION TECHNOLOGIES
> 
> Red Hat
> 
> limershe at redhat.com 
> M: (+1)831-588-5971    
> 
>    
> 
> On Wed, Aug 8, 2018, 1:14 PM Michael Niewöhner <admin at mniewoehner.de> wrote:
> > On Wed, 2018-08-08 at 22:09 +0200, Gionatan Danti wrote:
> > > Il 08-08-2018 17:35 Michael Niewöhner ha scritto:
> > > > Hi Bryan,
> > > > 
> > > > ah, thanks... I didn't realize that.
> > > > What is the reason for not passing down discard like ext*, LVM, ZFS, 
> > > > ... ?
> > > > Using VDO on a SSD would be very bad.
> > > > 
> > > > IMHO at least there should be an option to enable discard when needed.
> > > > In my case having discard is an absolute must-have because of ZFS.
> > > > Not having discard would mean ZFS never knows which blocks are unmapped 
> > > > and
> > > > don't need to be synced/scrubbed/...
> > > > (I don't want to use ZFS deduplication because of the memory 
> > > > requirements.)
> > > > 
> > > > Best regards
> > > > Michael
> > > 
> > > Hi, before going full-on for data deduplication, I would advice you to 
> > > test if your data *are actually deduplicable*.
> > > I evaluated both ZFS and VDO dedup and found that, for my VMs, they 
> > > provided minimal benefit over plain ZFS LZ4 compression at a very big 
> > > performance hit.
> > > 
> > > So, if your data are deduplicable - go ahead. If not, please stop here 
> > > and simply use compression.
> > > 
> > > Regards.
> > 
> > 
> > Hi,
> > 
> > since all my VMs are Linux VMs with exactly the same base, I am sure it is
> > deduplicable.
> > Thanks anyway.
> > 
> > Best regards
> > Michael
> > 
> > 
> > 
> > _______________________________________________
> > Vdo-devel mailing list
> > Vdo-devel at redhat.com
> > https://www.redhat.com/mailman/listinfo/vdo-devel
> 
> _______________________________________________
> Vdo-devel mailing list
> Vdo-devel at redhat.com
> https://www.redhat.com/mailman/listinfo/vdo-devel