A few days back I phased out an old iSCSI backup repository, which I was using as a temporary measure while I worked on a more robust backup solution. It did the job alright but iSCSI gets a bit finicky with latency, so WBADMIN backups to an iSCSI volume can take a lot longer unless everything is ideal as in lab conditions. In general I don’t recommend it. At least not long-term.
Anyway so part of the phase-out process involved deleting the iSCSI target and LUN from the Synology NAS, which is easy enough to do. But today I noticed that the Storage Manager still claimed the LUN was still consuming the same amount of space it always did. I had expected it would take a while for the DSM software to reflect the new available storage, but it should have updated this long before now. Some recommendations out there was to simply reboot the unit, which I had already done more than once in the interim, which obviously had no effect.
A quick search on the Synology forum revealed a nice quick solution — though it’s still unclear why the space wasn’t automatically recovered to begin with, here’s the method to delete the LUN manually (thanks to Synology forum user mugz):
- Enable SSH service via the Terminal & SNMP tool in the Control Panel.
- Log into the Synology as user “admin” using the appropriate password.
- ‘sudo -s’ for root shell
- Confirm there are no iSCSI LUNs in Storage Manager.
- Stop the iSCSI service:
- Remove files in folder and in subfolder /volume1/@iSCSI/
rm -rf /volume1/@iSCSI/*
- Start the iSCSI service again:
- Log out of the Synology
mugz also mentions deleting /var/db/iscsi/EP_JNL, but I could find no record of this file, so I could not say for sure whether it is necessary under normal circumstances. Arguably the DSM should be able to recover the data without having to resort to such brute-force measures, but if computers always did what they were supposed to, I wouldn’t have a job.