Parameter -S (write_mostly) seems to mix up SATA IDs

[TorbenSchreiter]

**SEPARATE ISSUE CREATED AS SUGGESTED IN THREAD #367 **

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?

Originally posted by @TorbenSchreiter in #367 (reply in thread)

[TorbenSchreiter]

responding to #367 (reply in thread)

user123@GLHV3:/volume1/scripts/Synology_HDD_db$ sudo -s /volume1/scripts/Synology_HDD_db/syno_hdd_db.sh -n --autoupdate=3 --ssd=restore
Synology_HDD_db v3.5.106
[..]
Restoring internal drive's state
ST4000VN008-2DR166
  sata1 DSM partition:  in_sync
  sata1 Swap partition: in_sync
CT1024M550SSD1
  sata2 DSM partition:  in_sync
  sata2 Swap partition: in_sync
ST4000VN008-2DR166
  sata3 DSM partition:  in_sync
  sata3 Swap partition: in_sync
ST4000VN008-2DR166
  sata4 DSM partition:  in_sync
  sata4 Swap partition: in_sync

and

user123@GLHV3:/volume1/scripts/Synology_HDD_db$ sudo -s /volume1/scripts/Synology_HDD_db/syno_hdd_db.sh -n --autoupdate=3 --ssd=sata4
Synology_HDD_db v3.5.106
[..]
Setting slow internal HDDs state to write_mostly
ST4000VN008-2DR166
  sata1 DSM partition:  in_sync,write_mostly
  sata1 Swap partition: in_sync,write_mostly
CT1024M550SSD1
  sata2 DSM partition:  in_sync,write_mostly
  sata2 Swap partition: in_sync,write_mostly
ST4000VN008-2DR166
  sata3 DSM partition:  in_sync,write_mostly
  sata3 Swap partition: in_sync,write_mostly

=> same problem as CT1024M550SSD1 is actually the SSD:

EDIT: This is quite strange:

user123@GLHV3:/volume1/scripts/Synology_HDD_db$ cat /proc/mdstat
Personalities : [raid1] [raid6] [raid5] [raid4] [raidF1]
md3 : active raid1 sata2p3[0]
      989480256 blocks super 1.2 [1/1] [U]

md2 : active raid5 sata3p5[0] sata1p5[2] sata4p5[1]
      7792583168 blocks super 1.2 level 5, 64k chunk, algorithm 2 [3/3] [UUU]

md4 : active raid1 nvme1n1p5[0] nvme0n1p5[1]
      1942787584 blocks super 1.2 [2/2] [UU]

md1 : active raid1 sata3p2[0] sata2p2[3] sata1p2[2] sata4p2[1]
      2097088 blocks [4/4] [UUUU]

md0 : active raid1 sata3p1[0] sata1p1[3] sata2p1[2] sata4p1[1]
      2490176 blocks [4/4] [UUUU]

unused devices: <none>

but

[007revad]

Can you run this and reply with the output: https://github.com/007revad/Synology_HDD_db/blob/test/writemostly_debug.sh

To download it:

[TorbenSchreiter]

Can you run this and reply with the output: https://github.com/007revad/Synology_HDD_db/blob/test/writemostly_debug.sh

[The script returned an error due to the missing "!" in #!/bin/bash in line 1. With that changed, the output is:]

user123@GLHV3:~$ sudo -s /volume1/scripts/Synology_HDD_db/issue_406/writemostly_debug.sh
internal_drives: sata1 sata2 sata3 sata4
internal_drives_qty: 4
idrive: sata1
idrive: sata2
idrive: sata3
idrive: sata4
internal_ssd_qty: 1
internal_hdd_qty: 3
internal_hdds: sata1 sata3 sata4

Setting internal HDDs state to write_mostly:
set_writemostly writemostly sata1
set_writemostly writemostly sata3
set_writemostly writemostly sata4

[007revad]

What does this command return? (you can obscure the serial numbers)

sudo syno_hdd_util --ssd_detect

[007revad]

And these commands:

sudo synodisk --isssd /dev/sata1
sudo synodisk --isssd /dev/sata2
sudo synodisk --isssd /dev/sata3
sudo synodisk --isssd /dev/sata4

[TorbenSchreiter]

user123@GLHV3:~$ sudo syno_hdd_util --ssd_detect
Model                Firmware     SN                   Dev        is SSD?
ST4000VN008-2DR166   SC60         XXXXXXXX             /dev/sata4 no
ST4000VN008-2DR166   SC60         XXXXXXXX             /dev/sata3 no
CT1024M550SSD1       MU02         XXXXXXXX             /dev/sata2 yes
ST4000VN008-2DR166   SC60         XXXXXXXX             /dev/sata1 no
If this is not right, please kindly report this to us
user123@GLHV3:~$ sudo synodisk --isssd /dev/sata1
dev:/dev/sata1 is not SSD
user123@GLHV3:~$ sudo synodisk --isssd /dev/sata2
dev:/dev/sata2 is SSD
user123@GLHV3:~$ sudo synodisk --isssd /dev/sata3
dev:/dev/sata3 is not SSD
user123@GLHV3:~$ sudo synodisk --isssd /dev/sata4
dev:/dev/sata4 is not SSD

I swear the SSD is in physical slot 4...

[007revad]

I swear the SSD is in physical slot 4...
It could be.

The /dev/sata# is assigned to each drive when they are first initialised. And you can move them to different drive bays and DSM still knows which drive is sata1 and sata2 etc. This is why Synology added a "Locate Drive" button in storage manager so when a drive needs replacing you make it's LED flash so you know which drive it is.

In my DS1821+ I set it up with 4 HDDs in bays 2, 3 and 5, 6 so It has:

• Bay 3 is sata1
• Bay 4 is sata2
• Bay 5 is sata3
• Bay 6 is sata4

When I add more drives I'll move the existing drives to bays 1, 2, 3 and 4 (because I prefer sata1 to be in bay 1 etc.)

[TorbenSchreiter]

Ok, I thought there'd be another level of indirection/mapping somewhere as DSM displays it actually according to physical bays. But for write_mostly it should not really matter, as long as it goes to sata2 (in my case).

I have now run the script w/ --ssd=sata2 and this seems to produce the correct assignments for "(W)" aka write_mostly. (Only -S seems to be picking the wrong sata#.)

user123@GLHV3:~$ sudo -s /volume1/scripts/Synology_HDD_db/syno_hdd_db.sh -n --autoupdate=3 --ssd=sata2
[..]
Setting slow 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
[..]
You may need to reboot the Synology to see the changes.
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)

Do I actually need to reboot for write_mostly?

Thanks a lot for the help!

[007revad]

Only -S seems to be picking the wrong sata#

Thanks for reminding me. I noticed this issue yesterday.

Do I actually need to reboot for write_mostly?

Actually I'm not sure. I may have added that message just in case.