LVM, чтобы было?

[jojahti]

Кашмай.

Что такое барьеры, в общих словах и на русском?

[Bluetooth]

чёрт возьми, какие все продвинутые! ext4, btrfs, nilfs!
чувствую себя такой деревней со старыми добрыми ext2/ext3. может быть, я извращенец?

Просто мы с Вами не убунтоиды.

XFS и JFS. NILFS2 тоже вроде бы не умеет.

Не помню, чтобы эти три фс использовались широко.

XFS включает, и правильно делает. И выключать их стоит только в случае, если у вашего дискового контроллера - энергонезависимый кэш записи. Иначе это безумие по отношению как к хранимым данным, так и к самой ФС.

А что ext3 не включает? И при этом данные на нем отнюдь не сыпятся. Может, таки надо уточнять, что это требуется не всем фс?

Да всё нормально, можно сконвертиться в Ext4, и спокойно ждать некоторой стабилизации BTRFS

А можно для начала подождать поддержки ext4 в стейбл ветках дистров. Как я понимаю, в дебиане 6 она будет. Ибо я как-то не любитель пихнуть ext4, а потом из быкапов разворачивать данные, т.к. в ехт4 был баг.

[rm_]

Не помню, чтобы эти три фс использовались широко.

Причём тут ваша память, и "использовались широко"? В оригинале было: большинство современных ФС. Могу даже уточнить -- современных ФС общего назначения, поддерживаемых в ядре Linux. А таких не очень-то и много.

А что ext3 не включает? И при этом данные на нем отнюдь не сыпятся. Может, таки надо уточнять, что это требуется не всем фс?

Да всем требуется, это очевидно любому, понимающему, что такое барьеры.

[drBatty]

А можно для начала подождать поддержки ext4 в стейбл ветках дистров.

в Slackware 13.0 уже есть уже и в 13.1 должна быть, не проверил ещё... Не думаю, что Патрик её выпилил.

про барьеры - ИМХО они не очень нужны. ИМХО всё равно данные могут быть потеряны. А 100%я гарантия сохранения структуры ценой снижения скорости и далеко не 100% гарантии сохранности данных мне не очень нужна. Удалённые бекапы ИМХО более предпочтительны для ценных данных, которые не очень часто меняются. А диск я и отформатировать смогу.

Да всем требуется, это очевидно любому, понимающему, что такое барьеры.

мне не требуется. те, кто отключал их в EXT3 ничего не понимали? да и не дают они гарантии при аппаратном сбое. Ну будет у вас сохранятся структура и теряться данные от нажатия на RESET, ну и что? Не нажимайте.

[serzh-z]

Что такое барьеры, в общих словах и на русском?

В общих словах: ядро имеет возможность запретить запись группы блоков (скажем - группа "2") на носитель, пока на носитель не будет записана предыдущая группа блоков (группа "1"). Запись этих двух групп разделяется "барьером" - специальным ядерным вызовом.

[sash-kan]

В общих словах: ядро имеет возможность запретить запись группы блоков (скажем - группа "2") на носитель, пока на носитель не будет записана предыдущая группа блоков (группа "1"). Запись этих двух групп разделяется "барьером" - специальным ядерным вызовом.

а контроллерами диска эти барьеры тоже управляют? а то ведь контроллеры имеют свою точку зрения на оптимальное движение головок.

[serzh-z]

а контроллерами диска эти барьеры тоже управляют? а то ведь контроллеры имеют свою точку зрения на оптимальное движение головок.

Я так понял - реализация барьеров завязана на механизм подтверждения от устройства, типа "запись завершена". Т.е. никакое внутреннее кеширование устройства не должно на это влиять. Но утверждать не берусь.

[sash-kan]

Я так понял - реализация барьеров завязана на механизм подтверждения от устройства, типа "запись завершена". Т.е. никакое внутреннее кеширование устройства не должно на это влиять. Но утверждать не берусь.

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

rm_
вы тут, видимо, единственный понимающий, что такое барьеры, скажите — я прав?

[rm_]

вы тут, видимо, единственный понимающий, что такое барьеры, скажите — я прав?

Да я не уверен, что сам-то их понимаю
Работает так:

запись в сектор 582
запись в сектор 382
запись в сектор 121
запись в сектор 421
запись в сектор 124
<барьер> // означает: "а теперь пойди, слей всё вышеуказанное на диск, без разницы в каком порядке, главное чтоб всё было записано, и не возвращайся, пока оно физически не будет намагничено на пластины"
запись в сектор 345
запись в сектор 456
чтение сектора 402
etc

