Media deletion via Emby on Synology NAS using Btrfs

[bobaldis 27]

Hi,

Running my Synology v7.2 with Btrfs and I understand it's my own fault as I ran too low on free space (I still had 1.4 TB so thought I was OK ) anyway NAS freezing and generally misbehaving, I managed to close lots of running applications (took a while under the circumstances) and managed to get into Emby to clear some Media files, this seemed to cause the NAS to through a hissy fit and "discussing" with Gemini it seemed to indicate because of the way Emby deletes media it causes a lot more disk/system utilisation (I'll post a summary below) but wondered if @Lukeor someone else at Emby could comment whether accurate or a case of AI hallucinations and if true anyway to alleivate it as far easier to look for Played Media and delete in Emby.
 

Gemini:
Here is a summary of the issues that occur when deleting media directly through the Emby application rather than using Synology File Station:

1. Btrfs Metadata Saturation & "Cliff Effect"

• Emby Deletes Bypass DSM Controls: When you delete a file in Emby, it issues a direct OS system call (unlink). On a Copy-on-Write (CoW) Btrfs volume operating near capacity (under 10–15% free space), deleting large media files or entire TV show directories forces Btrfs to immediately write thousands of complex pointer updates across its metadata trees.

• File Station Staggers I/O: Deleting through DSM File Station or SMB shares handles deletions through standard DSM queued operations, giving the Btrfs background cleaner time to process extents without completely starving system I/O.

2. Simultaneous SQLite Database Lockups

• Database & Storage Conflict: Deleting media via Emby triggers two heavy operations at once: unlinking files on the drive and updating Emby’s internal SQLite database (library.db).

• Package Native Priority: Because Emby is running as a native DSM package, its process threads share system resources directly with DSM. When disk I/O stalls during Btrfs space reclamation, Emby's database writes hang waiting on disk access, causing the Emby package to lock up and stalling system network daemons (making DSM and SSH unresponsive).

3. Immediate Permanent Deletion vs. Safety Buffer

• No Recycle Bin Safety Net: Media deleted inside Emby skips the DSM Share Recycle Bin (#recycle) entirely. File Station deletes, by contrast, move to #recycle (if enabled), allowing you to recover files accidentally deleted or stagger the permanent emptying of the Recycle Bin at off-peak hours.

4. Severe System Latency & Extended Boot Delays

• System-Wide UI Lag: A heavy deletion queue in Emby forces kernel processes like btrfs-cleaner and btrfs-transacti to spike Volume Utilization to 100%, causing DSM web interface lockups, SSH connection timeouts, and heavy disk I/O wait.

• Dirty Journal Replay on Reboot: If the NAS is restarted while Emby deletions or Btrfs space reclamation are actively processing, the system must replay uncommitted metadata transactions upon startup, causing exceptionally long reboot times before web/SSH access returns.

Best Practice Moving Forward

• Delete via File Station: Always remove unwanted video files or folders directly in DSM File Station in small, controlled batches (e.g., a few movies or 1 season at a time).

• Monitor Volume Utilization: Ensure Resource Monitor > Volume Utilization drops back down near 0% between deletion batches before clearing out additional files.

[Luke 42862]

Hi, yes this sounds right. On Windows and macOS we have added native recycle bin support. We haven't added this for linux yet but plan to in the future.