The OpenNET Project / Index page

[ новости /+++ | форум | теги | ]



"Обновление файловой системы Reiser4 c поддержкой различных т..."
Версия для распечатки Пред. тема | След. тема
Форум Разговоры, обсуждение новостей
Исходное сообщение [ Отслеживать ]
Отдельный RSS теперь доступен для каждого обсуждения в форуме и каждого минипортала.
. "Обновление файловой системы Reiser4 c поддержкой различных т..." –1 +/
Сообщение от Аноним (-), 19-Май-14, 12:21 
> А что такое COW на журналах? :)  Блок пишется либо через журнал,
> либо сразу на новое место на диске (COW).

Это - дeбильная и достаточно известная ситуация, когда некая программа умеет свое кастомное журналирование, не полагающееся на умения ФС и лучше знающее как оно хотело. А тут файловая система начинает "помогать", делая свое журналирование. Вполне может выйти так, что логика процессов не очень хорошо дружит между собой и получается куча лишней работы.

На примере классической транзакционной механики, с допущением что БД и классический журнал были в файлах.
По начальной задумке было так:
1) база пишет намерения в журнал.
2) Намерения коммитятся в основную область.
3) Журнал перетирается (возможно при начале следующей транзакции). Можно делать новую транзакцию.

А теперь допустим что над этим делали CoW...
1) Сначала CoW положит фрагмент по поводу записи в журнал намерений, сделав файлу журнала выносок вбок. Ведь CoW не знал что этот фрагмент нужен лишь на короткое время, а потом - никогда не потребуется.
2) Потом CoW сделает фрагмент "о, файл базы тоже поменяли!". База хотела его in-place воткнуть, но CoW об этом ничего не знал. И вообще это не его собачье дело. Он видит - "файл поменяли". Значит, выносок! С новой версией. Вон туда, вбок.
3) Чистим журнал. Для CoW - "журнал опять поменяли, делаем выносок/пометку в метаданных".

Не кажется что тут получается подозрительно много операций со стороны ФС, которые к тому же превращают файловую систему и файлы в мелкую такую вермишельку и дико загаживают ФС метаданными? На самом деле от ФС хотели всего 2 блочные операции in-place, в журнале и в базе. А вышло вона как.

Эталонный пример: попробуйте взять sqlite и что-нибудь с ним сделать на классической ФС. А теперь положите его на btrfs. Не отключайте для него CoW. И то же самое на btrfs. И как, нравится разница в скорости операций? Ну вот ораклу тоже видимо "нравится" :)

> - и ничего больше нет.

А что, рейзер сможет делать снапшоты после отключения CoW? И это даже будет не тормозно и не криво? Интересно, каким боком? Ну или радости то от "универсального менеджера транзакций", если конечный результат одинаковый? Я не понимаю - как предлагается делать снапшоты без ужасных костылей если CoW не было? В случае выполнения CoW - ну там для создания снапшота все есть, остается только договориться что именно считать за снапшот и пометить это как-то. Но если CoW не было - ничего этого нет. У рейзера сделан какой-то супер-уникальный трюк, обманывающий физику и логику? Мне кажется что так не бывает :).

> Ну, почему это забыть? Наоборот вспомнить! "txmod=wa" - чистое COW, и вот
> они снапшоты, уже просятся :)

Но в режиме обычных транзакций - CoW ведь не будет. И чем это лучше btrfs, в котором такое поведение было на уровне дизайна еще заложено, сколько-то лет назад. Ну, кроме расовой верноты и прочей академической чистоты.

Ответить | Правка | Наверх | Cообщить модератору

Оглавление
Обновление файловой системы Reiser4 c поддержкой различных т..., opennews, 19-Май-14, 10:14  [смотреть все]
Форумы | Темы | Пред. тема | След. тема



Партнёры:
PostgresPro
Inferno Solutions
Hosting by Hoster.ru
Хостинг:

Закладки на сайте
Проследить за страницей
Created 1996-2024 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру