logging volume

[akseg73]

We want to create a volume solely for append only logs on SSD. This is what we do:

1. fallocate() to preallocate 40 mb of log file
2. append 4kb blocks to the log file.

This is what we are thinking of doing:
-- disable compression, dedup
-- set sync=true

Does VDO play well with Linux Asynchronous i/o? In other words if aio is issued and async is true then does it complete the write before returning success to the caller?

[lorelei-sakai]

I am not certain I understand this question. If you disable both compression and deduplication, there is no reason to set up a VDO volume at all because you will not gain any benefit from it.

To your other question, VDO currently only supports asynchronous I/O, so write must be flushed to ensure they are stable on disk. (Older versions of VDO had a synchronous write mode, but the performance was fairly slow and it was not particularly popular, so we have removed it in newer versions.)

[akseg73]

Sorry for the confusion. So lets suppose we have a RAID0 of SSDs. And we want to utilize VDO on this. For a database usage we would have 2 volumes.
vol1 contains only data and utilizes only compression but not dedup
vol2 contains only logs and for that it disables both compression and dedup, any compression is done at application layer.

Additionally, in order to measure the performance impact of VDO layer we also want to measure VDO without dedup and compression to get a baseline minimal degradation due to VDO. Once compression is enabled we likely only become worse
from the baseline.

[lorelei-sakai]

This is certainly something you can do. For volume 2, I would recommend not using VDO. There is no reason to set up a VDo volume for production if you don't intend to use either the deduplication or the compression. (Benchmarking the costs of VDO is reasonable.)

[akseg73]

So is this what we have to do:

a) setup a RAID0 of all the SSDs
b) partition the RAID
c) utilize vdo with xfs on top for the partition for data
d) utilize xfs for the partition with log.

looks like sgdisk would have to be utilized somehow. In order to make the RAID work across reboot we had to do something
like this:

RAID_UUID=blkid -s UUID -o value /dev/md0
echo "UUID=$RAID_UUID /mnt/raid0 xfs defaults,noatime,nofail 0 0" >> /etc/fstab

maybe we have to partition the disks first and then create two raids one for data and one for logs.