mirror of
https://github.com/007revad/Synology_enable_Deduplication.git
synced 2026-04-25 12:46:03 +03:00
[GH-ISSUE #90] After enabling deduplication on a fresh DS2422+ system it hangs? #19
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#19
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 @ylluminate on GitHub (Dec 23, 2024).
Original GitHub issue: https://github.com/007revad/Synology_enable_Deduplication/issues/90
Using a fresh DS2422+ with 32GB RAM with no data on the volume yet, installation and script execution, et al, seemed to go fine.
Saw the deduplication option in Storage Manager and enabled it:

After hitting "Save" button, it kept giving the loading spinner, but after around 10 minutes, I decided to reload the page. No reload.
sshnot working, system seems unresponsive. A look at the system has a green light as in the status seems fine, but no network lights neither HDD lights are on.It did (does?) have an "Optimizing in the background... 18.24% (Ti..." that was showing for the Volume 1 prior to the hang, so I am curious if some kind of a deadlock of sorts may be going on?
Have you seen any such behavior?
@007revad commented on GitHub (Dec 23, 2024):
I always try not to do anything drive related while DSM is "optimizing" the storage pool, as it LAN access can be really slow until the optimising has finished.
It's possible that one of HDDs has a fault, though the HDD and LAN LEDs should still on. Maybe it doesn't like your RAM.
If LAN access hasn't come back by now, and seeing as you have no data on it yet, I would press and hold the Power button for a few seconds to force it to shutdown or reboot.
@ylluminate commented on GitHub (Dec 23, 2024):
It is a fresh system, brand new drives (and no data on them except the OS and set up as a single storage tank), new memory, seems to be advertised to work and was detected fine (and is ECC). No lights for the drives, network interfaces, no sounds, no drives working. I held the power button in briefly and it started flashing blue, so I waited for about 10 minutes and wrote the post above.
When it didn't do anything for that protracted period, I held in the power button until it died and rebooted. Things seem "normal" again.
It is back to "Optimizing in the background" so I'm just going to sit and wait until that finishes before I do anything else - including put data onto it . Very frustrating since it has no data and it's saying it's going to take another day and some hours.
@007revad commented on GitHub (Dec 23, 2024):
The good news is that DSM remembers which drives it's already checked (which is what the "optimising" is doing) so if in future you delete the storage pool and create a new storage pool you'll get an option to skip the drive check (and it will only take seconds instead of days).
@ylluminate commented on GitHub (Dec 24, 2024):
Oddly after having finished the this optimization/striping process and having run a small speed test, the system crashed/restarted. It seems that there is some kind of a stability issue for sure going on.
I'm curious if you have a set of steps that are useful in isolating problem points?
I'd like to rule out both this deduplication enablement as well as any other elements since this is a new system and I'm kinda flying "blind" here just starting out with Synology... I definitely don't want to build on a shaky foundation at this juncture.
@007revad commented on GitHub (Dec 24, 2024):
Have you done a memory test? You run the Memory Test from Synology Assistant. The NAS will shutdown, test the memory, then finish booting.
To view the results of the memory test:
sudo cat /var/log/messages | grep 'Memtest'I'd also do an Extended SMART test on all the drives.
If DSM or a service or application crashed there are normally memory core dumps for whatever crashed. These files are saved in /volume1 with names ending in .core.gz or sometimes .core