mirror of
https://github.com/007revad/Synology_HDD_db.git
synced 2026-04-25 13:45:59 +03:00
[GH-ISSUE #406] Parameter -S (write_mostly) seems to mix up SATA IDs #644
Labels
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference
starred/Synology_HDD_db#644
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Originally created by @TorbenSchreiter on GitHub (Dec 25, 2024).
Original GitHub issue: https://github.com/007revad/Synology_HDD_db/issues/406
**SEPARATE ISSUE CREATED AS SUGGESTED IN THREAD https://github.com/007revad/Synology_HDD_db/discussions/367 **
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_mostlyparameter-Sto 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:
write_mostly), whereas Drive 4 is the SSD. However, the log somehow missessata2and putssata4instead:Originally posted by @TorbenSchreiter in https://github.com/007revad/Synology_HDD_db/discussions/367#discussioncomment-11662929
@TorbenSchreiter commented on GitHub (Dec 25, 2024):
responding to https://github.com/007revad/Synology_HDD_db/discussions/367#discussioncomment-11663066
and
=> same problem as CT1024M550SSD1 is actually the SSD:
EDIT: This is quite strange:
but
@007revad commented on GitHub (Dec 25, 2024):
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 commented on GitHub (Dec 25, 2024):
[The script returned an error due to the missing "!" in
#!/bin/bashin line 1. With that changed, the output is:]@007revad commented on GitHub (Dec 25, 2024):
What does this command return? (you can obscure the serial numbers)
@007revad commented on GitHub (Dec 25, 2024):
And these commands:
@TorbenSchreiter commented on GitHub (Dec 26, 2024):
I swear the SSD is in physical slot 4...
@007revad commented on GitHub (Dec 26, 2024):
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:
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 commented on GitHub (Dec 26, 2024):
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=sata2and this seems to produce the correct assignments for "(W)" akawrite_mostly. (Only-Sseems to be picking the wrong sata#.)Do I actually need to reboot for
write_mostly?Thanks a lot for the help!
@007revad commented on GitHub (Dec 26, 2024):
Thanks for reminding me. I noticed this issue yesterday.
Actually I'm not sure. I may have added that message just in case.