ФС

Да.

ext3 ?

>ext3 ?

Как заблокировать каталог/файл от чтения и/или изменения (чтобы только мой процесс это мог делать)? Как создавать/изменять/удалять файлы/каталоги, другие процессы не видели изменения, а потом по моему выбору откатить или закоммитить транзакцию?

Это нах тебе такое? :)

Для работы с этим нужны будут свои файловые менеджеры/утилиты. Фактически, получится обычная база данных, которая при определенных ситуациях выглядит как файловая система.

А при чем тут вообще ФС? Это все фичи драйверов фс, а не самой фс как таковой. Вон винда умеет блокировки на ntfs и даже вроде бы на fat32. Линукс - нет, ибо у него идеология такая.

LVM ;-)

>Это нах тебе такое? :)

Ну, например, чтобы не было "неготовых" файлов, когда программа вырубится/наткнётся на отсутствие места на диске или другая начнёт писать туда же. Или чтобы рекурсивное удаление каталога выполнилось даже тогда, когда другой процесс активно пишет в него.

>Для работы с этим нужны будут свои файловые менеджеры/утилиты.

Так эти дополнительные функции будут в основном использоваться в своих программах.

>Фактически, получится обычная база данных, которая при определённых ситуациях выглядит как файловая система.

А как в SQL-базу данных закачать большой файл, не храня его целиком в памяти?

>А при чем тут вообще ФС? Это все фичи драйверов фс

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

fsvs ?

fopen( 'filename', O_EXL ) ?

любая фс в линуксе позволяет это делать. Только особенность в том, что это не принудительная блокировка. То есть все приложения _обязаны_ проверять, заблокирован ли файл/каталог прежде чем обращаться к нему.

Не гоните пургу, товарищи.

В Linux большинство блокировок - рекомендательные, т.е. программа _может_ проверить, не заблокирован ли файл целиком или определнный диапазон в нем другой программой. Никаких препятствий со стороны ядра на чтение/изменение/удаления данного файла любым процессом вне зависимости от наличия/отсутствия блокировок не делается.

В стандарте POSIX определены также _обязательные_ блокировки, при наличии которых процесс, пытающийся получить доступ к заблокированному файлу получает либо отлуп на вызове функций работы с файлом, либо блокируется, но используются они редко.

Отличие в поведении винды и линукса в поведении по умолчанию: при открытие файла в линуксе по умолчанию он открывается в неблокирующем режиме, а в винде - в блокирующем (хотя в последнем я не уверен).

что же касается транзакций и прочего околомаркетоидного трэша, так ими пользуются все журналируемые системы.

>что же касается транзакций и прочего околомаркетоидного трэша, так ими пользуются все журналируемые системы.

Слово "пользовательские" ничего не говорит? Читай мои коменты выше.

> Слово "пользовательские" ничего не говорит?

да мало ли ерунды люди говорят.

И как же пользователь может создать/закоммитить/откатить транзакцию (в пределах одной транзакции могло быть создано/удалено/изменено дохрена файлов и каталогов) в журналируемой ФС?

> И как же пользователь может создать/закоммитить/откатить транзакцию (в пределах одной транзакции могло быть создано/удалено/изменено дохрена файлов и каталогов) в журналируемой ФС?

Кому это надо? Гарантия целостности пользовательских данных лежит на пользовательских программах, а ФС должна следить только за своей целостностью. Не нравится - храните данные в БД.

Впрочем, в отличие от других ОС в Linux есть костыль на эту тему - опция ext3 data=journal, но лично я считаю это именно костылем, а не полноценным и правильным решением.

>Ну, например, чтобы не было "неготовых" файлов, когда программа вырубится/наткнётся на отсутствие места на диске или другая начнёт писать туда же. Или чтобы рекурсивное удаление каталога выполнилось даже тогда, когда другой процесс активно пишет в него.

неправильная постановка задачи. Вообще надо по возможности обходиться без блокировок, а уж при работе с файлами - тем более. Попробуй представить, что заблокировавшая файл прога подвисла в i/o из-за сбоя сети, например. Догадываешься, что будет? Правильно, получится виндовс :-]

>Не нравится - храните данные в БД.

Для работы с большими файлами неэффективно в плане расхода дискового пространства, памяти и процессорного времени.

>Для работы с большими файлами неэффективно в плане расхода дискового пространства, памяти и процессорного времени.

а в файлах что?

Вы хотите "быстро, дешево и надежно". Так не бывает. Хотите быстро и надежно - покупайте массивы с зеркалированием и автономным источником тока, позволяющим сбросить кэши при аварии. На таком железе обычна файловая система с журналом сохранит Вас на 99.999 от бед.

А быстро и дешево - data=journal на ext3 томе - ваш выбор.