Reiser FS
Модератор: Модераторы
-
debi12345
- долгожитель
- Сообщения: 5761
- Зарегистрирован: 10.05.2006 23:41:15
- Откуда: Ташкент (Узбекистан)
Не знал.
================
Точнее - не сталкивались по серьезному.
У меня стоит Reiser4 на одном из логических дисков сервера - где спулер мэйл-сервера, и где бэкап репликации ( не слишком ответственный участок ). В бэкапе - тысячи файлов, и именна эта ФС позволят быстро ( без бесящих задержек ) работать с этим каталогом (через MidnightCommander ) .
================
Точнее - не сталкивались по серьезному.
У меня стоит Reiser4 на одном из логических дисков сервера - где спулер мэйл-сервера, и где бэкап репликации ( не слишком ответственный участок ). В бэкапе - тысячи файлов, и именна эта ФС позволят быстро ( без бесящих задержек ) работать с этим каталогом (через MidnightCommander ) .
-
debi12345
- долгожитель
- Сообщения: 5761
- Зарегистрирован: 10.05.2006 23:41:15
- Откуда: Ташкент (Узбекистан)
unC0Rr писал(а):debi12345: ФС в принципе не может поддерживать целостность данных в файле, поскольку для этого нужно хоть что-то знать о структуре данных, так что Ваши сведения о чудесных возможностях ext3 не совпадают с реальностью
Ext3 делает открывает/подтверждает/откатывает транзакции, как и БД-сервера (которые тоже не знают о структуре.)
-
shade
- энтузиаст
- Сообщения: 879
- Зарегистрирован: 21.02.2006 19:15:48
- Откуда: http://shamangrad.net/
- Контактная информация:
-
Sergei I. Gorelkin
- энтузиаст
- Сообщения: 1409
- Зарегистрирован: 24.07.2005 14:40:41
- Откуда: Зеленоград
У файловой системы RT-11 было чудесное свойство: записывать новый файл не поверх старого, а на пустое место. Старый файл удалялся (из каталога) только после успешной записи нового. Таким образом, любой сбой (а их в эпоху дискет было достаточно) убивал максимум последние изменения, потерять файл совсем было практически невозможно. Ни о каком журналировании, естественно, даже речь не шла...
Позже, когда появилась ms-dos (а дискеты еще никуда не девались и все так же глючили), я просто поражался, почему в ней сделано все наоборот: сначала удаляется старый файл, потом начинает записываться новый. Да, это позволяет эффективнее использовать пустое место, но...
Так что все новое - хорошо забытое старое
Позже, когда появилась ms-dos (а дискеты еще никуда не девались и все так же глючили), я просто поражался, почему в ней сделано все наоборот: сначала удаляется старый файл, потом начинает записываться новый. Да, это позволяет эффективнее использовать пустое место, но...
Так что все новое - хорошо забытое старое
debi12345 писал(а):unC0Rr писал(а):debi12345: ФС в принципе не может поддерживать целостность данных в файле, поскольку для этого нужно хоть что-то знать о структуре данных, так что Ваши сведения о чудесных возможностях ext3 не совпадают с реальностью
Ext3 делает открывает/подтверждает/откатывает транзакции, как и БД-сервера (которые тоже не знают о структуре.)
Как раз БД знают о структуре
Этим БД и отличаются от ФС с файлами. Иначе не стоило бы придумывать такую сущность как БД.
Простой пример: в текстовый файл записываются числа тройками, каждое число в отдельном вызове write, если в файле кол-во чисел не делится на три - файл битый. Я записываю в непустой файл одно число, затем второе, третье, четвёртое, пятое, затем питание вырубается. Как ФС мне обеспечит целостность данных (в данном случае кол-во чисел должно делиться на три)? Откатит две записи? Пять записей? Почему не четыре?
Другой пример - в файле есть таблица смещений каких-то структур (по сути аналог ФС), происходит удаление/добавление структуры несколькими вызовами аналогично таковым операциям, допустим, на ФАТ32.... Что будет делать ФС при отказе на каком-либо этапе? Максимум, на что она способна - поддержать свою целостность и непротиворечивость.
-
debi12345
- долгожитель
- Сообщения: 5761
- Зарегистрирован: 10.05.2006 23:41:15
- Откуда: Ташкент (Узбекистан)
Как ФС мне обеспечит целостность данных (в данном случае кол-во чисел должно делиться на три)? Откатит две записи? Пять записей? Почему не четыре?
=============
Ну вы тоже захотели... Транзакции ФС - на уровне секторов (по 512 байт). ФС гарантирует, что, после сбоя записи, таблица БД как минимум откроется (так как сохранит неповрежденную структуру) - с данными на момент сбоя. Кстати, и сервера БД, когда сбрасывают транзакции на диск - о данных ничего не думают, а тупо манипулируют "страницами" и похожими "единицами измерения". При сбое, ФС откатывает изменение ао журналу и возвращает ОС сообщение об ошибке. Сервер БД по этому сообщению откатывает уже свою транзакцию ( знающую о структуре данных, возможно касающуюся нескольких таблиц, а не только сбойной ) .
=============
Ну вы тоже захотели... Транзакции ФС - на уровне секторов (по 512 байт). ФС гарантирует, что, после сбоя записи, таблица БД как минимум откроется (так как сохранит неповрежденную структуру) - с данными на момент сбоя. Кстати, и сервера БД, когда сбрасывают транзакции на диск - о данных ничего не думают, а тупо манипулируют "страницами" и похожими "единицами измерения". При сбое, ФС откатывает изменение ао журналу и возвращает ОС сообщение об ошибке. Сервер БД по этому сообщению откатывает уже свою транзакцию ( знающую о структуре данных, возможно касающуюся нескольких таблиц, а не только сбойной ) .
Ну здрасти....
1) Транзакции ФС - далеко не на уровне секторов Если дописать в конец файла данные и изменить запись о размере файла - это уже минимум два сектора.
2) Чем таблица БД отличается от моей таблицы в текстовом файле? Как ФС знает о структуре таблиц БД? В БД аналогичным образом длина таблицы и данные таблицы находятся в разных секторах - ФС не может, не зная о структуре файла, поддерживать его целостность.
3) Не подскажешь каким системным вызовом СУБД может узнать о сбое в ФС? Заметь, в твоей схеме целостность БД поддерживает всё-таки СУБД, а не ФС.
4) Что, если умная ФС откатит сектор БД, содержащий журнал транзакций?
1) Транзакции ФС - далеко не на уровне секторов
Если дописать в конец файла данные и изменить запись о размере файла - это уже минимум два сектора.
2) Чем таблица БД отличается от моей таблицы в текстовом файле? Как ФС знает о структуре таблиц БД? В БД аналогичным образом длина таблицы и данные таблицы находятся в разных секторах - ФС не может, не зная о структуре файла, поддерживать его целостность.
3) Не подскажешь каким системным вызовом СУБД может узнать о сбое в ФС? Заметь, в твоей схеме целостность БД поддерживает всё-таки СУБД, а не ФС.
4) Что, если умная ФС откатит сектор БД, содержащий журнал транзакций?
-
debi12345
- долгожитель
- Сообщения: 5761
- Зарегистрирован: 10.05.2006 23:41:15
- Откуда: Ташкент (Узбекистан)
) Не подскажешь каким системным вызовом СУБД может узнать о сбое в ФС? Заметь, в твоей схеме целостность БД поддерживает всё-таки СУБД, а не ФС.
==============
Насколько помню, API сервера, при РЕАЛЬНОМ сохранении данных, вызывает FSYNC ( и проверят код ошибки ) - которая пишет сразу "страницу" БД ( занимающую много секторов на диске - настраивается при запуске сервера ). При сбое откатываются эти "много секторов" - так разводится ваш текстовый файл (ваш редактор вызовет аналогичное APi по команде Save).
Что Вы волнуетесь ? Америка уже давно уже открыта. Конечно, эти вопросы уже 100 лет как продуманы и реализованы. Иначе падали бы сервера от каждого чиха. ReiserN, JFS, XFS делают транзакции разметки=метаданных ( миниатюрный быстро-проигрывемый журнал ). Ext3 - в дополнение к разметке, делает и транзакции данных (журнал неслабый бывает ).
ПС:
Попробуйте записать большую транзакцию из новых данных на сыпящийся (или забитый на 100%) винт. С высокой вероятность вся транзакция не прокатит.
Люблю я ReiserFS, люблю. И использую там, где не страшно потерять данные, но нужный быстрый поиск в мелких файлах. Даже не поленился перчитать кучу доки, собрать и модули, и утиллиты ( из исходников с NAMESYS ). Но в резведку с ReiserFS не пошел бы...
==============
Насколько помню, API сервера, при РЕАЛЬНОМ сохранении данных, вызывает FSYNC ( и проверят код ошибки ) - которая пишет сразу "страницу" БД ( занимающую много секторов на диске - настраивается при запуске сервера ). При сбое откатываются эти "много секторов" - так разводится ваш текстовый файл (ваш редактор вызовет аналогичное APi по команде Save).
Что Вы волнуетесь ? Америка уже давно уже открыта. Конечно, эти вопросы уже 100 лет как продуманы и реализованы. Иначе падали бы сервера от каждого чиха. ReiserN, JFS, XFS делают транзакции разметки=метаданных ( миниатюрный быстро-проигрывемый журнал ). Ext3 - в дополнение к разметке, делает и транзакции данных (журнал неслабый бывает ).
ПС:
Попробуйте записать большую транзакцию из новых данных на сыпящийся (или забитый на 100%) винт. С высокой вероятность вся транзакция не прокатит.
Люблю я ReiserFS, люблю. И использую там, где не страшно потерять данные, но нужный быстрый поиск в мелких файлах. Даже не поленился перчитать кучу доки, собрать и модули, и утиллиты ( из исходников с NAMESYS ). Но в резведку с ReiserFS не пошел бы...
debi12345 писал(а):Насколько помню, API сервера, при РЕАЛЬНОМ сохранении данных, вызывает FSYNC ( и проверят код ошибки )
Вот, уже ближе к делу. Да, СУБД обеспечивает целостность БД при помощи поддержания файла в синхронизированном состоянии, при этом тип ФС (журналируемая или нет) не имеет значения. Аналогичным образом ФС обеспечивает целостность своих данных, к которым относится информация о каталогах и файлах, но не о содержимом файла. Обычно текстовый реадактор не делает sync, ни к чему ему это. Да и моя самописная программа не станет
Потерять данные на ext3 так же реально, как и на рейзере, на xfs, ntfs, и прочем.
ПС. Сыпящийся винт не в тему, против него никакая ФС не поможет
-
shade
- энтузиаст
- Сообщения: 879
- Зарегистрирован: 21.02.2006 19:15:48
- Откуда: http://shamangrad.net/
- Контактная информация:
unC0Rr писал(а):Да, СУБД обеспечивает целостность БД при помощи поддержания файла в синхронизированном состоянии, при этом тип ФС (журналируемая или нет) не имеет значения.
Имеет: если файл БД окажется поврежденным (например, в FAT будет обрыв цепочки кластеров) или вообще потеряется, то СУБД ничего сделать не сможет.
shade писал(а):unC0Rr писал(а):Да, СУБД обеспечивает целостность БД при помощи поддержания файла в синхронизированном состоянии, при этом тип ФС (журналируемая или нет) не имеет значения.
Имеет: если файл БД окажется поврежденным (например, в FAT будет обрыв цепочки кластеров) или вообще потеряется, то СУБД ничего сделать не сможет.
Да, но файл может потеряться и у журналируемой ФС! Если же размер файла БД не меняется, то тип не имеет значения. Да, конечно, журналируемость немного поможет, но никакая ext3 не обеспечит полной надёжности.
-
debi12345
- долгожитель
- Сообщения: 5761
- Зарегистрирован: 10.05.2006 23:41:15
- Откуда: Ташкент (Узбекистан)
ext3 так же реально, как и на рейзере, на xfs, ntfs, и прочем.
==============
Reiser&Co может обнулить ( zero-size ) огромный файл ( например, всю БД ) из-за одного сбойного сектора ! И радостно прописать до освободившемуся месту. Потом ни одной утиллитой не вытащищь.
Сыпящийся винт не в тему, против него никакая ФС не поможе
================
У нас 10...20 таких машин. Ничего, вынуждены работать, из-за соображений окупаемости техники - БИОСы не понимают размер больше 2G,приходится брать жуткое старье . Преимущество Ext3 здесь (не обнулять фалы БД ни при каких условиях ) - чувствуется в полной мере.
==============
Reiser&Co может обнулить ( zero-size ) огромный файл ( например, всю БД ) из-за одного сбойного сектора ! И радостно прописать до освободившемуся месту. Потом ни одной утиллитой не вытащищь.
Сыпящийся винт не в тему, против него никакая ФС не поможе
================
У нас 10...20 таких машин. Ничего, вынуждены работать, из-за соображений окупаемости техники - БИОСы не понимают размер больше 2G,приходится брать жуткое старье . Преимущество Ext3 здесь (не обнулять фалы БД ни при каких условиях ) - чувствуется в полной мере.