LVM RAID-1 vs. mdadm RAID-1.

Use FreeBSD, Luke! GEOM RAID — и не надо заморачиваться с уровнями.

У меня убунта нормально держала mdraid1+lvm, но я не исключаю что при определённых обстоятельствах это ломается. Дебиан который не хотел в такой конфигурации вставать я видел, вылечилось созданием таблицы разделов с нуля(и переходом с gpt на msdos таблицу разделов).

Зачем LVM, если есть софтовый рейд?

В конечном счете, LVM - всего лишь простой способ добавлять новые винчестеры. Так в софтовом рейде это тоже несложно делается.

LVM снапшоты умеет. И он гораздо гибче растягивается на винты.

> и не надо заморачиваться с уровнями.

?? Я некоторое представление о geom имею, как оно поможет "не заморачиваться с уровнями" если это, по сути, аналог multiple devices в линухе?

gmirror это raid1, gvinum(оно вообще живо?) это raid5, graid3 это raid3 итп.

>LVM снапшоты умеет.

Ждем пока допилят БТРфс?

угу

>?? Я некоторое представление о geom имею, как оно поможет "не заморачиваться с уровнями"

Снапшоты обеспечиваются UFS2 без костылей и подпорок.

>если это, по сути, аналог multiple devices в линухе?

Чего?

>Ждем пока допилят БТРфс?

Ждите.
А у нас уже есть UFS2 и ZFSv13.

> Снапшоты обеспечиваются UFS2 без костылей и подпорок.

А что делать, если снапшоты нужны, а ФС - нет?

ufs2, простите, говно. И на то есть тыща причин(журнал(его отсутствие), ограничение на кол-во директорий в одной папке, роняет ось при малейших повреждениях(как и background fsck) итп).

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

>ufs2, простите, говно.

В каком году в последний раз на неё смотрели|щупали?

>И на то есть тыща причин(журнал(его отсутствие),

Давно есть. gjournal(8) называется.

>ограничение на кол-во директорий в одной папке

Какое ограничение? Почему не знаю?

>, роняет ось при малейших повреждениях

Не припомню случая.
Ext3/Ext4/Reiser — навалом эксцессов.

>(как и background fsck)

Это PROFIT!

>итп).
лолшто

Тесты разных годов: http://alv.me/?cat=26
Сейчас всё намного лучше с появлением SupePages в семёрке.

>По-моему, рановато фряшному zfs в продакшн. Она с него уже может грузиться? А на тачки меньше чем с гигом оперативы уже можно ставить? Все ли фичи оригинальной сановской реализации уже сделаны?

Состояние: http://wiki.freebsd.org/ZFS
В 7-STABLE грузиться уже можно.

>В 7-STABLE грузиться уже можно.
Угу-угу. Через жопу. Читаем внимательно:

zfsboot In progress ...is not possible to boot from ZFS pool.

И в таком состоянии оно уже оооочень давно. А так же рекомендую прочитать http://wiki.freebsd.org/ZFSKnownProblems прежде чем вообще про нее говорить.

> В каком году в последний раз на неё смотрели|щупали?

постоянно

> Давно есть. gjournal(8) называется.

gjournal к файлухе никакого отношения к ufs не имеет вообще.

> Какое ограничение? Почему не знаю?

http://docs.sun.com/app/docs/doc/817-5093/fsfilesysappx-94408?a=view в самом конце. Почему ты не знаешь я не знаю.

> Не припомню случая.

это не значит что так не бывает

> Ext3/Ext4/Reiser — навалом эксцессов.

А я и не говорил что они идеальны

> Это PROFIT!

У тебя просто серверов мало, иначе бы ты бы ты знал к чему это приводит. Можешь поискать, наприер, на nginx-ru что бывает. Ты вообще понимаешь как она чекает на ошибки? Она снапшот чекает а не саму файлуху. И легко может уронить систему.

> Тесты разных годов: http://alv.me/?cat=26

Какие-то старые тесты от Федорчука. Там без gjournal наверняка тестировали.

http://wiki.freebsd.org/ZFSKnownProblems
"ZFS file systems don't start on boot in single-user mode. Symptoms: ZFS file systems are not started / mounted when the machine is booted in single-user mode."

— ZFS не стартует с корня только в Single User Mode. Это вообще не рабочий режим.

>Угу-угу. Через жопу.

В PC-BSD последней версии уже предлагается загружаться с ZFS, и ничего. А по виду целевой аудитории не скажешь, что оно будет эксплуатироваться в идеальных климатических условиях, с UPS'ами и чётко при 25 градусах. :)

Читать лучше свежие новости, а не редко обновляемый Wiki: http://ivoras.sharanet.org/blog/tree/2009-05-21.zfs-v13-in-7-stable.html

P.S.
Так что, Шура, пилите свою Btrfs, пилите. Она — ваша последняя надежда на таких противоречивых линуксах.
http://forum.posix.ru/viewtopic.php?pid=34883#p34883

>http://docs.sun.com/app/docs/doc/817-5093/fsfilesysappx-94408?a=view в самом конце. Почему ты не знаешь я не знаю.

:))
Это САНОВСКАЯ UFS. Никакого отношения в FreeBSD'ной UFS2 она не имеет!
Sun UFS даже не монтируется под FreeBSD.


>Ты вообще понимаешь как она чекает на ошибки? Она снапшот чекает а не саму файлуху. И легко может уронить систему.

Про работу fsck со снапшотом я в курсе. Иначе невозможно было бы fsck работать в фоне. ;)

>Какие-то старые тесты от Федорчука. Там без gjournal наверняка тестировали.

Естественно без журналирования.

Журнал не спасает от пропажи данных (спасает, если журналировать всё, в том числе и данные, в Ext3 это возможно, но с тааааакими тоооормозами). Журнал нужен для быстрого восстановления ФС после сбоя. ВСЁ.
Soft Updates решает задачу восстановления упорядочением операций записи на диск и минимизацией возможных потерь комбинацией синхронных и асинхронных транзакций с носителем. В Linux все дисковые операции асинхронны, поэтому там жизненно необходим журнал транзаций.

> Журнал нужен для восстановления ФС после сбоя.

Исправил.

>У тебя просто серверов мало, иначе бы ты бы ты знал к чему это приводит. Можешь поискать, наприер, на nginx-ru что бывает.

И, да, gjournal и Soft Updates — взаимоисключающие сущности, работать вместе не могут. Поэтому нужно выбирать между отложенным на 15-20 минут восстановлением ФС (в случае использования SU) и восстановлением ФС во время загрузки (в случае с использованием gjournal). В первом случае ждать не надо, пока диски прочекаются и можно работать, терпя некоторые тормоза дисковой подсистемы. Во втором случае придётся ждать завершения fsck, прежде чем приступить к работе.

> Это САНОВСКАЯ UFS.

блин. Это один хрен. Проверь сам на своей тачке если не веришь. Или ищи в гугле. Или открой исходники, увидишь что там short int в качестве счётчика ссылок.

> Журнал нужен для быстрого восстановления ФС после сбоя. ВСЁ.

А это очень хорошая вещь в некоторых ситуациях.

Максимальное количество каталогов в корне — 32768.
Для увеличения этого параметра вдвое используется патч, который заменяет описатель в inode с short int на unsigned int. Но этот патч применять не рекомендуется, так как при использовании в работе большого числа каталогов снижается производительность дисковых операций.

iZEN, я всё это знаю. Я достаточно хорошо знаком с фряшкой. Но слышать от тебя что старая костыльная UFS это "отличная фс" очень странно. Она примитивная, у неё есть ограничения т.к. она слишком давно разрабатывалась итп. А достаточно быстрая она потому примитивная. И я предпочёл бы наличие журнала вместо soft updates. Хотя бы чекаться будет быстрее. А уменьшение фрагментации я от него не заметил.

Однако это не значит что это лучшее решение всех времен и народов. Сравни её с той же zfs. Ну просто небо и земля. Хотя я бы zfs применять не стал бы в силу её дикой прожорливости по cpu и памяти.

>И я предпочёл бы наличие журнала вместо soft updates. Хотя бы чекаться будет быстрее. А уменьшение фрагментации я от него не заметил.

UFS2 разработана в 2002-2003гг. с выходом эксериментальной ветки FreeBSD 5.x.

Фрагментация ФС не превышает 5% за всё время эксплуатации. У меня диск года два уже с еженедельными пересборками системы, и то / — фрагментированность до 3% не доходит (2,8%); /usr/local — 1% фрагментированности, хотя на /usr/local я чего только не делал, одно время держал там временные каталоги компиляции портов.

Попробуй писать на винт сразу в несколько потоков и всё пипец как зафрагментируется.

