Назад | Перейти на главную страницу

xfs: найти файлы на первом 1 ТБ

Меня ударил xfs ' На устройстве нет свободного места. Согласно FAQ:

http://xfs.org/index.php/XFS_FAQ#Q:_Why_do_I_receive_No_space_left_on_device_after_xfs_growfs.3F

Единственный способ исправить это - переместить данные, чтобы освободить место ниже 1 ТБ. Найдите самые старые данные (т.е. те, которые были до первого роста) и переместите их из файловой системы (переместите, а не копируйте). Затем, если вы скопируете его обратно, блоки данных будут больше 1 ТБ, и это должно оставить вам много места для inodes ниже 1 ТБ.

Но как определить, какие данные нужно переместить? Я не могу уложиться по возрасту, потому что первые 10 ТБ были заполнены в тот же день с помощью rsync.

Я пытался:

xfs_db -r -c "blockget -i 1 -n -v" /dev/md3

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

Я чувствую, что могу использовать xfs_db и узнайте, какие файлы используют блоки в первом 1 ТБ, но я не мог понять, как это сделать.

(Используя опцию монтирования inode64 файловая система не даст На устройстве нет свободного места, но если позже вы забудете использовать опцию монтирования inode64 тогда вы получите На устройстве нет свободного места очередной раз. Я бы хотел избежать варианта крепления inode64 поскольку файловая система может быть смонтирована другими людьми в других системах, и они воля забыть об этом и получить удивительный На устройстве нет свободного места).

Попробуйте (пере) смонтировать файловую систему с -o inode64 вариант и посмотрите, решит ли это уже вашу проблему, но обратите внимание man mount:

inode64
 Indicates  that XFS is allowed to create inodes at any location in the filesystem, including those
 which will result in inode numbers occupying more than 32 bits of significance.  This is  provided
 for  backwards compatibility, but causes problems for backup applications that cannot handle large
 inode numbers.

Быстрый и грязный пример (удаление встроенных комментариев, корректировка чисел):

# select filesystem
find / -xdev -type f -print0 | \
  xargs -0r -I{} \
    # execute xfs_bmap on every file (and prefix output with path for later processing)
    sh -c "xfs_bmap -v {} | awk '{gsub(/\.\./,\" \"); print \"{}: \" \$0}'" | \
    # remove some cruft
    awk -F: '$4 != ""{print $1 " " $4}' | \
    # print line if last block < 1TB/512B/block and size (in 512B blocks) > 100.
    awk '$3 < 1024*1024*1024*1024/512 && $7 > 100{print}'