Нужна помощь с отсутствующим пространством, root заполнен

Вопрос, который вы задаете, несколько глобальный, и существует множество способов автоматизировать определенные задачи. Проблема часто возникает из-за большого количества разных имен файлов или шаблонов соответствия регулярных выражений. Пожалуйста, создайте резервную копию файлов, прежде чем запускать какой-либо скрипт.

Чтобы понять направление, см. примеры:

array=(file1 file2 file3)
for i in "${array[@]}"; do
    echo "$i"
done

user@workdir:#cd /dir && ls >../files.list

main() {
    local list='/workdir/files.list'
    for item in $(cat "$list"); do
        func_read "$item"
    done
}

func_read() {
    local var="$1"
    [[ ! -d "$var" ]] && \
        while read -r line; do
            echo "$line"
        done < "$var"
}
main
-1
17.12.2019, 01:37
1 ответ

Возможно, у вас есть несколько удаленных файлов, которые остаются открытыми каким-то процессом.

Один из возможных вариантов — перезагрузка (все процессы завершатся и закроют свои файлы, освободив место ).

В противном случае вы можете сделать это (почти наверняка есть лучший способ, но я протестировал его на Ubuntu 18.04 -LTS, как вы просили)

find /proc -type l -exec ls -la \{\} \; 2>&1 | grep "/proc/[0-9]*/fd/.*deleted"

Это покажет что-то вроде:

lrwx------ 1 root root 64 Nov 18 08:16 /proc/1708/fd/139 -> /run/dovecot/login-master-notifycd7e64fd0dc27812 (deleted)
lrwx------ 1 root root 64 Nov 18 08:16 /proc/1708/fd/172 -> /run/dovecot/login-master-notify5d694b1832885980 (deleted)
lrwx------ 1 root root 64 Nov 18 08:16 /proc/1708/fd/177 -> /run/dovecot/login-master-notify03874675ec133d66 (deleted)
lrwx------ 1 root root 64 Nov 17 20:09 /proc/2160/fd/9 -> /tmp/.ZendSem.3acXWO (deleted)
lrwx------ 1 root root 64 Dec 16 06:39 /proc/10669/fd/9 -> /tmp/.ZendSem.3acXWO (deleted)
lrwx------ 1 root root 64 Dec 16 06:39 /proc/10670/fd/9 -> /tmp/.ZendSem.3acXWO (deleted)
lrwx------ 1 root root 64 Dec 16 06:39 /proc/10671/fd/9 -> /tmp/.ZendSem.3acXWO (deleted)
lrwx------ 1 root root 64 Dec 16 06:39 /proc/10672/fd/9 -> /tmp/.ZendSem.3acXWO (deleted)
lrwx------ 1 root root 64 Dec 17 00:01 /proc/10673/fd/9 -> /tmp/.ZendSem.3acXWO (deleted)
lrwx------ 1 mysql mysql 64 Dec 17 00:01 /proc/24928/fd/5 -> /tmp/ibZsXZWE (deleted)
lrwx------ 1 mysql mysql 64 Dec 17 00:01 /proc/24928/fd/6 -> /tmp/ibY4kIrj (deleted)
lrwx------ 1 mysql mysql 64 Dec 17 00:01 /proc/24928/fd/7 -> /tmp/ibhdYqWX (deleted)
lrwx------ 1 mysql mysql 64 Dec 17 00:01 /proc/24928/fd/8 -> /tmp/ib1PJXXg (deleted)
lrwx------ 1 mysql mysql 64 Dec 17 00:01 /proc/24928/fd/12 -> /tmp/ibuELYLV (deleted)

, что говорит мне о том, что MySQL и dovecot занимают «скрытое пространство». Таким образом, в этом примере я мог бы попробовать перезапустить сначала Dovecot, затем MySQL и т. д., и увидеть, когда(...остановка службы занимает чрезмерно много времени с большим количеством перегрузок на диске, после чего...)место становится пустым. освобожден

обновление

Я пропустил это в вашем вопросе :"без каких-либо других установок, кроме smb ". Попробуйте сразу же перезапустить этот .

Возможно, у вас активно ведение журнала VFS или высокий уровень отладки.

Это на самом деле случилось с моим $PFY однажды, у нас была включена отладка, чтобы проверить причуду Windows 10 (, давно решенную SMB4 кстати ), журнал превысил пять гигабайт, и он просто удалил журнал .

Итак, Samba продолжала писать в теперь невидимый файл журнала, который продолжал молча увеличиваться. Мы поняли, что произошло, когда исчезло около пятидесяти Гб, пока мы обвиняли пользователей, заполняющих пространство мусором (, они тоже этим занимались).

обновление 1.5

Вот один из способов заставить пространство «исчезнуть».

Предположим, у вас есть файловый сервер и данные на /var/media. Файлов около 250 Гб. Затем вы решаете добавить еще один диск или заменить диск большего размера с помощью синхронизации RAID плюс расширения или чего-то еще.

Таким образом, на этапе 2 у вас есть временно пустой /mnt/otherdisk с 8 ТБ свободного места, и вы успешно копируете эти 250 ГБ на новый диск/раздел, разрешения, ACL и все такое.

Когда вы закончите, вы, очевидно, захотите повторно использовать старую конфигурацию, сценарии, резервные копии и многое другое, поэтому вы монтируете новый раздел поверх старого каталога --, но забудьте сначала освободить его . Итак, теперь /var/mediaимеет 250 ГБ недавно скопированных файлов и 7,75 ГБ свободного места --, но исходные 250 ГБ по-прежнему находятся под всем этим, и их пространство не было освобождено.

Чтобы освободить место, вам нужно

umount /var/media && (
    mv /var/media /var/old-media
    mkdir /var/media # create a new "/var/media"
    chown --reference /var/old-media /var/media
    chmod --reference /var/old-media /var/media
    mount /var/media
)

Теперь, если /var/old-mediaдействительно содержит данные, вы можете сравнить его содержимое (, вероятно, сейчас оно устарело, но кто знает )с содержимым /var/media.

обновление 2

Ладно, перезагрузка ничего не исправила, значит файлы должны быть . Возможно, в lost+found, но теперь файловая система чистая, так что они должны быть там (, но просто для проверки каждого шага -, можете ли вы также опубликовать параметры монтирования?)

Попробуйте:

du -kx -d2 / | sort -n

чтобы получить содержимое диска (хорошо, такжеmedia). Это даст вам размер всех корневых поддеревьев. Если вы видите какое-то поддерево больше, чем должно быть, за исключением, конечно, /media, вы можете развернуть его. У меня большой /home/lserniнапример:

du -kx -d1 /home/lserni | sort -n

Если пространство по-прежнему необъяснимо занято, перезагрузитесь в одиночном режиме и запустите fsck.

Я не с готовностью поверю, что у вас настолько испорчена файловая система, что она показывает только занятое пространство, и тем не менее fsckне может это исправить!

1
28.01.2020, 05:09

Теги

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