Такой вот sync на уровне максимально приближенном к железу, и вменяемые диски не имеют права дурить его с помощью кэша записи и т.д.
ФС могут использовать это чтобы, к примеру, сначала записать на диск данные (точно записать), и уже только потом - обновлять структуры ФС, чтобы они указывали на эти данные. А без поддержки барьеров, у нас нету вообще никакой уверенности, что уже на диске, а что пока где-то "в полёте" (в кэшах диска или контроллера). Соотв-но если вдруг отрубили свет или компьютер повис, шансы после перезагрузки получить забавную кашицу вместо файловой системы и пользовательских данных резко возрастают. Конечно, если у вас UPS, и компьютер "точно-точно никогда не зависает", это может быть чуть менее актуально.

[sash-kan]

Работает так:

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

А без поддержки барьеров, у нас нету вообще никакой уверенности, что уже на диске, а что пока где-то "в полёте" (в кэшах диска или контроллера).

действительно, чего это вумные мужики головы ломали, журналирования придумывали и в файловых системах, и в базах данных и ещё где-нибудь? всех «журналистов» нужно срочно переквалифицировать в веб-дизайнеров. чтоб с голоду не померли.

[serzh-z]

тормоз в производительности.

"Performance penalty" до 30%.

[Bluetooth]

А что ext3 не включает? И при этом данные на нем отнюдь не сыпятся. Может, таки надо уточнять, что это требуется не всем фс?

Да всем требуется, это очевидно любому, понимающему, что такое барьеры.

Я таки не понимаю что это. Но это не проблема. могу пойти почитать. Другое дело, что огромное клоичество систем на ext3 и без барьеров работает надежно.

Причём тут ваша память, и "использовались широко"? В оригинале было: большинство современных ФС. Могу даже уточнить -- современных ФС общего назначения, поддерживаемых в ядре Linux. А таких не очень-то и много.

А при том, что это "большинство современных фс" не используется широко.

Удалённые бекапы ИМХО более предпочтительны для ценных данных, которые не очень часто меняются. А диск я и отформатировать смогу.

Удаленные бэкапы предпочтительны для любых данных, которые не хочется потерять. А включение/выключение барьеров, я подозреваю - экономия на спичках. Хотя могу быть и не прав.

в Slackware 13.0 уже есть уже и в 13.1 должна быть, не проверил ещё... Не думаю, что Патрик её выпилил.

По дефолту?

Конечно, если у вас UPS, и компьютер "точно-точно никогда не зависает", это может быть чуть менее актуально.

Лично я считаю, что наличие упса и "независающего компьютера" - отнюдь не повод пересматривать концепцию защиты данных. Ибо на деле проблемы остаются все те же, просто возникают реже. Но одного возникновения проблемы(отключения света или зависона) может хватить, чтобы похерить все.

[rm_]

действительно, чего это вумные мужики головы ломали, журналирования придумывали и в файловых системах, и в базах данных и ещё где-нибудь?

Барьеры как раз при журналировании и используются:
http://xfs.org/index.php/XFS_FAQ#Write_barrier_support.

Barrier support will flush the write back cache at the appropriate times (such as on XFS log writes).

Если важна целостность данных и ФС - это либо барьеры, либо выключайте кэширование записи вообще:
http://madduck.net/blog/2006.07.18:xfs-caching/

А performance penalty - ну да, есть. Как и от журналирования, и вообще, от многих других повышающих надёжность вещей.

[serzh-z]

Другое дело, что огромное клоичество систем на ext3 и без барьеров работает надежно.

Какой великий смысл в журнале, если сложно предсказать в каком порядке будет выполнена запись - "журнал, данные" или "данные, журнал"?

P.S.: /me ненароком заметил, что тема-то была про LVM =)

[Bluetooth]

Другое дело, что огромное клоичество систем на ext3 и без барьеров работает надежно.

Какой великий смысл в журнале, если сложно предсказать в каком порядке будет выполнена запись - "журнал, данные" или "данные, журнал"?

Не знаю. Меня интересует другой вопрос: В чем смысл в переполохе "ааа!! лвм не поддежривает барьеры!! в морг!", если кучас истем работает нормально без них.

[serzh-z]

В чем смысл в переполохе "ааа!! лвм не поддежривает барьеры!! в морг!", если кучас истем работает нормально без них.

Спор уже перешёл в разряд "Мне пох на всех, у меня это работает. ЧЯНД?".

[sash-kan]

Спор уже перешёл в разряд

imho, пока нет.
хотя бы потому, что нет тех, у кого «не работает» (это я не про участников дискуссии, а в глобальном плане).
и ещё потому, что, насколько я вижу, ещё никто в этой теме не заявлял «мне пох на всех».
скорее наоборот, интересно узнать (по крайней мере мне лично), что же такого сногшибательного в этой новой технологии.
чего-то такого, без чего

однозначно надо в морг

а то, что мы все тут немножко вольничаем в формулировках, надеюсь, простительно. не учёный диспут, чать, ведём.

[serzh-z]

imho, пока нет.

Ладно, уточню - спор с Bluetooth перешёл в этот разряд.

P.S.: про морг я ничего не писал.

хотя бы потому, что нет тех, у кого «не работает».

=) это похоже на то, как если бы несколько одомашенных юзеров сели и начали вести разговор "А вот на моём ноутбуке стоит не самая свежая версия сервера Java EE и не все пакеты следуют Enterprise JavaBeans". :) Масштабы не те.

[sash-kan]

Масштабы не те.

„нет тех, у кого «не работает»” — это я и писал про глобальное.

p.s. поставил примечание к этой строчке в исходном посте.

[Davinel]

Я таки не понимаю что это. Но это не проблема. могу пойти почитать. Другое дело, что огромное клоичество систем на ext3 и без барьеров работает надежно.

ext3 делает sync достаточно часто, чтобы барьеры небыли так уж критичны. Т.е. если у вас прямо во время записи случится кернел паник часть данных вы конечно потеряете, но только в таком случае.
ext4 же синкается в фоновом режиме, с низким приоритетом. И при неблагоприятных условиях данные могут куда то дется даже если прошло уже весьма много времени.



Вопрос по mhddfs (кстати, спасибо, очень прикольная штука не знал о такой раньше).
Допустим у меня обьединены два диска. На одном диске есть папка tmp. Я пишу туда какие то файлы и вот, место на том диске, где эта папка находится, закончилось.
Что оно будет делать?..

[rm_]

Вопрос по mhddfs (кстати, спасибо, очень прикольная штука не знал о такой раньше).
Допустим у меня обьединены два диска. На одном диске есть папка tmp. Я пишу туда какие то файлы и вот, место на том диске, где эта папка находится, закончилось.
Что оно будет делать?..

http://romanrm.ru/mhddfs
"Если какой-то из дисков исчерпает своё свободное пространство в процессе записи файла, запись не «обвалится»; mhddfs обойдёт эту неприятность абсолютно прозрачно, переместив уже записанные данные файла на другой диск (где места побольше) и продолжив дописывать последующие данные уже туда. Приложение, записывающее файл, ничего и не заметит (кроме, может быть, небольшой задержки при записи очередной порции данных)."

[Bluetooth]

imho, пока нет.

Ладно, уточню - спор с Bluetooth перешёл в этот разряд.

А я вот так не считаю. Если Вам не нравятся мои формулировки, то можете их проигнорировать, и ответить на гораздо более вменяемую формулировку sash-kan, которая по сути вопроса повторяет мою.

ext3 делает sync достаточно часто, чтобы барьеры небыли так уж критичны. Т.е. если у вас прямо во время записи случится кернел паник часть данных вы конечно потеряете, но только в таком случае.
ext4 же синкается в фоновом режиме, с низким приоритетом. И при неблагоприятных условиях данные могут куда то дется даже если прошло уже весьма много времени.

Ну, допустим, связка ext4+lvm действительно будет не выглядеть стабильно. Но этого явно недостаточно для отправки лвм в морг. Может, товарищ rm_ таки раскроет свое "в морг"?

[rm_]

Может, товарищ rm_ таки раскроет свое "в морг"?

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

[Bluetooth]

Может, товарищ rm_ таки раскроет свое "в морг"?

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

Я так понимаю, Вы считаете важным барьеры, потому, что юзаете ехт4, в которой есть реальная необходимость барьеров. Да?
Тогда вопросов больше нет. Это логично.
Если нет, то раскройте, почему барьеры - важно.

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

Которые перекрывают и барьеры(не требуется, т.к. ехт3), и невозможность работы из под других платформ(не требуется, т.к. использую gnu/linux на 90%)

[Ленивая Бестолочь]

автору темы очень рекомендую прочитать
http://xgu.ru/wiki/LVM
даже пусть без полного понимания, потому взять виртуалку, открыть ещё раз ссылку сверху и попробовать.

