Короткий ответ

rm удаляет имя в ФС. Блоки живут, если (1) снимок/VSS, (2) процесс держит inode, (3) thin/LUN не получил UNMAP/TRIM, (4) ZFS refreservation/quota, (5) файлы уехали в .recycle SMB. Проверяйте слои сверху вниз: du vs df, zfs list -o space, lsof +L1, lsblk -D, Windows vssadmin. Не format D: и не zfs destroy tank.

Симптомы и как отличить

Типичная картина:

  • du -sh /mnt/tank/share упал, df нет;
  • гость NTFS 200 ГБ free, zvol used тот же;
  • после rm на Ubuntu /var df стоит, journal ещё держит.
du vs dfСлой
du << df, ZFS USEDSNAPснимки
du << df, нет snap, Linuxopen deleted (lsof +L1)
обе ФС свободны, пул нетthin / zvol / RAID VD
SMB удалили, место есть через неделюrecycle / shadow

Возможные причины

  1. ZFS snapshots / clones.
  2. Процесс держит удалённый файл (Java, SQL, nginx log).
  3. Нет TRIM: SSD/thin/iSCSI.
  4. Windows VSS, гибернация, pagefile.sys (реже на сервере).
  5. Quota не df.
  6. TrueNAS .recycle на шаре.
  7. Reservation zvol равен volsize — «удаление в госте» не уменьшает used пула до unmap.
  8. Дедуп держит блоки — редко как первый слой, см. DDT.

Диагностика

1. Сверить счётчики

df -h /mnt/tank/share
sudo du -xhd1 /mnt/tank/share
zfs list -o space tank/share

Windows:

Get-Volume -DriveLetter D
measure
vssadmin list shadowstorage

2. Open deleted (Linux)

sudo lsof +L1 | awk 'NR==1 || /REG/'
sudo lsof +L1 | grep -E 'deleted|/var/log'

Большой SIZE у deleted — место вернётся после close/рестарта этого сервиса, не rm повторно.

3. Снимки и recycle

zfs list -t snapshot -r tank/share
ls -la /mnt/tank/share/.recycle 2>/dev/null

TrueNAS Recycle Bin в SMB share.

4. Thin / TRIM

lsblk -D
sudo fstrim -v /mnt/data

Гость Windows на iSCSI: Optimize-Volume -DriveLetter D -ReTrim -Verbose (поддерживаемый том). На NAS: used zvol до/после.

zfs get used,referenced,volsize,refreservation tank/sql01

5. Quota

zfs get quota,refquota,refreservation tank/share

Решение

Сценарий A. Open file

Рестарт сервиса, который держит лог (по runbook). Для journald — journalctl --vacuum-size= если проблема в журнале, не kill systemd.

Сценарий B. Snapshots / VSS / recycle

Retention, destroy истекших, опорожнить recycle, resize shadowstorage. Имена сверять.

Сценарий C. TRIM/unmap

Включить fstrim.timer, discard в fstab только если политика позволяет (на части RAID discard бесполезен/вреден — проверяйте). Для iSCSI — unmap на target TrueNAS и в инициаторе.

После trim смотрите пул, не только гостевой df.

Сценарий D. Reservation

refreservation на zvol бронирует место. Снижение — осознанно, иначе thin overcommit (статья thin).

Сценарий E. Не тот том

Удаляли на NAS01, смотрели SQL01 локальный D:. Сверьте UNC vs диск.

Практический порядок на Ubuntu: df против du -x, zfs list -o space, lsof +L1, fstrim. На Windows: проводник против Get-Volume, vssadmin, затем на NAS zfs get used по zvol SQL. Перескакивание сразу в destroy snap, когда виноват SQL с гигантским deleted log, даёт минуту места и ночной сюрприз после рестарта службы.

NFS: удаление на одном клиенте при открытом файле на другом — сервер может держать inode. Смотрите lsof на NAS01 и на app01. SMB recycle — отдельная папка, её квота должна быть в мониторинге, иначе удалили значит перенесли в корзину шары.

Для thin iSCSI без unmap гостевой df врёт: свободно в NTFS, пул полон. После retrim used zvol не всегда мгновенный. Не делайте вывод через десять секунд.

Как проверить, что проблема устранена

df и zpool list AVAIL выросли. lsof +L1 без гигантских deleted. zvol used снизился после retrim (если thin). Повторное удаление тестового файла сразу двигает счётчик ожидаемого слоя.

Если не помогло

  • Только metadata_percent thin: не файлы.
  • SMB delete «в корзину клиента» — не дошло до NAS.
  • Compression/dedup: used считается сложно, смотрите zfs list -o space.
  • Immutable/append атрибут: файл не удалился, хотя UI врёт.

Профилактика

  • Алерт du vs df расхождение.
  • fstrim по расписанию на SSD/thin.
  • Recycle с квотой.
  • Не бесконечные snap.
  • Логи rotate, не один 80 ГБ app.log без logrotate.
  • Документ, какой том thin.

На NFS silly rename (.nfs*) держит место, пока процесс с открытым файлом жив. ls -a в каталоге после rm — обязательный шаг, если du не сходится. Не чистите .nfs* руками, пока процесс жив: сначала клиент.

Windows Search и антивирус на шаре могут держать дескрипторы и тени. После «удалили гигабайты, места нет» спросите, не идёт ли полная индексация. Это не ZFS bug.

Ещё слой — refreservation и quota, которые df в госте не показывает. Смотрите zfs get quota,refquota,refreservation сразу после du/df, не в конце расследования. Иначе час ищете deleted log, а место зарезервировано zvol под «полный» volsize.

На SMB не забудьте корзину клиента Windows: файл жив в Recycle Bin рабочей станции и на NAS уже удалён, или наоборот. Спрашивайте путь удаления, не только «я нажал Del».

FAQ

reboot всегда освобождает open files?

Да для deleted на той машине. На NAS reboot не закроет файл, открытый на клиенте NFS (другой слой: client holds). NFS: смотрите клиент.

Windows Compact OS?

Не ваш случай на D: с данными.

sync; echo 3 > drop_caches?

Не вернёт блоки снимков и thin.

ZFS hole_birth / sparse?

cp --sparse не лечит уже плотный файл. fallocate --punch-hole / перезапись sparse — точечно, не вместо trim на LUN.

Нужен ли zpool reclaim?

Смотрите версию OpenZFS и man. Не выдумывайте флаг. fstrim + destroy snap покрывают 90% тикетов.