жесткая ссылка, созданная внезапно на флэш-памяти NAND

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

После копирования обратно в исходный файл я использую rename(*file2, *file1); в C, который убивает любую трассировку к config.txt.tmp

Каталог принадлежит root на диске mnt /sram, и ни у кого нет root-доступа к встроенной машине. Носитель данных — флэш-память NAND SRAM на встроенном Linux 2.6.10.

ls -l показывает

2 config.txt       699byte date_modify  
2 config.txt.tmp   699byte date_modify

config.txt.tmp должен быть создан, скопирован из config.txt, отправить параметры конфигурации в config.txt, а затем удален атомарно в течение всего 5-7 строк C

Каталог принадлежит root, и нет возможности создавать жесткие ссылки.

У кого-нибудь есть объяснение создания «жесткой ссылки» в функциях низкого уровня? Могу ли я столкнуться с состоянием гонки? Или это может быть какой-то код ядра для хранения во флэш-памяти? Или ошибка в линуксе?

Мой код работал более 5 лет, 100 машин, и ТОЛЬКО 1 машина недавно столкнулась с этой проблемой.


bash embedded-linux hardlink
person edward george    schedule 17.07.2012    source источник
comment
Из ваших различных прозаических описаний непонятно, какие операции над какими файлами выполняются. Не могли бы вы сделать это, например, чрезвычайно ясным? Используйте точные имена файлов, определяйте процессы, участвующие в каждом действии, перечисляйте шаги в последовательности, имена функций POSIX вместо «отправлять параметры конфигурации в config.txt» (вы не может отправить текст в файл, возможно, в сокет), и что означает «атомарное удаление», особенно учитывая, что оно занимает несколько строк?   -  person sehe    schedule 18.07.2012
comment
Я исправил свой ответ с дополнительной информацией   -  person sehe    schedule 18.07.2012

Ответы (1)


arrow_upward
1
arrow_downward

Проверьте, являются ли файлы фактически жесткими ссылками, выполнив

ls -i

показать иноды.

На макушке моей головы:

  • файловые буферы могли быть грязными перед перемещением?
  • если задействован форк, опять же, грязные буферы могут быть в игре даже до форка
  • is a flash 'overlay' filesystem driver present? Perhaps it has changed and contains an optimization that it previously didn't
    Think
    • unionfs
    • ауфс
    • ...?

Изменить

FWIW: Из вашего текста у меня сложилось впечатление, что вы, возможно, делаете все наоборот: я ожидаю, что вы будете писать в копию .tmp, и как только все будет сброшено и синхронизировано, «атомарно» (ну, скрестите пальцы для поддержки файловой системы и режим заказа) переименуйте его на место. (Сейчас я только предполагаю, потому что большая часть изображения слишком туманна, чтобы на самом деле продолжать)

Также см.: Безопасно ли rename() без fsync()?

person sehe    schedule 18.07.2012
comment
sehe, извините за поздний ответ, да, я вижу тот же номер, ссылающийся на эти два файла после ls -i. Я думаю так - только менее 50 единиц страдают от этого из сотен тысяч - я не верю, что это связано с самой файловой системой. Я ожидаю, что приложение от определенного программиста откроет эти файлы и выполнит определенную последовательность вызовов функций. Но беда в том, что НИКТО не дает свой код. Есть идеи? Спасибо - person edward george; 14.09.2012
comment
возможно, strace/ptrace может пролить свет на то, что делают другие программы, если вы не можете получить исходный код. OllyDbg/WinDbg на окнах - person sehe; 14.09.2012