Reiser FS

[Alexander]

Не знал.

[debi12345]

Не знал.
================
Точнее - не сталкивались по серьезному.

У меня стоит Reiser4 на одном из логических дисков сервера - где спулер мэйл-сервера, и где бэкап репликации ( не слишком ответственный участок ). В бэкапе - тысячи файлов, и именна эта ФС позволят быстро ( без бесящих задержек ) работать с этим каталогом (через MidnightCommander ) .

[unC0Rr]

debi12345: ФС в принципе не может поддерживать целостность данных в файле, поскольку для этого нужно хоть что-то знать о структуре данных, так что Ваши сведения о чудесных возможностях ext3 не совпадают с реальностью

[debi12345]

debi12345: ФС в принципе не может поддерживать целостность данных в файле, поскольку для этого нужно хоть что-то знать о структуре данных, так что Ваши сведения о чудесных возможностях ext3 не совпадают с реальностью

Ext3 делает открывает/подтверждает/откатывает транзакции, как и БД-сервера (которые тоже не знают о структуре.)

[shade]

debi12345
Не убедил

[Sergei I. Gorelkin]

У файловой системы RT-11 было чудесное свойство: записывать новый файл не поверх старого, а на пустое место. Старый файл удалялся (из каталога) только после успешной записи нового. Таким образом, любой сбой (а их в эпоху дискет было достаточно) убивал максимум последние изменения, потерять файл совсем было практически невозможно. Ни о каком журналировании, естественно, даже речь не шла...
Позже, когда появилась ms-dos (а дискеты еще никуда не девались и все так же глючили), я просто поражался, почему в ней сделано все наоборот: сначала удаляется старый файл, потом начинает записываться новый. Да, это позволяет эффективнее использовать пустое место, но...
Так что все новое - хорошо забытое старое

[debi12345]

debi12345
Не убедил

А я и не ставил такой цели - просто дал информацию к сведению, как человек, о-о-чень конкретно ( вплоть до экспериментов ) изучивший данный вопрос.
Есть журналирование секторов контента файлов (Ext3), и журналирование секторов метаданных { каталожных структур } ( остальные ФС ) .

[unC0Rr]

debi12345: ФС в принципе не может поддерживать целостность данных в файле, поскольку для этого нужно хоть что-то знать о структуре данных, так что Ваши сведения о чудесных возможностях ext3 не совпадают с реальностью

Ext3 делает открывает/подтверждает/откатывает транзакции, как и БД-сервера (которые тоже не знают о структуре.)

Как раз БД знают о структуре Этим БД и отличаются от ФС с файлами. Иначе не стоило бы придумывать такую сущность как БД.
Простой пример: в текстовый файл записываются числа тройками, каждое число в отдельном вызове write, если в файле кол-во чисел не делится на три - файл битый. Я записываю в непустой файл одно число, затем второе, третье, четвёртое, пятое, затем питание вырубается. Как ФС мне обеспечит целостность данных (в данном случае кол-во чисел должно делиться на три)? Откатит две записи? Пять записей? Почему не четыре?
Другой пример - в файле есть таблица смещений каких-то структур (по сути аналог ФС), происходит удаление/добавление структуры несколькими вызовами аналогично таковым операциям, допустим, на ФАТ32.... Что будет делать ФС при отказе на каком-либо этапе? Максимум, на что она способна - поддержать свою целостность и непротиворечивость.

[debi12345]

Как ФС мне обеспечит целостность данных (в данном случае кол-во чисел должно делиться на три)? Откатит две записи? Пять записей? Почему не четыре?
=============
Ну вы тоже захотели... Транзакции ФС - на уровне секторов (по 512 байт). ФС гарантирует, что, после сбоя записи, таблица БД как минимум откроется (так как сохранит неповрежденную структуру) - с данными на момент сбоя. Кстати, и сервера БД, когда сбрасывают транзакции на диск - о данных ничего не думают, а тупо манипулируют "страницами" и похожими "единицами измерения". При сбое, ФС откатывает изменение ао журналу и возвращает ОС сообщение об ошибке. Сервер БД по этому сообщению откатывает уже свою транзакцию ( знающую о структуре данных, возможно касающуюся нескольких таблиц, а не только сбойной ) .

[unC0Rr]

