на вопрос: "что лучше - жёлтое или сладкое", был дан адекватный вопросу ответ.

>Я ж за простоту, чем проще системы, тем надежнее)

для начальной школы можно считать утверждение верным. Но кроме арифметики существет ещё алгебра, "вышка" и т.д.:)

Прошу прощения, посмотрел исходники ядра, raid10 поддерживает барьеры, это я погорячился.

Дальше (в старших классах) оказывается, что утверждение "чем проще системы, тем надежнее" ДАЛЕКО не всегда верно.

hmmm.... А ведь действительно, судя по кодам ядра LVM (dm) транслирует все barrier вызовы на уровень ниже, хотя сам их не реализует особо (обвёртка функций есть, значит хоть частично, но реализованы).

Пруфлинк никто не встречал? Быстрый поиск не помог, дальше ломы :)

fixed

>Пруфлинк никто не встречал? Быстрый поиск не помог, дальше ломы :)

А есть исходники под рукой? Покажите свежий drivers/md/dm.c про dm_request

Я понял, что там тупо все отрубают - мол not supported.

Bebop

Я понял, что там тупо все отрубают - мол not supported.

Не, в том то и дело:

       /*
         * If we're suspended or the thread is processing barriers
         * we have to queue this io for later.
         */
        if (unlikely(test_bit(DMF_QUEUE_IO_TO_THREAD, &md->flags)) ||
            unlikely(bio_barrier(bio))) {
                up_read(&md->io_lock);

                if (unlikely(test_bit(DMF_BLOCK_IO_FOR_SUSPEND, &md->flags)) &&
                    bio_rw(bio) == READA) {
                        bio_io_error(bio);
                        return 0;
                }
                
                queue_io(md, bio);

                return 0;
        }

Ну и сам request транслирует ниже всё:

static int dm_request(struct request_queue *q, struct bio *bio)
{
        struct mapped_device *md = q->queuedata;
                
        if (dm_request_based(md))
                return dm_make_request(q, bio);
                        
        return _dm_request(q, bio);
}               

> Я понял, что там тупо все отрубают - мол not supported.

в RAID5, что у меня используется. Под LVM :)

Так что я особо LVM и не смотрел на предмет барьеров.

Вы часто сидите за физичекой консолью ?

Сам нашёл :)

http://bugzilla.kernel.org/show_bug.cgi?id=9554#c12

> As of 2.6.31-rc1, write barriers are supported by most device-mapper targets.

> (Just dm-raid1 and dm-mpath still need finishing.)

http://en.wikipedia.org/wiki/LWM

А я доставал данные с дисков после глюка мегарейда (HP NetRAID) - контроллер такой, со своей памаятью-процессором-батарейкой, весь такой SAS и SCSI. Так вот - не удалось спасти ни одного файла длиннее 64 килобайт. Так что не надо нам тут про хардварные рейды и отказоустойчивость :-)

Из какой части статьи это следует? По-моему у Вас проблемы с логическим мышлением :(

>http://bugzilla.kernel.org/show_bug.cgi?id=9554#c12

Здорово, dm развивается однако! Хоть и баг не закрыт полностью.

ЗЫ У меня правда таких новых ядер нет (ни 29, ни 31). Так что подождем новых версий дистрибутива.

А что не так? LVM -- он для управления разделами, md -- для создания рейда. Подумай, какая пляска с бубном будет, если создать сначала raid0 средствами lvm (т.е. striped), а потом ввести в ту же группу томов просто еще один диск (например, дя выполнения миграции raid0 -> raid1)

md raid1 исключение. А мы ведь говорим о правильной избыточности?

/громкий смех в зале/ Похоже они это делают плохо или их мало, т.к. d9d9 жив пока...

Аргументы будут? Выше уже написали, что эти инструменты решают разные задачи. Usecase придумать нетрудно.

Очевидно, что городить огород и умножать сущности не нужно, но если "вдруг и все же", то в каком месте сломается? Мне интересно, т.к. я так не делал и готов выслушать мнение гуру.

FreeBSD в составе промышленности: готово к продакшену

>Вот снапшоты на уровне файловой системы - это вкуснее, чем на уровне блочного устройства.

Вкуснее. Но вот завалился у меня как-то lvm2. Я пробовал его поднять стандартными средствами, нестандартными, перечитал за пару дней кучу документации - нихрена не поднялось. Хорошо, что настроены бэкапы и все важное сохранилось.

Что одно и то же, т.е. это их мнение. Они говорят - мы считаем, что система готова к примененю в промышленности. Верят они, или считают - это все лишь их мнение. И данный чудесный глагол либо действительно говорит "я верю", либо говорит "знаете, я думаю, что вот так, а вы как считаете?".

У меня есть такая файлопомойка. Года три назад один винт сдох. Все умерло. :)

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

Не делала. Но так делает Ubuntu - по умолчанию все попадает в lvm.

Интересно, кто-нить тут слышал о том, что английский язык является контекстно-зависимым или только словари читали из-под палки в институте?

У него есть... СЕРТИФИКАЦИЯ!

Оно еще не стабилизировалось.

А по-моему, что та, что другая -- пример, как НЕ надо делать, может только снэпшоты по делу. Впрочем, поживем - увидим.

>md общается только с device-mapper, который барьеры не умеет. Каким образом работает исключение?

Тебе выдержку из сорцов? Может стоит для начала набрать в гугле "md raid 1 write barrier" и понять, что оно таки работало. В 29 ядре сломали, но сейчас вроде чинят. А еще в сети пачка тестов где md raid1 сливает зеркалу lvm именно по этой причине.

>> А мы ведь говорим о правильной избыточности?

>Так какая бабка тебе сказала что в md избыточность правильнее?

Я всего лишь говорил о зеркале, а не о всяких raid5 или еще каких вариациях.

>Помоему это задача одного уровня. Появление zfs и btrfs тому подтверждение.

Массам захотелось чтоб было все и сразу - это модный тренд на упрощение. Вот только я считаю, делать монолитные решения типа zfs это не самый лучший вариант. Идеология VxVM+VxFS мне как-то ближе - функционал тот же, но сущности разделены и прекрасно живут отдельно, если что.

кому как не мейнтейнеру виднее насколько глючен код, за кой он отвечает? Или базарбным бабкам больше доверяешь?