У меня есть жесткий диск USB емкостью 2 ТБ, который я использую в качестве резервного. Диск содержит таблицу разделов GPT с одним разделом типа bf00. В этом разделе я создал пул ZFS с включенными шифрованием и сжатием и один единственный набор данных.
Пока я синхронизировал свои файлы с диском, я заметил, что общий общий размер смонтированного набора данных стал меньше и меньше (обратите внимание: это странная часть, это действительно общий размер, а не доступный размер). Как это может быть? И как я могу использовать полную емкость?
Это результат df -h
, общий размер уже уменьшился до 1,2 ТБ (rsync все еще копирует):
backup/DATA 1,2T 380G 834G 32% /backup
Это это список zpool
:
# zpool list
NAME SIZE ALLOC FREE CKPOINT EXPANDSZ FRAG CAP DEDUP HEALTH ALTROOT
backup 1,81T 964G 892G - - 3% 51% 1.01x ONLINE -
А это список zfs
:
# 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 status:
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
Последние новости:
Хорошо, я оставил систему наедине с собой на ночь, чтобы посмотреть, что произойдет. Когда я в последний раз смотрел, цифры были такими, как указано выше: общее пространство резервной копии набора данных / ДАННЫХ сокращалось при копировании на него нескольких сотен ГБ. И даже когда rsync завершился, диск был занят (на что указывает светодиод). Также было большое использование ЦП в фоновом режиме.
Когда я взглянул сегодня утром, общий размер резервной копии / ДАННЫХ вернулся на 1,8 ТБ, и вся фоновая работа явно закончилась. Тадаа! : -)
Я думаю, что могло случиться вот что: rsync перебрасывал большое количество файлов в набор данных. ZFS, кажется, получает и своего рода буфер для файлов, которые необходимо записать. Этот буфер, вероятно, уменьшает общий полезный размер, пока он существует. Поскольку у меня включены сжатие и шифрование в пуле соответственно. набора данных, это могло занять некоторое время (спустя много времени после завершения rsync) даже на моей вполне приличной рабочей станции (12 ядер, 32 ГБ ОЗУ), возможно, потому что USB-накопитель действительно не быстрый.
Кто-нибудь может подтвердить, что это ( или что-то в этом направлении) что происходит? Думаю, было бы полезно знать всем, кто сталкивается с подобной проблемой.
Вам отослали ~600 ГБ backup
набор данных только с дополнительными 422 ГБ, отнесенными backup/data
.
подход, используемый zfs, чтобы "опубликовать" правильное количество свободного пространства в файловой системе, как замечено утилитами прежней версии как df
, должен изменить общее доступное дисковое пространство. В то время как немного сбивающий с толку, это производит корректное количество свободного пространства, и путь более ясно, чем, скажем, , что BTRFS делает .
В Вашем конкретном случае, как Вы пишете на backup
(а не backup/data
), общее свободное место для другого набора данных/файловой системы уменьшается соответственно.
РЕДАКТИРОВАНИЕ: , поскольку OP подтвердил, что он действительно ничего не записал на backup
, я предлагаю и дополнительное объяснение. Функции ZFS как вид "удаляют дроссель", где удаленные файлы освобождены в фоновом режиме. Поскольку rsync создает и удаляет много временных файлов в скором времени, возможно что deleted-but-not-already-deallocated файлы, где говорится против корневой набор данных backup
(сокращение AVAIL
для backup/data
).