У меня есть жесткий диск USB емкостью 2 ТБ, который я использую в качестве резервного. Диск содержит таблицу разделов GPT с одним разделом типа bf00. В этом разделе я создал пул ZFS с включенными шифрованием и сжатием и один единственный набор данных.
Во время синхронизации файлов с диском я заметил, что общее количество размер смонтированного набора данных становился все меньше и меньше (обратите внимание: это странная часть, это действительно общее количество размер, а не доступный размер). Как это может быть? А как использовать полную мощность?
Это результат df -h, общий размер уже уменьшился до 1,2 ТБ (в настоящий момент rsync все еще копирует):
backup/DATA 1,2T 380G 834G 32% /backup
Это zpool list:
# zpool list
NAME SIZE ALLOC FREE CKPOINT EXPANDSZ FRAG CAP DEDUP HEALTH ALTROOT
backup 1,81T 964G 892G - - 3% 51% 1.01x ONLINE -
А это zfs list:
# zfs list
NAME USED AVAIL REFER MOUNTPOINT
backup 973G 832G 98K none
backup/DATA 381G 832G 381G /backup
Кажется, не хватает одной трети емкости, как это может быть? Могу ли я как-нибудь вернуть себе место? И куда это делось? Я использую Arch Linux (5.3.8-arch1-1) с zfs-dkms 0.8.2-1.
Кстати: я не говорю о проблеме 2 ТБ против 1,8 TebiByte, это что-то другое.
Обновить:
Вот вывод статуса zpool:
zpool status
pool: backup
state: ONLINE
scan: none requested
config:
NAME STATE READ WRITE CKSUM
backup ONLINE 0 0 0
BackupDisk1 ONLINE 0 0 0
errors: No known data errors
и
zfs list -o space
NAME AVAIL USED USEDSNAP USEDDS USEDREFRESERV USEDCHILD
backup 793G 1011G 0B 98K 0B 1011G
backup/DATA 793G 422G 0B 422G 0B 0B
Последние новости:
Хорошо, я оставил систему самой себе на ночь, чтобы посмотреть, что произойдет. Когда я в последний раз смотрел, цифры были такими, как указано выше: общее пространство резервной копии набора данных / DATA уменьшалось при копировании на него нескольких сотен ГБ. И даже когда rsync завершился, диск был занят (на что указывает светодиод). Также была большая загрузка ЦП в фоновом режиме.
Когда я взглянул сегодня утром, общий размер резервной копии / ДАННЫХ вернулся к 1,8 ТБ, и вся фоновая работа явно закончилась. Тадаа! :-)
Я думаю что мощь Произошло следующее: rsync выбрасывал большое количество файлов в набор данных. ZFS, кажется, получает и буфер файлы, которые нужно записать. Этот буфер, вероятно, уменьшает общий полезный размер, пока он существует. Поскольку у меня включены сжатие и шифрование в пуле соответственно. dataset, это могло занять некоторое время (спустя много времени после завершения rsync) даже на моей вполне приличной рабочей станции (12 ядер, 32 ГБ ОЗУ), возможно, потому, что USB-накопитель действительно не быстрый.
Может ли кто-нибудь подтвердить, что это (или что-то в этом направлении) происходит? Думаю, было бы полезно знать всем, кто сталкивается с подобной проблемой.
У вас есть ~ 600 ГБ, рекомендованные backup только набор данных, с дополнительными 422 ГБ, указанными backup/data.
Подход, используемый zfs для "публикации" нужного количества свободного места в файловой системе, как это видят устаревшие утилиты как df заключается в изменении общего доступного дискового пространства. Это немного сбивает с толку, но дает правильное количество свободного места и путь яснее, чем, скажем, что делает BTRFS.
В вашем конкретном случае, когда вы пишете backup (скорее, чем backup/data), общее доступное пространство для другого набора данных / файловой системы соответственно уменьшается.
РЕДАКТИРОВАТЬ: поскольку ОП подтвердил, что он действительно ничего не писал на backupПредлагаю и дополнительные пояснения. ZFS представляет собой своего рода «дроссель удаления», при котором удаленные файлы освобождаются от размещения в фоновом режиме. Поскольку rsync создает и удаляет много временных файлов за короткое время, возможно, что удаленные, но еще не освобожденные файлы учитываются в корневом наборе данных backup (сокращение AVAIL для backup/data).