Previous Entry Share Next Entry
2016-01

нубский вопрос про unix/9p traditions

Я вот краем уха слышал, что в Unix'ах идеологически правильно, к примеру, если у нас есть какой-то browsable сетевой ресурс или устройство - интегрировать его как mount point, дабы дальше его всяческий софт мог использовать с этой точки монтирования, не заморачиваясь деталями.

Ну, nfs, smb, procfs и так далее.

А вот в каком месте (POSIX?) можно прочитать, как предполагается при этом жить с concurrency?
Т.е. вот я получил список файлов в папке, показал его юзеру, он что-то открыл и потом сделал "save" в ту же папку. А к тому времени на него напал какой-нибудь, ну не знаю, search indexer, или банально другой юзер файл открыл.

Хочется юзеру показать диалог "файл занят Васей", а индексеру сказать "отпусти файл временно", и всякое такое прочее.

Предположим, что у нас идеальный случай, и мы контролируем (можем запатчить) и приложение, и сетевой ресурс, и API файловой системы.

То есть, баги конкретных реализаций можно отставить в сторону, ограничиться багами в спецификациях. Где про такое читать, чтобы велосипед не изобретать?

UPD: чтиво в тему, чтобы была понятна глубина кроличьей норы -
http://danluu.com/file-consistency/
http://0pointer.de/blog/projects/locking.html
http://0pointer.de/blog/projects/locking2
https://www.samba.org/samba/news/articles/low_point/tale_two_stds_os2.html

This entry was originally posted at http://wizzard.dreamwidth.org/455707.html. It has comment count unavailable comments. Please comment there using OpenID.

  • 1
wizzard0 December 16th, 2015
Оу.

lyuden December 16th, 2015
.lock файл при операциях записи ?

И индексер не должен ждать пользователя. Максимум пометить у себя, что данный файл вскоре надо переиндексировать.

wizzard0 December 16th, 2015
Индексер уже открыл файл, а нам надо его вдруг подпатчить (e.g. append)


Edited at 2015-12-16 12:39 pm (UTC)

altmind December 16th, 2015
я может задам тупой вопрос - но нельзя ли файл открывать в неблокирующем режиме? если нет, нельзя ли файл копировать куда-то или делать снимок каким-нибудь ммапом для индексации?

lyuden December 16th, 2015
Блокирующее чтение по сети ? Это по моему не UNIX way. И ломает абстракцию файлов. Если это необходимо, то не надо использовать абстракцию файлов. Как то так.

amarao_san December 16th, 2015
Отдавать пользователю EBUSY? Не юзерфрендли, но все посиксовые штуки, либо shared, либо "кого тапки, тот и первый".

amarao_san December 16th, 2015
Вообще, по-хорошему, я бы делал даже интереснее: ioctl, который позволяет получить специфичную ошибку на IO, если кто-то другой в это время начнёт в файл писать.

Но да, нифига не posix.

wizzard0 December 16th, 2015
Ну, не posix, но может какой-то другой стандарт это решил более продуманно, что ли...

amarao_san December 16th, 2015
Я думаю, надо перестать смотреть в этом вопросе на унылое легаси, которое таки не сделало эти блокировки, и написать свои. С нуля. Мандаторные. В том числе с "вытесняющей блокировкой" (поломай меня если кто-то начал писать) и т.д.

mbr December 16th, 2015
так оно и есть.

mbr December 16th, 2015
Ты пытаешься вендопроблемы вкостылить в linux. Не нужно. Другой подход.

Нужен лок на файл - делай это явно через fcntl F_SETLKW. Чаще, как сказали выше - делают просто .lock файл.

wizzard0 December 16th, 2015
Дефолтное поведение винды меня тоже не устраивает. Более того, там по ссылкам написано, как это образовалось (тоже легаси) и какие проблемы реально создает %)

alamar December 16th, 2015
Если файл открыт на аппенд, очевидно, индексер проиндексирует, сколько успеет.

KIO, кажется, неплохую абстракцию представляет. Правда, не совсем юникс-вей.

_winnie December 16th, 2015
CAS (compare-and-swap)? Индексируем (или копируем себе) файл без блокировок. Если после индексации обнаруживаем что его поменяли - когда-нибудь в будущем его переиндексируем.


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

  • 1
?

Log in

No account? Create an account