Бен, это Данила - Solaris

[redtigra]

Проблемы с записью в лог-файл на ZFS.
Убираю под кат. Мне не хватает базисного понимания процесса. Не связанным с профессией френдам приношу извинения. Завтра с утра еще в ру_рут закину, наверное.

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

Пока модуль крутился на машине, которая держала логи на NFS, мы не чаяли беды.

Сейчас модуль крутится на последнем релизе Соляриса. Файловая система - ZFS, mirror на два диска.

События в лог пишутся не сразу, а по факту накопления некоторого количества событий. Хуже того, если штатно погасить модуль, послав ему предписанный SIGTERM, ошибки, которые произошли (их можно спровоцировать), но еще не записались в лог - пропадают.

Выглядит это как некорректная работа кэша, хотя аналогия, конечно, враг решения.

На этом мысль останавливается. Я повесила мониторинг ошибок в системных вызовах скриптиком из DTraceKit - все в порядке, да и, мне кажется. так и должно быть, поскольку на другой файловой системе все работает нормально.

Я правильно понимаю, что системный вызов write записывает куда дают (то есть по умолчанию в кэш файловой системы) и умывает руки? То есть если что и мониторить, то это zfs? Но что именно? У меня огромный провал в этом месте, и я поблагодарю за любой хинт. А если удастся что починить - расскажу.

Comments

[ringm.livejournal.com]

Вызов write() сам по себе не дает никаких гарантий.
fsync() делается после write()? Какие опции у open()? O_DSYNC, O_SYNC?
Хочу предупредить, правда - я имел очень и очень серьезные проблемы с msync() на ZFS, latency там получается даже под не очень большой нагрузкой раз в 10 выше, чем на UFS, в итоге мы все попытки использовать ZFS для активной random-access записи отложили до лучших времен. С другой стороны, это всего один лог-файл, не так уж и страшно.

[rampitec]

write() имеет право писать в буфер, если для дескриптора не было вызвано fcntl с требованием вырубить кэширование. Иначе надо делать fsync() для принудительного скидывания буфера. В противном случае система может сама решать, когда его скидывать. Это все к тому же OS и FS специфик, вот для NFS, видно, кэширование и запрещено.

[an-kl.livejournal.com]

Это совсем не an_kl ... видимо, дело не в кэшировании, а в буферизации... ;-) С ZFS есть целый ряд побочных эффектов. Я бы посоветовал запись события начинать с fopen() и заканчивать fclose()... Есть еще побочные эффекты, связанные с dynamic inodes, так что на flock() полагаться нельзя. Ну итд...

[rampitec]

Тогда хватит fflush(). Но если был write(), и аргумент правильный, то флаш не поможет. Другое дело, что сорцы на модификацию особо не доступны, насколько я понял. Иначе нахрен их трэйсить?

[basile.livejournal.com]

Я конечно в солярисе ни бум-бум, но не может ли ZFS просто откатывать транзакции? Как я понимаю, данные накапливаются на всю транзакцию, после чего ZFS начинает наконец активно шуршать рейдами. Может, покопаться в том, почему модуль по сигтерму не коммитит файловую транзакцию? Может, у него есть какой-нибудь специально обученный сигюзр? Или запускать его надо по-другому какнть?
Может, этому zfs-у размер блока зарезать по самое не могу? ;)

[redtigra.livejournal.com]

fflush есть. Доступен девелопмент, но с большой неохотой, зараза.

Вопрос пока не в том, как это правильно написать, а как отлоовить, где работает неправильно, ты же понимаешь.

[redtigra.livejournal.com]

Я же не пишу это дело! :) Мне нужно выловить, где оно проваливается.

[rampitec]

Ну если доступен, то попробуй после флаша еще fsync вызвать...

[redtigra.livejournal.com]

он не настролько доступен :)
к тому же, ну ты же понимаешь, давать советы, которые я толком сама не понимаю, я не рискну... попробую посмотреть, вызывает ли модуль fsync вообще.

[redtigra.livejournal.com]

Насколько я понимаю (а я запросто понимаю по идее оно должно "шуршать рейдами" :), как ты говоришь, раз в положенный интервал, вроде по умолчанию раз в пять секунд, и вроде бы с размером блока это никак не связано. Кстати, блоки ZFS, по-моему, выделяет динамически, от 128 до 512 кб, хотя можно ограничить максимальный размер блока до этих самых 128 и получить тогда всегда минимальный блок, но что-то мне кажется, это nothing to do with.

(большая все-таки польза от таких разговоров мне :) я серьезно. спасибо.)

[redtigra.livejournal.com]

я хотела сказать "а я запросто понимаю неправильно" :)

[basile.livejournal.com]

Ымхо дело как раз в транзакциях.
Вот у тебя надо изменить блок. Ну, дописать например туда. Как я понимаю ZFS, она дуплит исходный блок и начинает измываться над дублем блока. Тут софту приходит сигтерм. По чистой логке (он же не сигкилл) софт должен скинуть буфера в FS, почистить потоки и закрыть транзакцию. FS должна засинхрить данные на диск и закоммитить блок. (то есть сказать, что этот файл "готов к использованию с новым содержимым") Чего-то из этого не происходит. Надо выяснять почему.
Потом FS видит грязный файл, выцепляет из него новый блок, подцепляет старый и ставит флажочек "чисто". Транзакция откачена. Нужные тебе данные тоже в принципе лежат на диске, но этот блок уже давно перераспределён обратно в "свободные".
Это как я понимаю механику ZFS... Может, и неправильно.