Unable to use ssd as storage pool
snakealanis opened this issue · comments
Hi,
I am a new user of a 1823xs+
I ran the script (3.3.72), it seems to work, all my HDD & SSD's are green now
Despite this, i can't use my ssd's as storage pool (WD SN850X 4 TB)
I am able to use them as cache, so the "normal synology behaviour"
Am i doing something wrong ?
You should able to use the M.2 SSDs as a cache or a volume.
What version of DSM is on the DS1823xs+?
Have you rebooted after running the script?
Hi,
I have version 7.2.1 69057
Yes i restarted several times. Part of the script works as all my drives are green now, but it still refuses to create a pool with my ssd's
The DSM UI features a button to manually update the compatible database. You can press that button without a reboot; it should work.
My DS1821+ also encountered the same situation last week. After executing the script and rebooting, it couldn't be added as described.
I have a theory that DSM caches the database somewhere, and directly changing the database file will not update that cache.
there is indeed this db update button
if i click "update now" it says the db is already up to date
i tried to manually update it with the synology db available on their site, it updates, but still doesn't work. I rebooted, and still no luck
sorry for unclear information
the procedure:
execute this script
reboot
press ui update button
and it should works.
the script already set the db update url to localhost, so the ui update button will not fetch official db files, just to let DSM reread the modify db files.
hope it explains.
Hi, thanks for the help
I tried as you said
i re run the script, rebooted
immediately tried to push the update button, but now i get this message
and i still cannot create the pool :o(
The script makes DSM check the disk compatibility at the end of the script with:
sudo -i synostgdisk --check-all-disks-compatibility
Manual db updates only work if there is a newer db version available AND the update drive db URL is not set.
To restore the drive db URL run the script without the -n option.
In DMS 7 each .db file has a .version file. A few also have a .release file. For a NAS without an expansion unit or M.2 PCIe card we're only interested in the host files.
If you run the following commands you'll see the version number and release date:
cat /var/lib/disk-compatibility/ds1821+_host_v7.version && echo
cat /var/lib/disk-compatibility/ds1821+_host_v7.release && echo
On my DS1821+ with DSM 7.2.1-69057 Update 3 they return:
8043
20230915
I assume they would both need to be changed to smaller numbers before a manual drive database update would work.
sudo -i
echo -n 8000 > /var/lib/disk-compatibility/ds1821+_host_v7.version
echo -n 20230101 > /var/lib/disk-compatibility/ds1821+_host_v7.release
What options did you run the script with?
I always use the -n option. This prevents DSM updating the drive databases (which is what you want).
You can run the script with the --restore option to undo all the changes it made... then reboot.
I have a theory that DSM caches the database somewhere, and directly changing the database file will not update that cache.
I experienced something similar yesterday when testing my syno_enabled_dedupe script. After running it with the --restore option and rebooting the Data Deduplication was still available for my HDD volumes.
well you guessed, i f... up with the parameters, i ran with -nr and that's what was wrong
i used the --restore option, rebooted
re ran the script with -r parameters
and without even rebooting it worked
I then rebooted to check and everything is working now
thanks a lot for you help
It sounds like the xs models check if the drive db URL has been changed.