Как очистить необработанный список инодов?

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

mount -o remount,rw /mountpoint

К сожалению это не сработало:

mount: /mountpoint not mounted already, or bad option

dmesg доклады:

[2570543.520449] EXT4-fs (dm-0): Couldn't remount RDWR because of unprocessed orphan inode list.  Please umount/remount instead

umount тоже не работает

umount /mountpoint
umount: /mountpoint: device is busy.
    (In some cases useful info about processes that use
     the device is found by lsof(8) or fuser(1))

К сожалению ни lsof из fuser не показывать процессам, обращающимся к чему-либо, находящемуся под точкой монтирования.

Итак - как я могу очистить этот необработанный список потерянных, чтобы иметь возможность снова смонтировать файловую систему без перезагрузки компьютера?

Источник

6 ответов

Решение

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

Расширенное обсуждение из списка рассылки linux-ext4 содержит больше информации о том, что это сообщение и почему оно может появиться. Короче говоря, произошло одно из двух: либо вы столкнулись с ошибкой в ​​ядре, либо, что более вероятно, какое-то повреждение файловой системы произошло один из предыдущих раз, когда вы перемонтировали файловую систему только для чтения. Возможно, именно поэтому система думает, что что-то все еще использует файловую систему, а ее нет.

Если прошел год, а вы до сих пор не перезагрузили машину, просто откажитесь и запланируйте время обслуживания.

Источник

Если вы используете ext2 / ext3 / ext4, вы должны иметь возможность использовать e2fsck очистить осиротевшие иноды:

e2fsck -f

Для reiserfs вы можете использовать reiserfsck который также очистит осиротевшие иноды.

Источник

e2fsck -f <mount point> не сработает

Сначала выясните точки монтирования с

sudo mount -l

Тогда fsck диск прямо.

Например для меня

sudo e2fsck -f /dev/xvda2
Источник

Я бы порекомендовал сначала принудительно размонтировать раздел, т. Е. Использовать опцию -f, а запустить проверку файловой системы с помощью fsck.

Источник

Вы, вероятно, должны попробовать ленивую размонтирование, то есть:

umount -l
Источник

Я столкнулся с той же проблемой на машине AWS EC2. Решение усложнялось тем, что затронутый том был корневым томом экземпляра EC2. Следовательно, устройство не загружалось, и для экземпляра также был невозможен SSH.

Следующие шаги помогли мне решить проблему:

  1. Отсоедините том от экземпляра EC2.
  2. Настройте новый экземпляр EC2, используя тот же AMI и в той же зоне доступности, что и старый.
  3. Присоедините том (отключенный на шаге 1) к новому экземпляру.
  4. Выполните следующие команды:
      # Switch to Root user:
sudo -i

# Identify the device Filesystem name and save it as a variable:
lsblk
rescuedev=/dev/xvdf1    # Mention the right Filesystem for the particular volume.

# Use /mnt as the mount point:
rescuemnt=/mnt
mkdir -p $rescuemnt
mount $rescuedev $rescuemnt

# Mount special file systems and change the root directory (chroot) to the newly mounted file system:
for i in proc sys dev run; do mount --bind /$i $rescuemnt/$i ; done
chroot $rescuemnt

# Download, install and execute EC2Rescue tool for Linux to fix the issues: 
curl -O https://s3.amazonaws.com/ec2rescuelinux/ec2rl.tgz
tar -xf ec2rl.tgz
cd ec2rl-<version_number>
./ec2rl run
cat /var/tmp/ec2rl/*/Main.log | more
./ec2rl run --remediate

# Switch back from the Root user and unmount the volume:
exit
umount $rescuemnt/{proc,sys,dev,run,}
  1. Завершите работу экземпляра EC2 и отсоедините том.
  2. Присоедините том к исходному экземпляру и запустите экземпляр EC2.
Источник
Другие вопросы по тегам