История изменений

Я первый раз такое вижу. В каком руководстве или каком стандарте ты такое прочитал? Насколько мне известно, ни одна ось не гарантирует синхронность mmap-а и файла до момента закрытия mmap-а. Потому что запись на накопитель - это дополнительная операция, а они по отношению к файлам могут быть дорогими. Если держать в памяти рассинхронизированное значение, то возникает проблема: как быть с программами, которые сделали read/write на файл, и ожидают, что прочитают целостную инфу с диска, а не черт пойми что из буферов?

О синхронизации при изменении через mmap и чтении через файловые операции см msync(), т.е. это стандарт. Синхронизация в обратном направлении (при изменении через файл и чтении mmap) не стандартизована, но де-факто (наверное) во всех операционках (c виртуальной памятью и mmap для файлов) кроме OpenBSD.

Повелось так достаточно давно, примерно c VMS. Причина достаточно проста - с некоторого уровня развития ядра гораздо проще и эффективнее сделать «unified page cache», а не полторы/две подсистемы. Проще говоря, сделать иначе - тяжелее, медленнее, дороже, хуже и т.п.

Собственно я так к этому привык, что никак не ожидал такого «закидона» в дизайне OpenBSD - это как «назло бабушке уши отморозить». Поэтому увидев проблему и с учетом ранее выявленных проблем с семафорами POSIX.1, решил что это баг, ибо фичей быть не может…

Да, я понимаю, что ты используешь /tmp и только для своих программ, но ты слишком много хочешь от ОС-и.

Нет, это промышленно эксплуатируемый движок БД.

Может быть ОС пошла у тебя на поводу, но только потому, что вас таких мног, и проще было подставить костыль под ОС, чем написать ядро правильно.

Такой «хак» используется примерно повсеместно. Аналогично мало кто рассчитывает на не-8-битный байт или представление отрицательных не в дополнительном коде.

Я первый раз такое вижу. В каком руководстве или каком стандарте ты такое прочитал? Насколько мне известно, ни одна ось не гарантирует синхронность mmap-а и файла до момента закрытия mmap-а. Потому что запись на накопитель - это дополнительная операция, а они по отношению к файлам могут быть дорогими. Если держать в памяти рассинхронизированное значение, то возникает проблема: как быть с программами, которые сделали read/write на файл, и ожидают, что прочитают целостную инфу с диска, а не черт пойми что из буферов?

О синхронизации при изменении mmap и чтение через файловые операции см msync(), т.е. это стандарт. Синхронизация в обратном направлении (при изменении через файл и чтении mmap) не стандартизована, но де-факто (наверное) во всех операционках (c виртуальной памятью и mmap для файлов) кроме OpenBSD.

Повелось так достаточно давно, примерно c VMS. Причина достаточно проста - с некоторого уровня развития ядра гораздо проще и эффективнее сделать «unified page cache», а не полторы/две подсистемы. Проще говоря, сделать иначе - тяжелее, медленнее, дороже, хуже и т.п.

Собственно я так к этому привык, что никак не ожидал такого «закидона» в дизайне OpenBSD - это как «назло бабушке уши отморозить». Поэтому увидев проблему и с учетом ранее выявленных проблем с семафорами POSIX.1, решил что это баг, ибо фичей быть не может…

Да, я понимаю, что ты используешь /tmp и только для своих программ, но ты слишком много хочешь от ОС-и.

Нет, это промышленно эксплуатируемый движок БД.

Может быть ОС пошла у тебя на поводу, но только потому, что вас таких мног, и проще было подставить костыль под ОС, чем написать ядро правильно.

Такой «хак» используется примерно повсеместно. Аналогично мало кто рассчитывает на не-8-битный байт или представление отрицательных не в дополнительном коде.