Странное поведение в команде mv – возможно, проблема с открытым вызовом sys?

Я замечаю очень странное поведение из команды «mv», которая может (или не может) быть связана с «открытым» системным вызовом. Мы запускаем RedHat v5. Существует два отдельных устройства хранения, один из которых установлен на «/ diskTo», а другой «/ diskFrom» (для этого примера).

В обычных операциях мы перемещаем (mv'ing) сотни, если не меньше тысяч, файлов с / diskFrom на / diskTo. Большинство файлов перемещается в порядке. Однако, из 1000 файлов, у нас есть 1-5, которые терпят неудачу. Ошибка – это отказ в разрешении. Когда мы проверяем назначение файла, файл существует , но содержимое inode является мусором. Например, временная метка является нежелательной («1969», но меняется), а разрешения – «0.».

Итак, я решил, что мы должны запускать strace на командах mv и записывать выходные данные сбоев. Вот что я нашел:

munmap(0x2b0328770000, 4096) = 0 geteuid() = 31169 ioctl(0, SNDCTL_TMR_TIMEBASE or TCGETS, 0x7fff90de9500) = -1 ENOTTY (Inappropriate ioctl for device) stat("/diskTo/foo.dat", 0x7fff90de95d0) = -1 ENOENT (No such file or directory) lstat("/diskFrom/bar.dat", {st_mode=S_IFREG|0444, st_size=234632119, ...}) = 0 lstat("/diskTo/foo.dat", 0x7fff90de9370) = -1 ENOENT (No such file or directory) rename("/diskFrom/bar.dat", "/diskTo/foo.dat") = -1 EXDEV (Invalid cross-device link) unlink("/diskTo/foo.dat") = -1 ENOENT (No such file or directory) open("/diskFrom/bar.dat", O_RDONLY|O_NOFOLLOW) = 3 fstat(3, {st_mode=S_IFREG|0444, st_size=234632119, ...}) = 0 open("/diskTo/foo.dat", O_WRONLY|O_CREAT|O_EXCL, 0400) = -1 EEXIST (File exists) write(2, "mv: ", 4) = 4 write(2, "cannot create regular file `/diskTo"..., 76) = 76 write(2, ": File exists", 13) = 13 write(2, "\n", 1) = 1 

Как вы можете видеть, вызывается функция unlink , которая возвращает -1, которая показывает, что файл не существует. Затем «mv» пытается открыть файл и получает ошибку EEXIST. Но файл не может существовать! Я не показываю это здесь, но скрипт, создающий этот тестовый пример, использует уникальные номера для создания каталогов – так что очень маловероятно (если не невозможно), что файл действительно существует. Не говоря уже о том, что unlink доказывает, что файл не существует.

Это может быть проблема с тем, как open создает содержимое inode? Я не знаю, где это посмотреть. Может быть, заглянуть в «mv» больше или «открыть» системный вызов?

One Solution collect form web for “Странное поведение в команде mv – возможно, проблема с открытым вызовом sys?”

Запустите полный fsck(8) на диске, похоже, что некоторые испорченные inodes плавают вокруг (или создаются «на лету»). Запустите badblocks(8) чтобы увидеть, есть ли что-то не так с диском. Посмотрите, что в журналах (или другой диагностике диска) говорится об этом.

Все программное обеспечение обновлено?

Что такое файловая система (ы)? Любое другое действие на diskTo которое может мешать? Является ли диск почти полным (в космосе, inodes) каким-либо образом? Любые другие отчеты в журналах?

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

  • В чем разница между жесткими ссылками и скопированными файлами?
  • Ограничить вход через группу пользователей в access.conf
  • Как изменить корневой каталог TFTP
  • Слишком маленькая ошибка области Hotplug
  • получение сообщения об ошибке при попытке зарегистрироваться для подписки на rhel6
  • Постоянно увеличивайте MTU для мостового интерфейса на RHEL 7
  • Как гарантировать, что установка кикстарта выберет определенный диск?
  • Как проверить, включена ли автопиляция для NTP?
  • Установка конфликтов Postfix с пакетом MySQL-server
  • Как использовать команду setarch uname в сценарии оболочки
  • Могу ли я монтировать флэш-накопитель NTFS на Linux
  • Interesting Posts
    Linux и Unix - лучшая ОС в мире.