Если даже и страшно (с lvm2) (хотя, не понимаю, почему?), то с ZFS - на порядок страшнее:)

"believe" не только "верить"

например ядро :)

http://www.theregister.co.uk/2009/09/14/freebsd_security_bug/

> It affects versions 6.0 through 6.4 of the operating system. <...> Versions 7.1 and and beyond are not vulnerable.

ahaha oh wow

Официального и полномасштабного как у RedHat — нет. Собственно, сие есть основное „препятствие“ для пользования xBSD в Ънтерпрайзе™ — ибо в ситуации „амба продакшн-серверу“ спрашивать не с кого.

<troll> за что ненавидишь девушку? </troll>

Уверен что девушке? Может быть нелюбимой теще? ^_^

Скажи честно, как ты ей объясняешь почему у подруг виста а у нее это?

btrfs поможет тебе.

Исче один ниасилятор, нужны снапшоты - юзай btrfs

Он просто за нее берет

Известно, что новая уязвимость стала результатом продолжения работы по представленному в августе эксплоиту, демонстрирующему проблемы в реализации системного вызова kevent ("race condition"), проявляющиеся на многопроцессорных системах для старых версий FreeBSD и исправленных в релизе 6.2.

По словам Пржемыслава уведомление команде FreeBSD было направлено еще 29 августа, но сообщение об исправлении пока не поступало.

;

Один диск сейчас проверить не могу - вся система поставлена на этот гигантский zfs-пул и дисков больше нету.

т.е. можно закапывать?

во-первых, 7.2 тоже дырява (здесь надо не лениться тыкать по ссылкам) во-вторых, 6.3 и 6.4 еще никто не отменял; или вы думаете, что весь мир обновляется в день выхода нового релиза? ошибаетесь, перманентные апдейты - удел красноглазиков с кучей свободного времени.

Она дырява как решето, почитай opennet

Плохо, конечно.

> В догонку: почему никто не прикрутит её к ядру лялиха (понятное дело, в ванильное не попадёт, - cddl всё же, но кому-то плевать на лицензии)?

Копай FUSE. Зачем тебе тащить ее в ядро?

А о чем речь? О журнале зеркала? Так его можно на диске не хранить, делов-то.

У зеркала на LVM2 совсем другие проблемы, если что.

Поверь, до файловой системы c lvm-функциональностью доберешься, но лучше тебе от этого не станет..

Переводится как: мы ВЕРУЕМ, ZFS уже готова к продакшену.

О! Наверное, ты еще и знаешь - кто сильнее, кит или слон?

Первое

Мне как-то параллельно кто и что видел, но "особенности" зеркалирования в lvm есть - речь о механизмах чтения и записи на половинки зеркала. Эти механизмы сильно отличаются от md-raid. Это раз. А два состоит в том, что lvm не очень безопасен в случае сбоев по питанию. Т.е. он не так сильно парится целостностью данных прописанных в журнал и на половинки зеркала, ну и собственно последовательностью записи. Есть мнение что lvm пофигу на барьеры, а значит теоретически можно развалить файловую систему поверх lvm.

А кто безопасен? Может быть более или менее, но если нет батарейки, то можно только выбирать, что лучше в каждом конкретном случае.

> Есть мнение что lvm пофигу на барьеры, а значит теоретически можно развалить файловую систему поверх lvm.

Данной фразы не понял. Можно поподробнее?

А ты почему-то начал сравнивать _программный_ LVM с _аппаратным_ RAID.

А ты почему-то начал сравнивать _программный_ LVM с _аппаратным_ RAID.

Не начал. Я дополнил достоинства raid в проблеме отказоустойчивости примером хардварного рэйда. На этом закончим. Я ж за простоту, чем проще системы, тем надежнее)

raid, который может быть одной микросхемкой на плате

iZEN, а почему тогда у меня на 8.0BETA4 с таким вот ...

loader.conf:
vfs.root.mountfrom="zfs:tank"
hw.mpt.enable_sata_wc=1
vm.kmem_size_max="1024M"
vm.kmem_size="1024M"
vfs.zfs.arc_max="100M"
vfs.zfs.prefetch_disable=1
vfs.zfs.zil_disable=0
vfs.zfs.cache_flush_disable=1
vfs.zfs.arc_max="448M"

sysctl.conf:
kern.maxvnodes=400000

— не нужно.

>> Данной фразы не понял. Можно поподробнее?

>В целях повышения отказоустойчивости применяют Write Barriers, нечто отдаленно напоминающее транзакции на уровне железа. Это снижает скорость записи, но значительно снижает вероятность повреждения ФС и потери данных при отказе оборудования. LVM не совместим с барьерами.

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

http://lwn.net/Articles/283161/

ЗЫ Зато LVM быстро работает ;)

Не, это я в курсе, тут такие войны были по поводу того, какое поведение системы есть правильное :) Там и барьеры обсуждались :), тут тоже хорошо и понятно описано их применение и важность: http://lwn.net/Articles/283161/ (если кому интересно).

Но!

Барьеры - штука иногда полезная, но использовать их можно только либо на 1 конкретном приводе, либо на нескольких, которые работают как один - зеркало.

Quick search:

http://hightechsorcery.com/2008/06/linux-write-barriers-write-caching-lvm-and...

> That means you cannot use write barriers with dm-raid, dm-crypt, or LVM. You also cannot use it with md-raid except for RAID 1.

Несовместим с барьерами, но область применения барьеров крайне мала. Без батарейки гарантий не будет, редко где на интенсивном В/В используют RAID 1, больше RAID 5/6 или 0+1. А барьеры важны именно для интенсивного В/В, проблемы без них именно на таких тестах показывались.

Меня обогнали :(

Медленно набираю, наверное.

Та же ссылка, те же аргументы