Ну здрасти....
1) Транзакции ФС - далеко не на уровне секторов Если дописать в конец файла данные и изменить запись о размере файла - это уже минимум два сектора.
2) Чем таблица БД отличается от моей таблицы в текстовом файле? Как ФС знает о структуре таблиц БД? В БД аналогичным образом длина таблицы и данные таблицы находятся в разных секторах - ФС не может, не зная о структуре файла, поддерживать его целостность.
3) Не подскажешь каким системным вызовом СУБД может узнать о сбое в ФС? Заметь, в твоей схеме целостность БД поддерживает всё-таки СУБД, а не ФС.
4) Что, если умная ФС откатит сектор БД, содержащий журнал транзакций?

[debi12345]

) Не подскажешь каким системным вызовом СУБД может узнать о сбое в ФС? Заметь, в твоей схеме целостность БД поддерживает всё-таки СУБД, а не ФС.
==============
Насколько помню, API сервера, при РЕАЛЬНОМ сохранении данных, вызывает FSYNC ( и проверят код ошибки ) - которая пишет сразу "страницу" БД ( занимающую много секторов на диске - настраивается при запуске сервера ). При сбое откатываются эти "много секторов" - так разводится ваш текстовый файл (ваш редактор вызовет аналогичное APi по команде Save).

Что Вы волнуетесь ? Америка уже давно уже открыта. Конечно, эти вопросы уже 100 лет как продуманы и реализованы. Иначе падали бы сервера от каждого чиха. ReiserN, JFS, XFS делают транзакции разметки=метаданных ( миниатюрный быстро-проигрывемый журнал ). Ext3 - в дополнение к разметке, делает и транзакции данных (журнал неслабый бывает ).

ПС:
Попробуйте записать большую транзакцию из новых данных на сыпящийся (или забитый на 100%) винт. С высокой вероятность вся транзакция не прокатит.

Люблю я ReiserFS, люблю. И использую там, где не страшно потерять данные, но нужный быстрый поиск в мелких файлах. Даже не поленился перчитать кучу доки, собрать и модули, и утиллиты ( из исходников с NAMESYS ). Но в резведку с ReiserFS не пошел бы...

[unC0Rr]

Насколько помню, API сервера, при РЕАЛЬНОМ сохранении данных, вызывает FSYNC ( и проверят код ошибки )

Вот, уже ближе к делу. Да, СУБД обеспечивает целостность БД при помощи поддержания файла в синхронизированном состоянии, при этом тип ФС (журналируемая или нет) не имеет значения. Аналогичным образом ФС обеспечивает целостность своих данных, к которым относится информация о каталогах и файлах, но не о содержимом файла. Обычно текстовый реадактор не делает sync, ни к чему ему это. Да и моя самописная программа не станет Потерять данные на ext3 так же реально, как и на рейзере, на xfs, ntfs, и прочем.

ПС. Сыпящийся винт не в тему, против него никакая ФС не поможет

[shade]

Да, СУБД обеспечивает целостность БД при помощи поддержания файла в синхронизированном состоянии, при этом тип ФС (журналируемая или нет) не имеет значения.

Имеет: если файл БД окажется поврежденным (например, в FAT будет обрыв цепочки кластеров) или вообще потеряется, то СУБД ничего сделать не сможет.

[unC0Rr]

Да, СУБД обеспечивает целостность БД при помощи поддержания файла в синхронизированном состоянии, при этом тип ФС (журналируемая или нет) не имеет значения.

Имеет: если файл БД окажется поврежденным (например, в FAT будет обрыв цепочки кластеров) или вообще потеряется, то СУБД ничего сделать не сможет.

Да, но файл может потеряться и у журналируемой ФС! Если же размер файла БД не меняется, то тип не имеет значения. Да, конечно, журналируемость немного поможет, но никакая ext3 не обеспечит полной надёжности.

[debi12345]

ext3 так же реально, как и на рейзере, на xfs, ntfs, и прочем.
==============
Reiser&Co может обнулить ( zero-size ) огромный файл ( например, всю БД ) из-за одного сбойного сектора ! И радостно прописать до освободившемуся месту. Потом ни одной утиллитой не вытащищь.

Сыпящийся винт не в тему, против него никакая ФС не поможе
================
У нас 10...20 таких машин. Ничего, вынуждены работать, из-за соображений окупаемости техники - БИОСы не понимают размер больше 2G,приходится брать жуткое старье . Преимущество Ext3 здесь (не обнулять фалы БД ни при каких условиях ) - чувствуется в полной мере.