[Vdo-devel] MySQL on VDO volume

[Prasad K]

Hi Michael,

    Thanks for the detailed information.

Regards
Prasad

On Tue, 13 Nov 2018 at 14:12, Michael Sclafani <sclafani at redhat.com> wrote:

> 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/20181114/fa0ab898/attachment.htm>