[Vdo-devel] MySQL on VDO volume

Michael Sclafani sclafani at redhat.com
Tue Nov 13 08:42:35 UTC 2018


If VDO is not showing any space savings, then it is extremely likely the
data has no duplicate 4K blocks, or the duplication happens so far apart in
the data that VDO can no longer find the duplicates in its index. The
latter is unlikely to be the issue at the dataset sizes you've mentioned
(unless you've configured a very small, dense index).

I don't know MySQL internals, but if it's using anything like the BTree
structures I'm familiar with, I wouldn't expect there to be duplicate 4K
blocks. The page references on an interior node of the tree have to be
unique, by definition--otherwise it would be a DAG, not a tree. If the leaf
pages are linked as in a B+tree, then those leaf pages also must have
unique references and cannot be identical to any others. A quick google of
"MySQL B+tree" seems to show that they use such a data structure, or that
it is an option to use.

The only way I can imagine getting much dedupe is by backing up that
database to a VDO volume periodically, or by recording many identical large
blobs in the database that are not normalized, or by storing large blobs
that contain many copies of the same block within a single blob. This
presumes the blobs are represented in storage in a format close to their
content, and not at arbitrary alignments (as they might be if they were
journaled or otherwise serialized).

ISO images will be as deduplicable or compressible as the data they
contain. For Linux distributions, I would expect significant, and for
multiple ISOs of similar distributions, I can also imagine copies of the
same blocks common to the distributions.

On Tue, Nov 13, 2018 at 1:04 AM, Prasad K <email.kprasad at gmail.com> wrote:

> Hi All,
>
> I recently used VDO on a LVM to store MySQL files. The volume was used
> only to store MySQL data. But it was not able to store more than the
> physical size. After reading the documentation, I understand VDO
> compression will be ineffective on binary files, but block level
> deduplication should have saved some space but it was also ineffective.
>
> Before this, I had tested VDO on another host by writing lots of Linux ISO
> files (CentOS 6 and 7 iso files) and the test went fine. I was able to
> store 2TB of ISO files on 450GB of physical space. I did not try to max out
> the space as storing 2TB of data was itself awesome and I wanted to try
> MySQL on VDO.
>
> So my questions :
>
> 1.) Why MySQL data had issues with VDO but not ISO files ?
> 2.) Have anyone faced similar issue ?
>
> Regards,
> Prasad
>
> _______________________________________________
> Vdo-devel mailing list
> Vdo-devel at redhat.com
> https://www.redhat.com/mailman/listinfo/vdo-devel
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/vdo-devel/attachments/20181113/800eb63b/attachment.htm>


More information about the vdo-devel mailing list