к "обсуждению" у меня вот вообще все сервера стоят на LVM поголовно. очень много преимуществ его использования, с учётом того, что у нас на всех "железных" серврах разведены drbd разделы, в которых лежат машины xen. без LVM это было бы сильно грустнее. в данный момент на всех без исключения серверах стоит reiserfs3. я её выбрал тогда, когда г-н Рейзер ещё не убивал свою жену, ФС почти стала "дефолтовой в линукс", уступив ext3 и светлое будущее reiser4 казалось неизбежным. чего ставить теперь я не знаю. в связи с вышесказанным думаю - либо отключать барьеру и ставить ext4 (sic), либо ждать дальше btrfs и отключать LVM в пользую её встроенного менеджера, либо патчить ядро для ZFS (спасибо, на солярисе наелся), либо патчить ядро и ставить reiser4 (как же я не хочу патчить ядро).
стыдно, товарищи, стыдно,
без LVM жизнь скучна, порочна
не победил LVM - обидно,
но btrfs победит - точно! ;-)

[rm_]

Я так понимаю, Вы считаете важным барьеры, потому, что юзаете ехт4, в которой есть реальная необходимость барьеров. Да?

Я пользуюсь XFS, Ext4 и BTRFS, во всех трёх они важны.

барьеры(не требуется, т.к. ехт3)

Не доказано, и "у меня всё вроде работает без них" - не аргумент.

Напротив, в Википедии расписан замечательный сценарий, как без барьеров очень реально угробить себе ФС и данные:

Ext3 does not do checksumming when writing to the journal. If barrier=1 is not enabled as a mount option (in /etc/fstab), and if the hardware is doing out-of-order write caching, one runs the risk of severe filesystem corruption during a crash.[28][29]

Consider the following scenario: If hard disk writes are done out-of-order (due to modern hard disks caching writes in order to amortize write speeds), it is likely that one will write a commit block of a transaction before the other relevant blocks are written. If a power failure or unrecoverable crash should occur before the other blocks get written, the system will have to be rebooted. Upon reboot, the file system will replay the log as normal, and replay the "winners" (transactions with a commit block, including the invalid transaction above which happened to be tagged with a valid commit block). The unfinished disk write above will thus proceed, but using corrupt journal data. The file system will thus mistakenly overwrite normal data with corrupt data while replaying the journal. There is a test program available to trigger the problematic behavior. If checksums had been used, where the blocks of the "fake winner" transaction were tagged with a mutual checksum, the file system could have known better and not replayed the corrupt data onto the disk. Journal checksumming has been added to EXT4.[30]

http://en.wikipedia.org/wiki/Ext3#No_checksumming_in_journal

The ext3 barrier option is not enabled by default on almost all popular Linux distributions, and thus most distributions are at risk.
http://blog.nirkabel.org/2008/12/07/ext3-w...-write-caching/

[Bluetooth]

Я так понимаю, Вы считаете важным барьеры, потому, что юзаете ехт4, в которой есть реальная необходимость барьеров. Да?

Я пользуюсь XFS, Ext4 и BTRFS, во всех трёх они важны.

Тогда ясно.

барьеры(не требуется, т.к. ехт3)

Не доказано, и "у меня всё вроде работает без них" - не аргумент.

А аргумент "у огромной толпы людей все работает без них" - аргумент?

[Ali1]

О, я понял почему тормозит KVM на btrfs!

Я честно не понимаю, как можно добиться 100% надёжности при асинхронном обмене. И стоит ли огород городить.

[watashiwa_daredeska]

Я считаю барьеры очень важной фичей (см. выше, почему), и если LVM не даёт их использовать,

Выше приводилась цитата про то, что LVM поддерживает барьеры на однодисковых конфигурациях. Проверил у себя — никаких сообщений о недоступности барьеров не обнаружил.

А аргумент "у огромной толпы людей все работает без них" - аргумент?

Насколько я понимаю, без барьеров оно может работать, безусловно. Отсутствие барьеров может сказаться при жестком powerfail.

Я честно не понимаю, как можно добиться 100% надёжности при асинхронном обмене.

А что Вы понимаете под 100% надежностью? Суть в том, чтобы пусть даже ценой потери некоторых данных, вернуть ФС в некоторое консистентное состояние, которое было в прошлом, а не получить бессвязную кучу мусора на диске.

[mvt]

Я не очень понял нужна мне эта штука или нет.
А вот если запилить её себе, так, на всякий случай, никаких побочных эффектов не будет? Навроде снижения скорости дисковых операций?

Вот так человек спросил. О чем споры?
Ответ: LVM Вам иногда может пригодиться, когда Вы знаете, зачем это нужно.
А пока - не нужно.