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:
/usr/syno/etc/rc.sysv/S78iscsitrg.sh stop - Remove files in folder and in subfolder /volume1/@iSCSI/
rm -rf /volume1/@iSCSI/* - Start the iSCSI service again:
/usr/syno/etc/rc.sysv/S78iscsitrg.sh start - 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.
Hi there,
Have you figured out how to reclaim space from a Synology iSCSI LUN after you’ve deleted data and zeroed out the space (sdelete)?
I couldn’t get this working for me. I’ve been trying to use the best of both worlds: the management simplicity of a Synology NAS and the robustness of Windows block-level deduplication for (mostly) lab VM storage: Create large, thin-provisioned iSCSI LUNs, present them to Windows Server 2019 (with Hyper-V), format the LUNs with ReFS or NTFS and deduplicate them on nightly schedules….then store VMs and VHD/VHDX files there…but if space can’t be reclaimed, it would be a bummer.
Thick provisioning is not what I had in mind….
thanks! it works for me!
Thanks worked for me ;-)
did not work for me but this did:
btrfs subvolume delete /volume1/@iSCSI/*
Does not work with Synology 7.1. The service does not exist or was moved.
In DSM 7 the service was renamed SAN Manager
I was able to get rid of the SAN manager with this description
https://mariushosting.com/synology-how-to-delete-san-manager/
but rm -rf /volume1/@iSCSI/* still gives me
ash-4.4# rm -rf /volume1/@iSCSI/*
rm: cannot remove ‘/volume1/@iSCSI/LUN/VDISK_BLUN/503587e1-6f39-4040-b490-ffffd5f8546a’: Operation not permitted
rm: cannot remove ‘/volume1/@iSCSI/LUN/BLUN/503587e1-6f39-4040-b490-ffffd5f8546a’: Operation not permitted
rm: cannot remove ‘/volume1/@iSCSI/Snapshot/BLUN/503587e1-6f39-4040-b490-ffffd5f8546a/85e534db-1be2-46a5-94fa-debc2816dc37/vdisk.bdeaa644-31ae-408b-90d7-7f59757f6522.bbb1b078-b566-4dfa-8c9e-b717b1b654cd.2.0_00000’: Read-only file system
rm: cannot remove ‘/volume1/@iSCSI/Snapshot/BLUN/503587e1-6f39-4040-b490-ffffd5f8546a/9b1cf88a-cb1a-4269-9ef8-f635a7f203c1/vdisk.bdeaa644-31ae-408b-90d7-7f59757f6522.bbb1b078-b566-4dfa-8c9e-b717b1b654cd.2.0_00000’: Read-only file system