[GH-ISSUE #318] Suggestion: Set Writemostly for DSM and Swap to HDD if have SSD #823

Closed
opened 2026-03-12 17:18:43 +03:00 by kerem · 13 comments
Owner

Originally created by @Xeroxxx on GitHub (Jul 7, 2024).
Original GitHub issue: https://github.com/007revad/Synology_HDD_db/issues/318

I found out if you have an hybrid environement and a SSD is part of you NAS between all those HDDs you can configure mdadm to primary read Swap and DSM from your SDD instead of the HDDs to gain access times.

Did a write-up over here: https://www.techspark.de/speed-up-synology-dsm-with-hdd-ssd/

I think that would be a great addition to your script.

Cheers

Originally created by @Xeroxxx on GitHub (Jul 7, 2024). Original GitHub issue: https://github.com/007revad/Synology_HDD_db/issues/318 I found out if you have an hybrid environement and a SSD is part of you NAS between all those HDDs you can configure mdadm to primary read Swap and DSM from your SDD instead of the HDDs to gain access times. Did a write-up over here: https://www.techspark.de/speed-up-synology-dsm-with-hdd-ssd/ I think that would be a great addition to your script. Cheers
kerem closed this issue 2026-03-12 17:18:49 +03:00
Author
Owner

@007revad commented on GitHub (Jul 7, 2024):

Interesting. I wanted more information on this so after reading your write-up I found https://raid.wiki.kernel.org/index.php/Write-mostly.

I'll have to install another drive in my Synology to test this (because md0 and md1 are not mirrored to my NVMe drives or HDD in an expansion unit).

I might start with a separate script. It would have to also cater for newer models that use device tree and use /sys/block/md0/md/dev-sata1p1 or /sys/block/md0/md/dev-sas1p1. People would need to specify their fast drive (or drives) because the script would have no easy way to determine which drive or drives are faster. Though the script could just set all internal HDDs as writemostly if there is an innternal SSD found.

Currently mine show in_sync

# cat /sys/block/md0/md/dev-sata3p1/state
in_sync

It looks like the script would need to echo writemostly > ... after each boot.

<!-- gh-comment-id:2212593517 --> @007revad commented on GitHub (Jul 7, 2024): Interesting. I wanted more information on this so after reading your write-up I found https://raid.wiki.kernel.org/index.php/Write-mostly. I'll have to install another drive in my Synology to test this (because md0 and md1 are not mirrored to my NVMe drives or HDD in an expansion unit). I might start with a separate script. It would have to also cater for newer models that use device tree and use `/sys/block/md0/md/dev-sata1p1` or `/sys/block/md0/md/dev-sas1p1`. People would need to specify their fast drive (or drives) because the script would have no easy way to determine which drive or drives are faster. Though the script could just set all internal HDDs as writemostly if there is an innternal SSD found. Currently mine show `in_sync` ``` # cat /sys/block/md0/md/dev-sata3p1/state in_sync ``` It looks like the script would need to `echo writemostly > ...` after each boot.
Author
Owner

@Xeroxxx commented on GitHub (Jul 8, 2024):

I've to check what happens after a restart. You can specific the parameter on volume creation as well, but this is actually risky and not a path I would follow.

Actually you don't need the determine which drive is faster, I think you want to read from ALL SSDs as you want to gain AccessTimes not Throughput for DSM.

Determine which drives are part of md0 and md1, than cat /sys/block/sda/queue/rotational. 1 HDD 0 SSD.

<!-- gh-comment-id:2213252557 --> @Xeroxxx commented on GitHub (Jul 8, 2024): I've to check what happens after a restart. You can specific the parameter on volume creation as well, but this is actually risky and not a path I would follow. Actually you don't need the determine which drive is faster, I think you want to read from ALL SSDs as you want to gain AccessTimes not Throughput for DSM. Determine which drives are part of md0 and md1, than cat /sys/block/sda/queue/rotational. 1 HDD 0 SSD.
Author
Owner

@Xeroxxx commented on GitHub (Jul 10, 2024):

@007revad I can confirm writemostly stays intact after a restart.

The speed of a restart feels enourmously faster.

<!-- gh-comment-id:2221634531 --> @Xeroxxx commented on GitHub (Jul 10, 2024): @007revad I can confirm writemostly stays intact after a restart. The speed of a restart feels enourmously faster.
Author
Owner

@007revad commented on GitHub (Jul 12, 2024):

@Xeroxxx

Do you want to set your drives back in_sync then try this script: https://github.com/007revad/Synology_HDD_db/blob/test/writemostly_test.sh

It checks that there are SSD and HDD drives and if there both it sets writemostly for the HDDs.

If it works I'll add the code to syno_hdd_db

<!-- gh-comment-id:2224973288 --> @007revad commented on GitHub (Jul 12, 2024): @Xeroxxx Do you want to set your drives back in_sync then try this script: https://github.com/007revad/Synology_HDD_db/blob/test/writemostly_test.sh It checks that there are SSD and HDD drives and if there both it sets writemostly for the HDDs. If it works I'll add the code to syno_hdd_db
Author
Owner

@Xeroxxx commented on GitHub (Jul 12, 2024):

Currently extending my storage pool with an additional drive. Will do afterwards! (ETA 2 days)

cat /var/log/synobootup.log
Startup finished in 13.354s (kernel) + 2min 46.683s (userspace) = 3min 38ms.

Can you guide me in the script where echo -writemostly > state is set? Can find where the unset happens?

writemostly > state # sets
-writemostly > state # removes flag

default is "in_sync"

<!-- gh-comment-id:2225879238 --> @Xeroxxx commented on GitHub (Jul 12, 2024): Currently extending my storage pool with an additional drive. Will do afterwards! (ETA 2 days) cat /var/log/synobootup.log `Startup finished in 13.354s (kernel) + 2min 46.683s (userspace) = 3min 38ms.` Can you guide me in the script where echo -writemostly > state is set? Can find where the unset happens? writemostly > state # sets -writemostly > state # removes flag default is "in_sync"
Author
Owner

@Xeroxxx commented on GitHub (Jul 16, 2024):

It does work and sets the variable on all HDDs in my case. I can do a pull request for unset, but I'm not sure how you want this to be implemented.

1 internal SSD
5 internal HDD

md0 sda: in_sync,write_mostly
md1 sda: in_sync,write_mostly

md0 sdb: in_sync,write_mostly
md1 sdb: in_sync,write_mostly

md0 sdc: in_sync,write_mostly
md1 sdc: in_sync,write_mostly

md0 sdd: in_sync,write_mostly
md1 sdd: in_sync,write_mostly

md0 sde: in_sync,write_mostly
md1 sde: in_sync,write_mostly
<!-- gh-comment-id:2230404567 --> @Xeroxxx commented on GitHub (Jul 16, 2024): It does work and sets the variable on all HDDs in my case. I can do a pull request for unset, but I'm not sure how you want this to be implemented. ``` 1 internal SSD 5 internal HDD md0 sda: in_sync,write_mostly md1 sda: in_sync,write_mostly md0 sdb: in_sync,write_mostly md1 sdb: in_sync,write_mostly md0 sdc: in_sync,write_mostly md1 sdc: in_sync,write_mostly md0 sdd: in_sync,write_mostly md1 sdd: in_sync,write_mostly md0 sde: in_sync,write_mostly md1 sde: in_sync,write_mostly ```
Author
Owner

@007revad commented on GitHub (Jul 16, 2024):

but I'm not sure how you want this to be implemented.

I chose to make it automatically set writemostly on HDDs because it was easier to do. The other alternatives are:

  1. Test the speed of each internal drive to get the fastest one (complicated but possible).
  2. Let the user specify the fast drive, or drives, as part of the option. Like --sdd=sda,sdb

I'm not sure yet either. I've been trying to think of what letter to use for the optional flag that relates to what it does. These are already used:

  -s, --showedits       Show edits made to <model>_host db and db.new file(s)
  -n, --noupdate        Prevent DSM updating the compatible drive databases
  -r, --ram             Disable memory compatibility checking (DSM 7.x only)
  -f, --force           Force DSM to not check drive compatibility
  -i, --incompatible    Change incompatible drives to supported
  -w, --wdda            Disable WD Device Analytics to prevent DSM showing
  -p, --pcie            Enable creating volumes on M2 in unknown PCIe adaptor
  -e, --email           Disable colored text in output scheduler emails
      --restore         Undo all changes made by the script
      --autoupdate=AGE  Auto update script (useful when script is scheduled)
  -h, --help            Show this help message
  -v, --version         Show the script version
<!-- gh-comment-id:2230493736 --> @007revad commented on GitHub (Jul 16, 2024): > but I'm not sure how you want this to be implemented. I chose to make it automatically set writemostly on HDDs because it was easier to do. The other alternatives are: 1. Test the speed of each internal drive to get the fastest one (complicated but possible). 2. Let the user specify the fast drive, or drives, as part of the option. Like --sdd=sda,sdb I'm not sure yet either. I've been trying to think of what letter to use for the optional flag that relates to what it does. These are already used: ``` -s, --showedits Show edits made to <model>_host db and db.new file(s) -n, --noupdate Prevent DSM updating the compatible drive databases -r, --ram Disable memory compatibility checking (DSM 7.x only) -f, --force Force DSM to not check drive compatibility -i, --incompatible Change incompatible drives to supported -w, --wdda Disable WD Device Analytics to prevent DSM showing -p, --pcie Enable creating volumes on M2 in unknown PCIe adaptor -e, --email Disable colored text in output scheduler emails --restore Undo all changes made by the script --autoupdate=AGE Auto update script (useful when script is scheduled) -h, --help Show this help message -v, --version Show the script version ```
Author
Owner

@Xeroxxx commented on GitHub (Jul 17, 2024):

I'm sorry I completely misunderstood. I thought you want me to toggle my active writemostly back.

It works completely fine, I thought the script should set it back to in_sync and echo -writemostly when its triggered again or with a switch.

You implementation is fine, no need for option 1 or 2.

How about:

	-m --mdadm-writemostly <optional drive> Define the drive you expect to be the fastest, otherwise all sdds will be choosen (recommended)
	   --mdadm-writemostly-restore
<!-- gh-comment-id:2234421179 --> @Xeroxxx commented on GitHub (Jul 17, 2024): I'm sorry I completely misunderstood. I thought you want me to toggle my active writemostly back. It works completely fine, I thought the script should set it back to in_sync and echo -writemostly when its triggered again or with a switch. You implementation is fine, no need for option 1 or 2. How about: ``` -m --mdadm-writemostly <optional drive> Define the drive you expect to be the fastest, otherwise all sdds will be choosen (recommended) --mdadm-writemostly-restore ```
Author
Owner

@007revad commented on GitHub (Jul 18, 2024):

I've released a new version with the writemostly option.
https://github.com/007revad/Synology_HDD_db/releases/tag/v3.5.96

  -S, --ssd=DRIVE       Enable write_mostly on slow internal drives so DSM 
                        runs from the fast internal drive(s).
                          -S automatically sets internal SSDs as DSM preferred
                          --ssd=DRIVE requires the fast drive(s) as argument,
                          or restore as the argument to reset drives to default
                          --ssd=sata1 or --ssd=sata1,sata2 or --ssd=sda etc
                          --ssd=restore
<!-- gh-comment-id:2236354706 --> @007revad commented on GitHub (Jul 18, 2024): I've released a new version with the writemostly option. https://github.com/007revad/Synology_HDD_db/releases/tag/v3.5.96 ``` -S, --ssd=DRIVE Enable write_mostly on slow internal drives so DSM runs from the fast internal drive(s). -S automatically sets internal SSDs as DSM preferred --ssd=DRIVE requires the fast drive(s) as argument, or restore as the argument to reset drives to default --ssd=sata1 or --ssd=sata1,sata2 or --ssd=sda etc --ssd=restore ```
Author
Owner

@Xeroxxx commented on GitHub (Jul 18, 2024):

Maybe replace "runs" to "primary reads" from SSDs or individual configured drives. But only a suggestion. I can do a PR/MR if you like.

Thanks for your work, think that helps others alot! Thanks for the Kudos in the Release Notes, appreciate that.

<!-- gh-comment-id:2237024674 --> @Xeroxxx commented on GitHub (Jul 18, 2024): Maybe replace "runs" to "primary reads" from SSDs or individual configured drives. But only a suggestion. I can do a PR/MR if you like. Thanks for your work, think that helps others alot! Thanks for the Kudos in the Release Notes, appreciate that.
Author
Owner

@007revad commented on GitHub (Jul 18, 2024):

You can make a PR/Mr

It has to be 80 chars or less. I don't know why I put a full stop on the end.

You could change it to something like the following:

  -S, --ssd=DRIVE       Enable write_mostly on slow internal drives so DSM 
                        primary reads are from internal SSDs or your selected
                        fast internal HDDs
<!-- gh-comment-id:2237527847 --> @007revad commented on GitHub (Jul 18, 2024): You can make a PR/Mr It has to be 80 chars or less. I don't know why I put a full stop on the end. You could change it to something like the following: ``` -S, --ssd=DRIVE Enable write_mostly on slow internal drives so DSM primary reads are from internal SSDs or your selected fast internal HDDs ```
Author
Owner

@Xeroxxx commented on GitHub (Jul 18, 2024):

I did a proposal. Feel free to edit.

<!-- gh-comment-id:2237629654 --> @Xeroxxx commented on GitHub (Jul 18, 2024): I did a proposal. Feel free to edit.
Author
Owner

@Xeroxxx commented on GitHub (Dec 12, 2024):

@007revad Just to document that. The setting survives updates. So set and forget.

In general you can see greatly improved startup times. Had several restarts now :D

<!-- gh-comment-id:2539849408 --> @Xeroxxx commented on GitHub (Dec 12, 2024): @007revad Just to document that. The setting survives updates. So set and forget. In general you can see greatly improved startup times. Had several restarts now :D
Sign in to join this conversation.
No milestone
No project
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference
starred/Synology_HDD_db#823
No description provided.