Судьба бага 2645 в ядре Linux
Oct. 13th, 2009 11:03 am![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
codedotОбновление временных штампов при работе с отображаемыми в память файлами, скорректированное в ядре 2.6.24 принятием части восьмой версии решения для файловых систем, использующих общеядерный механизм file_update_time(), все еще остается для RAMFS и TMPFS. Между версиями ядра 2.6.31 и 2.6.32-rc4 подобную проблему в XFS удалось разрешить Christoph Hellwig.
После закрытия соответствующего бага 2645 ("msync() does not update the st_mtime and st_ctime fields") в январе 2008 года, к этому вопросу в LKML вернулись, когда было обнаружено, что при переходе от версии 2.6.24 к версии 2.6.26 ошибочное поведение временных штампов при использовании mmap() для работы с файлами проявилось снова. В последовавшем обсуждении проблемы в Kernel Bug Tracker вместо переоткрытия 2645 было предложено открыть новые баги против конкретных файловых систем.
Так как поведение XFS относительно значений atime и mtime стало корректным, возможно, пришло время попробовать разобраться с файловыми системами, лишенными запоминающего устройства (RAM-based), такими как RAMFS и TMPFS.
После закрытия соответствующего бага 2645 ("msync() does not update the st_mtime and st_ctime fields") в январе 2008 года, к этому вопросу в LKML вернулись, когда было обнаружено, что при переходе от версии 2.6.24 к версии 2.6.26 ошибочное поведение временных штампов при использовании mmap() для работы с файлами проявилось снова. В последовавшем обсуждении проблемы в Kernel Bug Tracker вместо переоткрытия 2645 было предложено открыть новые баги против конкретных файловых систем.
Так как поведение XFS относительно значений atime и mtime стало корректным, возможно, пришло время попробовать разобраться с файловыми системами, лишенными запоминающего устройства (RAM-based), такими как RAMFS и TMPFS.
