Don't delete the NAS storage pool carelessly: I went through a 4TB Feiniu and found that all five places have taken up the space
one Sunday morning last month, a notification popped up from Feiniu: "Storage is insufficient, 95% used." I was stunned for a few seconds—that N100 dual-drive machine, when the 4TB data drive was installed, was so empty it could run a horse, so how did it only have 11GB left in two years? Even more awkward, the album was backing up videos on my wife's phone, and the backup task was completely frozen. WeChat asked if I wanted to expand. Don't rush to delete anything, and don't rush to buy the market. I ran through the machine from start to finish, and found nearly 400GB of storage. Where did the space go? Let's talk about it one by one.
Step one: Spend ten minutes to settle the bills—don't delete based on your feelings
storage pool is full of two types of people: one is to start deleting directly, only to find later that the deleted items are still things family wants; The other is to buy the stock after just one glance, but actually the machine contains 300GB of junk. My habit is to settle the accounts first.
SSH connect to the machine, the first thing to check is the total amount and mounting points:
df -h
my main data drive is mounted on vol1, showing total capacity 3.6TB, 3.4TB used, 11GB usable—matching the alarm. Next, let's see which one occupies the most of the first level of contents:
du -h --max-depth=1 /vol1 2>/dev/null | sort -rh | head -15
this command was finished, the bill was basically clear: download directory 1.1TB, photo library 620GB, video library 780GB, Docker-related over 90GB, and a piece of occupancy I didn't understand—snapshots. If you find the command line a hassle, install an NCDU and insert the arrow keys to enter and tunnel through layers—it's much more intuitive than the DU. Synology users have a ready-made suite called the "Storage Space Analyzer." Installed in the center of the kit, it can sort the top 200 large files in descending order by size and report duplicate files. I used it on my old DS220J, and it really saved the trouble. I couldn't find the same built-in kit on Feiniu, so I just SSH it and du it up, and the effect is the same.
Habitual Offender 1: Btrfs snapshot chain, quietly took 72 G
the most surprising thing about the bill was the snapshot. I chose Btrfs for this photo drive, with one snapshot per hour and 48 retained, one per day, 14 saved — originally to prevent accidental deletion, I didn't bother with it after setting it up. This time, I saw that the snapshot chain had taken up 72GB of my memory.
first clarify the temperament of snapshots: they store "variation." For example, if you move a 20GB folder to a new location, the file itself only occupies one copy, but the snapshot from before moving still points to old data, so 20GB is essentially an extra copy retained. During that time, I organized my photo catalog once and moved hundreds of gigabytes of stuff, and snapshots took up the space in one go.
don't mess around with how to handle it. Snapshots are a remedy for accidental deletion; deleting them all at once is like removing the insurance. My approach is to tighten the retention strategy: cut the hourly snapshots from 48 to 24, and keep the daily snapshots from 14 for 7 days. You can adjust the number of saved items in the snapshot settings. The old ones that exceed the limit will be automatically cleared. After the change, the next day you check—the 72GB limit drops to 38GB. Where to check how much snapshots occupy: In Feiniu's storage overview, the Btrfs file system lists a separate snapshot row, and Synology clearly shows the snapshot size of each shared folder in the snapshot suite storage. Here's another lesson for you: before you plan to organize your catalog on a large scale, clear out your old snapshots before you start. Otherwise, you'll be moving files and snapshots while keeping accounts, and the more space you manage, the tighter your space will be. That's exactly how I frustrated myself on my first trip. If you haven't opened a snapshot yet and are using ext4, you can skip this part. Ext4 doesn't have this issue. How to choose a file system I wrote a separate article before. If you're unsure, feel free to check it out.
Repeat Offender 2: Recycle Bin—deleted items are still lying on the drive
second big head is the recycle bin, 31GB. When deleting files in SMB Shares, by default they are not actually deleted; they are moved to the #recycle directory under the shared folder. My family has been deleting things on the mapping disk for the past two years, all lying there—including a batch of 'blurred' videos my wife deleted in 2024, each worth several hundred megapixels.
handling is divided into two steps. First, check if there are any accidentally deleted items (I found a video of my child turning one, and the family thought deleting it would actually be recovered. accidentally deleted the full rescue process I wrote a more detailed one); After checking and confirming it's junk, just clear the #recycle directory. The key is to clean up afterwards: set an automatic cleanup system for the Recycle Bin, set the number of days in Synology's shared folder editing, and the new Feiniu version also has a deletion preference option in the file management settings. I set it for 30 days, so don't accumulate a second 31GB.
Habitual Offender 3: Docker logs and images—wrote 8 G
in half a year using a single container.third piece is Docker. I run seven or eight containers on Feiniu: qBittorrent, Jellyfin, photo albums, downloaders, and so on. I was shocked when I checked: qBittorrent had 8.4GB of log files per container. The reason is simple: Docker's default json-file log driver no size ; the container keeps logs as long as it runs. The preservation client that flashes screens every few seconds is about this scale for half a year.
see how Docker occupies a single command:
docker system df
How many images and containers each occupy in one screen. There's a pitfall in log cleaning: the container is running, so you just run the log file space without releasing it, so you have to use Truncate to clear it:
truncate -s 0 /var/lib/docker/containers/containerID/container ID-json.log
the root of the issue is locking the logs. Feiniu Docker can configure daemon.json in settings, add two log-opts, set max-size to 100MB, max-file to 3, and from now on, a single container log can be capped at 300MB. Note: This configuration only applies to newly created containers. Old containers need to be deleted and rebuilt once before they can take advantage of the new rules—the night I rebuilt, I casually pruned several abandoned containers and floating images that had been inactive for half a year. The Docker section shrank from over 90GB to 51GB. Docker not yet familiar, read the introductory first; journaling is an advanced course.
Repeat Offenders 4 and 5: Old downloads consume 250GB, cache directories are all broken silver
the real space is actually the most plain: the undeleted content from the download directory. I checked "Completed"—the entire season of a 2024 show is over 90GB, several Blu-ray discs each have 50GB to 60GB, and a batch of movies "might watch later"—totaling 250GB, which accounts for two-thirds of what I cleaned up this time. There are no shortcuts—I just go through them one by one: delete what I finished, move what I can't bear to leave to a cold backup drive for archiving, keep what I want to keep on my NAS, but at least I know where they are.
don't overlook the remaining small points: Jellyfin's transcoding temporary directory has 4GB of storage, and you can control it by reducing the cache limit in playback settings; The album's thumbnails and recognition database take up more than 5GB, with over 40,000 photos. This is a normal expense and should not be touched; There are also duplicate files. I previously used FDUPES to clear 18.9GB after a scan, and the tools and commands are already available in duplication removal , so I just copied them. Also, a reminder: check qBittorrent seed task list too. I have a seed I've been working on for over a year, with a file over 40GB and no one has logged in for a long time. Delete the task and check "Delete file simultaneously," and the space immediately returns.
which can be deleted, which should be carefully considered before deleting, and which should be avoided
clearing space can get overwhelming once you get too late. I made a table with the boundaries and glanced at it before starting:
| category | can I delete it | My Disposal |
| Recycle Bin# recycle | and delete it again | After confirming everything is correct, delete and clear the data. Set 30 days for automatic cleaning |
| old snapshots beyond the retention policy | tighten the policy | don't delete everything manually—keep the closest ones as a remedy for regret |
| Docker container logs | you can easily clear | truncate and empty them, then pair them with max-size to completely fix |
| floating mirrors, For the container you stopped | cleared casually | prune confirm the container name before you don't accidentally delete it from the |
| you watched, or the downloaded | you set it yourself | delete or move a cold backup drive, regularly review |
| photo library and album database | avoid touching them | This is the lifeblood of a NAS and can only be protected by backups |
| other people's personal space | don't delete them yourself | ask them first—family harmony is more important than 400GB |
finish with a general order, follow it without confusion: first df -h to calculate the total, then du to position the main heads in layers; Snapshot collection strategy, recycle bin emptying, Docker log locking; Download the directory and delete the film yourself; Don't touch a family portrait or database even with a finger. After I finished this setup, the 4TB drive went from 11GB to 418GB usable, the alarm disappeared, and the album backup kept running. I casually set the storage warning threshold to 85%. Next time space is tight, I can get notified two weeks in advance, instead of waiting for it to freeze in the middle of the night and then remember to clean up.