По поводу "свежести" ufs2. Чем она принципиально отличается от старой ufs? Да ничем. Атрибуты добавили, разрядность каунтеров повысили... И оставили старые болячки типа ограничения на кол-во папок в папке. Это всё мелкие доработки.

>По поводу "свежести" ufs2. Чем она принципиально отличается от старой ufs?
>Атрибуты добавили, разрядность каунтеров повысили...

...ACL's, расширенные атрибуты дополнительные флаги файлов, динамические inode, квоты с мягкими и жёсткими ограничениями, мягкие обновления, моментальные снимки, динамический размер блока вместо экстентов.

Ничего принципиально нового не появилось в 2002 году... :))

Ext4 до сих не может предоставить ВСЁ это в работоспособном состоянии, чтобы её выпустить в продакшен. :)

Квоты уже были. Про динамический размер блоков первый раз слышу, можно ссылочку? Может ли ufs2 содержать несколько снапшотов сразу? Ксати, в man newfs кое-что сказано про экстенты :).

ufs2 и ufs1 на одной кодовой базе сидят.

ext4 это вообще не для продакшена и, на самом деле, это переходной вариант перед btrfs. Я её боюсь использовать.

Ну а так убедил, подлатали чуток файлуху. Но мне она не нравится по тем причинам что я говорил.

>Квоты уже были.

Где?

>Про динамический размер блоков первый раз слышу, можно ссылочку?

Маршал Кирк МакКузик: FreeBSD. Архитектура и реализация

>Может ли ufs2 содержать несколько снапшотов сразу?

Сколько хочешь.

>Ксати, в man newfs кое-что сказано про экстенты :).

В книге тоже приводится сравнение с экстентами из XFS. Называй это как хочешь.

>ufs2 и ufs1 на одной кодовой базе сидят.

Авторы называют цифру 90% общего кода.

>ext4 это вообще не для продакшена и, на самом деле, это переходной вариант перед btrfs.

Теперь уже и не для продакшена. Тогда что для продакшена? Дикофрагментирующиеся Ext3 и JFS?

>Я её боюсь использовать.

Вот-вот. UFS2 тоже боялись использовать, а ведь она тоже эволюционное развитие говна мамонта.

>>Квоты уже были. >Где? В ufs1.

>>Про динамический размер блоков первый раз слышу, можно ссылочку? > Маршал Кирк МакКузик: FreeBSD. Архитектура и реализация

А почему гугл не знает об этом? Зачем тогда в newfs параметр -b?

> Теперь уже и не для продакшена. Тогда что для продакшена? Дикофрагментирующиеся Ext3 и JFS?

Разве я говорил что ext4 в продакшн? Я щас юзаю xfs и jfs. С ext3 по некоторым причинам завязал. Кстати, это хорошо что ты про фрагментацию заговорил, xfs_fsr обещает онлайн-дефрагментацию (пробовать, правда, страшно). А вот для ufs такого нет.

А, собстно, на какую тему мы спорим? Что круче? btrfs, если его допилят. Или jfs под aix. Всё остальное написано слишком давно чтобы содержать весь набор нужных фич либо хавает кучу ресурсов(zfs под фрёй).

>ZFS не стартует с корня только в Single User Mode. Это вообще не рабочий режим.

Ну слава богу, допилили. Остальное вы по этой ссылке проигнорировали, да?

>Так что, Шура, пилите свою Btrfs, пилите. Она — ваша последняя надежда на таких противоречивых линуксах.

Это вы мне говорите? Я буквально вчера "апдейтил" zfs с v6 до v13, очень тоже смешно от zpool получать "zpool internal error out of memory". Тоже мне продакшн блин.

>Зачем тогда в newfs параметр -b?

man newfs
-b block‐size
             The block size of the file system, in bytes.  It must be a power
             of 2.  The default size is 16384 bytes, and the smallest allow‐
             able size is 4096 bytes.  The optimal block:fragment ratio is
             8:1.  Other ratios are possible, but are not recommended, and may
             produce poor results.

