Virtual DSM (vDSM) practical application

[DSfuchs]

vDSM is attracting notable attention, partly because its modern implementation via Docker bypasses any hardware limitations imposed by the manufacturer.

Whether using VMM or Docker, the resulting experiences are something I would like to share here.

 

[DSfuchs]

Performance consideration: Avoiding nested Copy-on-Write performance degradation on a Btrfs or ZFS filesystem.

By default, vDSM creates a Btrfs volume1. To avoid this performance penalty, it is necessary to switch to at least ext4.

 

[DSfuchs]

Today I managed a migration to ext4 for volume1. I see two ways to do this.

According to the AI recommendation, disable Btrfs:

sed -i 's/support_btrfs="yes"/support_btrfs="no"/g' /etc.defaults/synoinfo.conf

However, I fear that this causes the volumenumber after reboot to increment to an undesirable value, for which I know of that no remedy.


I handled it cleanly by deleting and recreating the data partition:

Script 1: Delete existing partition & reboot

#!/bin/bash

# Definition of the target drive
DRIVE="/dev/sdb"

echo "Deleting partition 1 on $DRIVE..."

# Fdisk automation for deleting
fdisk "$DRIVE" <<EOF
d
1
w
EOF
echo "Partition successfully deleted."

echo "System will reboot in 3 seconds..."
sleep 3

echo "Reboot the system now..."
reboot

Script 2: Create new partition & keep signature & reboot

#!/bin/bash

# Definition of the target drive
DRIVE="/dev/sdb"

echo "Creating new partition 1 on $DRIVE and keeping the signature..."

# Fdisk automation for creating
fdisk "$DRIVE" <<EOF
n
p
1


n
w
EOF

echo "Partition /dev/sdb1 successfully created (signature was kept)."

echo "Formatting /dev/sdb1 with ext4 file system..."

# Formatting the newly created partition
mkfs.ext4 -F "${DRIVE}1"

echo "File system ext4 successfully created on ${DRIVE}1."

echo "System will reboot in 3 seconds..."
sleep 3

echo "Reboot the system now..."
reboot