The OpenNET Project / Index page

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



Вариант для распечатки  
Пред. тема | След. тема 
Форум Разговоры, обсуждение новостей
Режим отображения отдельной подветви беседы [ Отслеживать ]

Оглавление

Принято решение использовать в Fedora 16  по умолчанию файло..., opennews (ok), 09-Июн-11, (0) [смотреть все]

Сообщения [Сортировка по времени | RSS]


138. "Принято решение использовать в Fedora 16  по умолчанию файло..."  +/
Сообщение от Аноним (-), 10-Июн-11, 15:25 
> в некоторых тестах быстрее, но там бонусы в другом, это как бы
> аналог ZFS

А зачем в линуксе аналог zfs, если она уже портирована под него?
Те дистры, которым это интересно, сделают сборку модулей через dkms, делов-то. Но вряд ли это примет массовый характер - все-таки zfs больше красивая игрушка, чем рабочий инструмент.
По скорости и живучести она все равно с xfs тягаться не может.

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

162. "Принято решение использовать в Fedora 16  по умолчанию файло..."  +/
Сообщение от Аноним (-), 10-Июн-11, 18:28 
> По скорости и живучести она все равно с xfs тягаться не может.

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


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

175. "Принято решение использовать в Fedora 16  по умолчанию файло..."  +/
Сообщение от Аноним (-), 11-Июн-11, 00:23 
Не надо путать живучесть данных и живучесть фс. cow немного повышает шансы на выживание данных, но если нагнутся метаданные - вытащить данные может оказаться нереально (никто уже не скажет, какому файлу из какого снапшота принадлежит этот экстент).

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

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

192. "Принято решение использовать в Fedora 16  по умолчанию файло..."  +/
Сообщение от Аноним (-), 11-Июн-11, 10:21 
> Не надо путать живучесть данных и живучесть фс.

Одно несколько взаимосвязано с другим. Путать - не стоит.

> cow немного повышает шансы на выживание данных, но если нагнутся метаданные
> - вытащить данные может оказаться нереально (никто уже не скажет,
> какому файлу из какого снапшота принадлежит этот экстент).

Ну, если так рассуждать, если нагнутся метаданные описывающие выделение блоков, никто не сможет понять к какому файлу относится вон тот блок.

Я про чуть иные случаи. Например для ZFS довольно типично совсем не осиливать монтирование тома + крешиться в сервисных утилях при минимальном повреждении метаданных. Это довольно плохое свойство ФС означающее что при малейшем сбое и отсутсвии бэкапа, вы пойдете в хексэдитор, парсить навернутые структуры самолично вместо облажавшегося это сделать кода драйвера/утилит.

> Разработчики XFS решили этот вопрос радикально - открытые на запись в момент
> сбоя файлы заполняются нулями (этим данным кабздец, да), но зато метаданные
> всегда в строгом порядке

В последних версиях столь мерзкое поведение устранили более-менее по дефолту. Но с точки зрения пользователя, метаданные ФС вообще не нужны. А вот засранные нулями файлы - это жесть.

> - в результате гарантированно выживают остальные файлы,
> так что в итоге живучесть данных тоже оказывается на уровне.

Сомнительное преимущество. В случае btrfs CoW применяется и к данным и к метаданным, при обычном крахе такой подход вообше неубиваем: всегда можно просто выбросить недописанные хвосты и получить фс просто в чуть более старом состоянии. Когда данные и метаданные синхронизированы и логически не противоречивы. Реальные проблемы будут если как-то порушатся какие-то старые метаданные/данные (дозапись файла их не разрушает, с этим то как раз нет проблем). Что возможно например при вылезании бэдсектора, сбоях железа и т.п.. Хотелось бы чтобы fsck мог бы разрулить вот такие ситуации, перестроив побитые метаданные на основе иных метаданных, или хотя-бы нейтрализуя заведомо некорректные/проблемные метаданные дабы привести том в монтируемое состояние когда с него что-то можно закопировать.

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

199. "Принято решение использовать в Fedora 16  по умолчанию файло..."  +/
Сообщение от Аноним (-), 11-Июн-11, 14:27 
> Сомнительное преимущество. В случае btrfs CoW применяется и к данным и к
> метаданным, при обычном крахе такой подход вообше неубиваем

Напомню, что лазить по ZFS с hexeditor-ом приходится именно из-за того, что там к метаданным применяется cow. Думаю, у btrfs будет то же самое.
Хотя в zpool v28 эту проблему уже устранили (при импорте можно указать руками версию метаданных).

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

Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема




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

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