- минимальный размер блока. На больших файлах размеры блоков будут увеличиваться, как это посчитает нужным система:
"FreeBSD: Архитектура и реализация", с. 446-447 в русском издании 2006г.:
"Чтобы получить наибольшую эффективность протяженности без неэффективности произвольного доступа, UFS2 добавила в inode поле, которое позволит этому inode использовать больший размер блока. Небольшие, медленно растущие или разбросанные файлы устанавливают в качестве этого значения обычный размер блока файловой системы и представляют свои данные традиционным способом, указанным на рис. 8.37(a). Однако когда файловая система обнаруживает большой, плотный файл, она может установить в этом поле размера блока inode значение, от 2 до 16 раз большее размера блока файловой системы. На рис. 8.37(c) представлен тот же самый набор номеров блоков, как на рис. 8.37(a), с полем размера блока inode в 4 раза большим размера блока файловой системы. Каждый указатель на блок ссылается на участок дискового хранилища, который в четыре раза больше, что уменьшает требования к хранилищу метаданных на 75 процентов. Поскольку указатель на каждый блок, кроме, возможно, последнего, ссылается на блоки одинакового размера, вычисление смещений произвольного доступа так же быстро, как при традиционном представлении метаданных. В отличие от традиционного основанного на экстентах представления, которое может удвоить неободимое для метаданных пространство для определённых наборов данных, это представление всегда ведет к меньшему пространству, выделяемому для метаданных."

>Кстати, это хорошо что ты про фрагментацию заговорил, xfs_fsr обещает онлайн-дефрагментацию (пробовать, правда, страшно). А вот для ufs такого нет.

Потому что в UFS2 используется адресация пространства на уровне фрагментов блоков, фрагментация мала. То есть один не до конца занятый блок одного файла может быть использован для хранения данных другого файла. Кроме того, при создании нового элемента в каталоге операционная система "уплотняет" существующие элементы (почти on-line дефрагментация).

Как я уже говорил, на интенсивных дисковых операциях с созданием и удалением файлов у меня за два года использования UFS2 фрагментировалась не больше чем на 3%.

>Остальное вы по этой ссылке проигнорировали, да?

Что именно?
На Wiki даются только общие представления о ходе работ, но не отражается реальное текущее состояние. (Разработчики просто не успевают вовремя обновить Wiki).

>Это вы мне говорите? Я буквально вчера "апдейтил" zfs с v6 до v13, очень тоже смешно от zpool получать "zpool internal error out of memory". Тоже мне продакшн блин.

По-моему, сервера с 2ГБ и более памяти давно стали уже нормальным явлением. А у кого 1ГБ — это уже не сервер.
Так что память для кэшей ZFS — наипервейшая необходимость, особенно для такой ответственной операции, как преобразование пулов.

А с чего вы взяли, что у меня 1Гб или 2? Или даже 4? У меня их 8, от этого "легче" не становится. Я эту проблему уже решил, но характер у нее такой же, как и по приведенной вами ссылке. Так что не надо на других пенять, ZFS тоже пока далеко не идеал.

Кстати, как будете мир обновлять в "нерабочем режиме" single user mode с zfs, а? :)

>Зачем LVM, если есть софтовый рейд?

>В конечном счете, LVM - всего лишь простой способ добавлять новые винчестеры

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

>Кстати, это хорошо что ты про фрагментацию заговорил, xfs_fsr обещает онлайн-дефрагментацию (пробовать, правда, страшно).

Я многократно использовал :)

http://home.balancer.ru/munin/home/home/xfs_frag.html

Особенно график за год хорошо смотрится :)

Всё по-живому, как на системных разделах, так и на активных p2p.

>Кстати, как будете мир обновлять в "нерабочем режиме" single user mode с zfs, а? :)

Мир давно уже обновляется в нормальном режиме, как и ядро.

> Как я уже говорил, на интенсивных дисковых операциях с созданием и удалением файлов у меня за два года использования UFS2 фрагментировалась не больше чем на 3%.

В пятницу переливал 1млн файлов с пятой фряшки и убедился что ты не прав. Без дефрагментатора рано или поздно придёт время когда при 100% iowait винты будут от силы 2-3мб отдавать.

Чудес не бывает. Бэкап-сервера сильно фрагментированы под любой fs.

> Так что память для кэшей ZFS — наипервейшая необходимость, особенно для такой ответственной операции, как преобразование пулов.

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

Вы представляете хоть, в чем эта операция заключается?

>Вы представляете хоть, в чем эта операция заключается?

Для рекурсивных моментальных снапшотов дерева каталогов со всем содержимым.

UFS2 в FreeBSD нормально стала работать где-то с версии 5.3, но не раньше. Раньше было УГ.

Ну тогда уж с 6-й фри, до этого везде softupdates глючил(место "кончалось").