Почему общий полезный размер уменьшается при копировании файлов в мой набор данных ZFS?

У меня есть жесткий диск 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-накопитель действительно не быстрый.

Кто-нибудь может подтвердить, что это ( или что-то в этом направлении) что происходит? Думаю, было бы полезно знать всем, кто сталкивается с подобной проблемой.

2
задан 4 November 2019 в 11:14
1 ответ

Вам отослали ~600 ГБ backup набор данных только с дополнительными 422 ГБ, отнесенными backup/data.

подход, используемый zfs, чтобы "опубликовать" правильное количество свободного пространства в файловой системе, как замечено утилитами прежней версии как df, должен изменить общее доступное дисковое пространство. В то время как немного сбивающий с толку, это производит корректное количество свободного пространства, и путь более ясно, чем, скажем, , что BTRFS делает .

В Вашем конкретном случае, как Вы пишете на backup (а не backup/data), общее свободное место для другого набора данных/файловой системы уменьшается соответственно.

РЕДАКТИРОВАНИЕ: , поскольку OP подтвердил, что он действительно ничего не записал на backup, я предлагаю и дополнительное объяснение. Функции ZFS как вид "удаляют дроссель", где удаленные файлы освобождены в фоновом режиме. Поскольку rsync создает и удаляет много временных файлов в скором времени, возможно что deleted-but-not-already-deallocated файлы, где говорится против корневой набор данных backup (сокращение AVAIL для backup/data).

3
ответ дан 3 December 2019 в 10:31

Теги

Похожие вопросы