mirror of
https://github.com/007revad/Synology_enable_Deduplication.git
synced 2026-04-25 20:56:02 +03:00
[GH-ISSUE #96] Synology keeps drive compatibility information for drives after forcefully disabling compatibility flag #24
Labels
No labels
pull-request
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference
starred/Synology_enable_Deduplication#24
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 @Ubsefor on GitHub (May 23, 2025).
Original GitHub issue: https://github.com/007revad/Synology_enable_Deduplication/issues/96
Just as the name states, there's a certain problem after enabling deduplication and/or disabling
support_drive_compatibilityinsynoinfo.conf.This can be sometimes needed, when using nvme or sas drives as volumes. The culprits are certain files in
/run/synostorage, which store information about nvme/sas drives compatibility even aftersupport_drive_compatibilitygets disabled, so this information doesn't seem to update on itself and nvme/sas drive becomes "unsupported for deduplication".I suggest looking into
libhwcontrol.soto patch this behavior or deletesys_not_supportlock files for NVME/SAS drives in your scripts, when certain flag is present.P.S. I understand, that this issue also linked with Synology_HDD_db, but the problem occurs with enabling deduplication on non-synology NVME drives, so here we are.