mirror of
https://github.com/007revad/Synology_enable_Deduplication.git
synced 2026-04-25 12:46:03 +03:00
[GH-ISSUE #88] Deduplication configuration still not showing up for HDDs #21
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#21
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 @Msprg on GitHub (Nov 16, 2024).
Original GitHub issue: https://github.com/007revad/Synology_enable_Deduplication/issues/88
I'm running DSM as a Proxmox VM with passed-trough SATA controller for the drives.
I have run both enable deduplication with --hdd parameter and hdd_db script. Rebooted multiple times. Everything is healthy, performance analysis is enabled, and I've waited more than 10 minutes for the menu to show up. Like #79 but I still can't get it to work.
Any ideas about what I'm missing??
@007revad commented on GitHub (Nov 17, 2024):
It is looking like it's a an issue with virtual disks. Xpenology, proxmox and virtual disks are all beyond my level of knowledge.
@Msprg commented on GitHub (Nov 17, 2024):
Definitely not. As I've mentioned, the sata controller is passed through, meaning that the drives are communicating with DSM exactly as they would in a real bare metal hardware DSM system.
As far as virtual disks are concerned. Actually, the deduplication for those was ironically easily available even before running your scripts, despite me not needing it.
@Msprg commented on GitHub (Dec 3, 2024):
Would you mind sending me your patched
StorageManager 1.0.0-00502storage_component.js file to compare it to mine?@Msprg commented on GitHub (Dec 15, 2024):
@007revad There's a different js file that's being sent to the DSM web clients than the one your script is modifying, or something like that. Because, even if the
&&e.dedup_info.show_config_btnis deleted in the file correctly, the browser is still gettingstorage_panel.jsthat still contains the check. I have 100% confirmed that that's the culprit by using proxy and swapping the js Synology is sending with the modified js. And the deduplication menu was available right there and then.It's not browser cache, and I have rebooted Synology - multiple times, and cold booted it as well.
Now I can't say what to do now. Maybe there's another caching going on in the Synology itself or something? I really don't feel like grepping entire file system just to find where is the other file / string hiding, but that's my last resort for now.
Let me know if you happen to have any ideas~!
@007revad commented on GitHub (Dec 16, 2024):
After a reboot is the
&&e.dedup_info.show_config_btnstill deleted?I just searched DSM 7.2.2 update 2 for files named
storage_panel.json a DS720+ and only found 2 storage_panel.js filesI wonder if DSM is loading the backup storage_panel.js.1.0.0-00502 file as storage_panel.js. You could try moving, renaming or deleting storage_panel.js.1.0.0-00502.
@Msprg commented on GitHub (Dec 17, 2024):
I removed the check, and made both files the same. There has to be some other place where it's pulling it from still…
And btw, yes, the modifications do survive reboots.
@Msprg commented on GitHub (Dec 17, 2024):
Oh, and maybe this will help, this is the file that Synology is sending despite having the files above modified: storage_panel_sentBySyno.zip
@007revad commented on GitHub (Dec 18, 2024):
Do you have syno_enable_dedupe.sh scheduled?
My real Synology NAS don't have the storage_panel.js.gz (or storage_panel.js.gz.bak) files. I assume they are created by the xpe loader. Does the storage-panel.js in storage_panel.js.gz contain
&&e.dedup_info.show_config_btn?I suspect what is happening is your xpe loader, or trcp-addons etc, is recreating storage-panel.js during the junior boot stage and then syno_enable_dedupe is editing it. But where the ui is loading an unedited copy from is a mystery.
A quick look at storagepanel.sh and install.sh shows they are creating the gzipped copy of storage-manager.js
@Msprg commented on GitHub (Dec 18, 2024):
I don't.
Oh, I didn't know that!
I've tried to modify the archives, and it seems to have worked!
I think they're there because the DSM loader allows choosing things such as HDD bays graphics etc., so I guess it's achieving that by modifying the storage_panel.js as well.
@007revad commented on GitHub (Dec 18, 2024):
If you reboot does the storage_panel.js.gz still contain your edits?
I might change the script to delete the existing storage_panel.js.gz and gzip storage_panel.js
But before I do that can you provide a zip file containing everything in /usr/local/packages/@appstore/StorageManager/ui
@Msprg commented on GitHub (Dec 19, 2024):
So far, yes they do. However, I suspect that updates to the loader can easily break it / revert the changes.
Sure can do. Here you go, should be in more-less unmodified (xpenology / loader) state:
StorageManagerui.tar.gz
@Msprg commented on GitHub (May 20, 2025):
I mean, this is technically solved for me, as well as anyone else that will just replace the file in the GZIP archive. Whether or not this will be natively implemented into this dedupe script is a separate matter, at least for me.
Thanks for the cooperation, I'm happy I got it working ^^