DSM system partition missing on M.2 volume?

[TorbenSchreiter]

Hi there,

on a DS920+ with 4x HDD previously installed (as /volume1; ext4) I successfully installed 2x M.2 Samsung 990 EVO SSDs (SHR as /volume2; btrfs). The aim is to reduce spinning times of the HDDs (thus reduce power consumption) and add a bit of performance. As part of the effort I would like to recreate the HDD volume1 as btrfs as a last step.

I have finished migrating all packages and shared folders to the M.2s. Both Synology_HDD_db & Synology_app_mover worked nicely. I also moved the system Postgres following instructions here.

Then I started following the suggested procedure from here:

1. Migrate everything to vol2.
2. Shut down NAS.
3. Remove vol1 drives.
4. Boot NAS and mute the beep.
5. Start your packages and check they are okay.
6. Shut down NAS.
7. Install the drives you removed in step 3.
8. Boot NAS.
9. Delete vol1 storage pool.

However, after step 4, the NAS is not booting at all with the HDDs removed and only the M.2s inside. I had expected that the DSM system/OS partition would automatically mirror to all drives (volumes?). Originally, I had intended to next set the -S (write_mostly) switch for the script after confirming everything is working off the M.2s. But that does not seem to be the case.

What can I do to ensure the DSM system partition is also mirrored to the M.2s?

Thanks.

[007revad]

DSM does not mirror the system or swap partitions to M.2 drives (or drives in an expansion unit), so.

• You can't boot the NAS with just NVMe drives
• And write_mostly won't make DSM try to always read from the NVMe drives.

Technically there is a way to install DSM on NVMe drives... but it requires some seriously dangerous hacking.
See this reddit post and the reply by Alex_of_Chaos.

In your situation I'd just install a small 2.5 inch SATA SSD in the DS920+. But as you don't have a spare bay you'd have to:

1. Remove one of the HDDs (which will make the storage pool degraded).
2. Insert the small SSD drive and create a new storage pool (so DSM gets mirrored to it).

Then check your packages are all okay without the HDDs.

1. Shut down NAS.
2. Remove vol1 HDDs.
3. Boot NAS and mute the beep.
4. Start your packages and check they are okay.

Assuming step 4 was okay:

1. Shut down NAS.
2. Install the 3 HDDs you removed in the previous step 2.
3. Boot NAS.
4. Delete vol1 storage pool.
5. Create a new btrfs storage pool and volume 1.

The one downside of this is you now only have 3 HDDs for data instead of 4.

[TorbenSchreiter]

In your situation I'd just install a small 2.5 inch SATA SSD in the DS920+. But as you don't have a spare bay you'd have to:

1. Remove one of the HDDs (which will make the storage pool degraded).
2. Insert the small SSD drive and create a new storage pool (so DSM gets mirrored to it).

Last week I finally had the time to proceed as suggested in order to drastically reduce the time the HDDs are actually in spun up state. Already back in October I had moved all packages and package data to the M.2s. The problem was with DSM still residing only on the HDDs.

So, I put an older Crucial SATA SSD as Drive 4 and put its own independent Storage Pool with a "Basic" RAID configuration. Then I added the write_mostly parameter -S to the script and rebooted the box.

Unfortunately, for a week or so now the box behaves similar to before: HDDs are spinning up every couple of hours during the night (without reasonable activity).

There are two things slightly strange that I have observed:

1. The script log during boot up seems to have SATA IDs somewhat mixed up if I read correctly. Drives 1-3 actually are the HDDs (which should get tagged write_mostly), whereas Drive 4 is the SSD. However, the log somehow misses sata2 and puts sata4 instead:

Setting internal HDDs state to write_mostly
ST4000VN008-2DR166
sata1 DSM partition: in_sync,write_mostly
sata1 Swap partition: in_sync,write_mostly
ST4000VN008-2DR166
sata3 DSM partition: in_sync,write_mostly
sata3 Swap partition: in_sync,write_mostly
ST4000VN008-2DR166
sata4 DSM partition: in_sync,write_mostly
sata4 Swap partition: in_sync,write_mostly

2. The new Storage Pool 3 only has 12 MB allocated (see screenshot below). The Drive 4-SSD is completely empty. Hard to believe that DSM actually got mirrored to it. Or would this be accounted for outside of the storage pool (I think the math wouldn't add up if it were). Do I need to change the RAID type to a 1-disk SHR for it to get mirrored? Is there a way to check from the console whether DSM actually got mirrored to the new storage pool?

[007revad]

I'll have a look at what could have caused the script to to confuse drive 2 and 4.

You could do the following:

1. Run the script with the --ssd=restore option.
2. Then run the script with --ssd=sata4

You can check if sata4 has the DSM and Swap partitions with cat /proc/mdstat | grep -E 'md0|md1'

My sata1 is a HDD with (W) write-mostly set, and sata2 is an SSD

root@SENNA:~# cat /proc/mdstat | grep -E 'md0|md1'
md1 : active raid1 sata1p2[0](W) sata2p2[1]
md0 : active raid1 sata1p1[0](W) sata2p1[1]

[007revad]

@TorbenSchreiter Can you create an issue so I can work with you to find out why the script thought drive 2 was an SSD and drive 4 was a HDD.

[TorbenSchreiter]

Issue #406 is created re the ID mixup issue.

wrt DSM and swap partitions:

user123@GLHV3:~$ cat /proc/mdstat | grep -E 'md0|md1'
md1 : active raid1 sata3p2[0](W) sata2p2[3] sata1p2[2](W) sata4p2[1](W)
md0 : active raid1 sata3p1[0](W) sata1p1[3](W) sata2p1[2] sata4p1[1](W)

If I understand correctly, both partitions have also been created on the SATA SSD (sata4), correct? So, probably the mixup on the write_mostly is the main issue? Responding to that in #406.

What is the meaning of the IDs in "[x]", which are varying in ordering compared to yours?

[007revad]

both partitions have also been created on the SATA SSD (sata4), correct?
Correct.

So, probably the mixup on the write_mostly is the main issue?
Yes.

What is the meaning of the IDs in "[x]", which are varying in ordering compared to yours?
I didn't know, and a google search wasn't much help so I asked chatgpt

The numbers in brackets [0], [3], [2] and [1] denote their roles in the array:
[0]: This is the first (primary) disk in the RAID configuration.
[2]: This is the second disk in the RAID configuration (assigned the role number 2).

On my DS1821+ with 4 HDDs the md0 and md1 RAID Role Numbers are like yours:

# cat /proc/mdstat | grep -E 'md0|md1'
md1 : active raid1 sata4p2[0] sata2p2[4] sata1p2[2] sata3p2[1]
md0 : active raid1 sata4p1[0] sata2p1[4] sata1p1[2] sata3p1[1]