Почему моя пустая папка имеет размер 134 ГБ?

Я переместил файлы со старого сервера на новый. Я не знаю почему, но когда я хочу заархивировать свою папку, она всегда висит на папке.

Сначала я подумал, что это не удалось, поэтому отменил, нажав ctrl + c , но я пытался несколько раз и всегда получал один и тот же результат.

Моя команда zip:

zip -r backup.zip /var/www -x '*.log*'

Я пробовал так много команд zip с параметром params / arg или без него, но все еще зависает в каталоге / admin / storage / logs / 0 .

Когда он повесил трубку, процесс архивирования все еще продолжался, поэтому я попытался подождать около 3 часов, пока он не будет завершен.

После завершения я переместил .zip с файлом размером 7,7 ГБ на новый сервер, а затем попытался извлечь его. При распаковке возвращается:

/ admin / storage / logs / 0: ошибка записи (диск заполнен?)

На моем новом сервере 160 ГБ, а на старом - только около 15 ГБ. Что делает новый сервер заполненным?

При исследовании я обнаружил, что папка / admin / storage / logs / имеет размер 134 ГБ, но когда я запускаю команду ls , она пуста. Я удалил эту папку, но когда я запустил df -h , используемое дисковое пространство осталось прежним.

Ниже приведена моя история команд:

root@ip-172-26-4-220:/var/www/www/admin/storage# du -hs * | sort -rh
134G    logs
1.2G    app
32K framework
8.0K    debugbar
root@ip-172-26-4-220:/var/www/www/admin/storage# cd logs/
root@ip-172-26-4-220:/var/www/www/admin/storage/logs# du -hs * | sort -rh
134G    0
root@ip-172-26-4-220:/var/www/www/admin/storage/logs# cd ..
root@ip-172-26-4-220:/var/www/www/admin/storage# rm -r logs/
root@ip-172-26-4-220:/var/www/www/admin/storage# du -hs * | sort -rh
1.2G    app
32K framework
8.0K    debugbar
root@ip-172-26-4-220:/var/www/www/admin/storage# df -h
Filesystem      Size  Used Avail Use% Mounted on
/dev/root       156G  156G  2.2M 100% /
devtmpfs        3.9G     0  3.9G   0% /dev
tmpfs           3.9G     0  3.9G   0% /dev/shm
tmpfs           796M  832K  796M   1% /run
tmpfs           5.0M     0  5.0M   0% /run/lock
tmpfs           3.9G     0  3.9G   0% /sys/fs/cgroup

Как освободить место?

На старом сервере admin / storage / logs папка имеет только 52M:

[root@server storage]# du -hs * | sort -rh
3.4G    app
52M logs
2.7M    framework
4.0K    oauth-public.key
4.0K    oauth-private.key
4.0K    debugbar

Почему было извлечено.zip-файл размером более 134 ГБ?

[root@server admin]# cd storage/logs/
[root@server logs]# ls -lh
total 51M
-rwxrwxrwx 1 root   root   1.0T Sep 30  2020 0
drwxr-xr-x 2 root   root   8.0K Sep  1 12:00 cron
-rwxrwxrwx 1 apache apache 1.6K Mar  6  2020 frontend-response-2020-03-06.log
-rwxrwxrwx 1 apache apache  720 Mar 23  2020 frontend-response-2020-03-23.log
-rwxrwxrwx 1 apache apache  353 Apr 29  2020 frontend-response-2020-04-29.log
-rwxrwxrwx 1 apache apache  719 Apr 30  2020 frontend-response-2020-04-30.log
-rw-r--r-- 1 apache apache  51M Sep  1 18:00 laravel.log
[root@server logs]# df -h
Filesystem      Size  Used Avail Use% Mounted on
devtmpfs        1.9G     0  1.9G   0% /dev
tmpfs           1.9G     0  1.9G   0% /dev/shm
tmpfs           1.9G  188M  1.7G  10% /run
tmpfs           1.9G     0  1.9G   0% /sys/fs/cgroup
/dev/sda2        36G   25G   11G  71% /
tmpfs           379M     0  379M   0% /run/user/0

вау, файл 0 имеет размер 1 ТБ. но почему df вернул только 25 ГБ использованного? Может быть, мне нужно сначала удалить его перед переносом?

1
задан 1 September 2021 в 17:58

1 ответ

Файл / var / www / admin / storage / logs / 0 вполне вероятно является разреженным файлом. То есть он не содержит фактических данных по всей своей длине. Есть участки, которые никогда не записывались и поэтому не занимают места на диске. Если они читаются, то ядро ​​Linux просто возвращает серию байтов со значением 0, которое сжимается очень хорошо, поэтому zip не имеет проблем с размещением всего файла размером 1 ТБ в архиве 7,7 ГБ. Но при распаковке архива unzip попытается фактически записать все эти нули на диск, потому что он не знает, что их на самом деле не было на старом сервере.

У вас есть два возможных варианта действий:

a) Удалить файл на старом сервере или, по крайней мере, исключить его из zip-архива. В любом случае он, наверное, не содержит ничего полезного. Редкий файл журнала довольно необычен и обычно возникает только из-за какой-либо неисправности, неправильной ротации журнала или чего-то подобного.

б) Вместо zip используйте программу архивирования с поддержкой разреженных файлов, например GNU tar, которая может воссоздать разреженный файл на новом сервере.

1
ответ дан 4 September 2021 в 09:24

Другие вопросы по тегам:

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