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

[jojahti]

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

[allez]

Я не очень понял нужна мне эта штука или нет.

Если не очень поняли, то лучше пока не связывайтесь с этим делом. Вот когда появится осознанная необходимость...
А до этого можно почитать, например, здесь - http://ru.wikipedia.org/wiki/LVM и попутно пройтись по ссылкам, приложенным к статье, они тоже содержат полезную информацию.

P. S. Я лично ни на домашних компьютерах, ни на рабочих станциях LVM не использую.

[sash-kan]

Навроде снижения скорости дисковых операций?

с чего бы это диски стали работать медленнее?

[sash-kan]

Вот когда появится осознанная необходимость...

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

[jojahti]

sash-kan

с чего бы это диски стали работать медленнее?

Ну как бы лишняя прослойка.

Если не очень поняли, то лучше пока не связывайтесь с этим делом.

Ну ресайз томов, с шифрованием поиграться. Главное с минусами непонятно.

[sash-kan]

Ну как бы лишняя прослойка.

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

jojahti
у вас не работает ссылка «quote», располагающаяся чуть правее ссылки «insert name» в левой части поста?

[allez]

увы, жизнь так паршиво устроена, что необходимость появляется именно тогда, когда уже нет возможности.
сидишь и думаешь: и чего я отказался от создания lvm в два клика при установке?

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

Ну ресайз томов, с шифрованием поиграться. Главное с минусами непонятно.

Можете тогда поэкспериментировать вначале на виртуальной машине: и плюсы с минусами на собственном опыте прочувствуете, и напортачить не страшно будет. ;)

[serzh-z]

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

sash-kan, ну вот всё равно не получается у тебя косить под идиота. :) Device-mapper, на котором построен LVM, да и сам LVM, - это вполне ощутимые прослойки между ядром ОС и контроллером. Это не просто лишняя работа процессора по управлению процессом ввода-вывода, но и дополнительная работа по поддержке блокировок и прочего.

Ну и помимо производительности - это сложность, при отсутствии навыков, восстановления системы, невозможность использовать барьеры для журналируемых ФС при записи, невидимость ФС из другой ОС. Хотя я всегда почти за LVM/EVMS был, но вот в связи со всем сказанным, подозреваю, что нашему гостю с рогами не стоит спешить использовать LVM - иначе следующие его вопросы будут про "невозможность загрузки с LVM", "доступ из Windows", "восстановление упоротой системы" и т.д. =)

[sash-kan]

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

вот я про это самое и говорю: лучше заранее соломку подостлать. даже не до конца понимая, где и когда она может пригодится.

serzh-z
получается-получается!
для современного процессора ожидание ввода-вывода — это как в средние века гонца послать на край света. да, когда-нибудь вернётся. и время на его сборы настолько ничтожно по сравнению с ожиданием его возвращения…
если путь туда-обратно занимает несколько лет, то час-другой задержки перед выходом — просто пыль.

[serzh-z]

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

=) Ну-ну... Как тебе многосекундные (!) задержки на sync_page при использовании планировщика CFQ, Device-mapper/LUKS, активной работе торрент-клиента в фоне, работе rsync и обычной работе в GNOME? Не нужно только говорить, что это проблемы винта и настроек.

[sash-kan]

Как тебе многосекундные (!) задержки на sync_page при использовании планировщика CFQ, Device-mapper/LUKS, активной работе торрент-клиента в фоне, работе rsync и обычной работе в GNOME?

примерно как и погода на марсе.

[rm_]

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

=) Ну-ну... Как тебе многосекундные (!) задержки на sync_page при использовании планировщика CFQ, Device-mapper/LUKS, активной работе торрент-клиента в фоне, работе rsync и обычной работе в GNOME? Не нужно только говорить, что это проблемы винта и настроек.

А в dmesg случаем ничего нету после таких задержек?

[serzh-z]

А в dmesg случаем ничего нету после таких задержек?

Нет. Ошибки pulseaudio про ratelimit, думаю, не в счёт. Судя по всему в последних версиях Device-mapper или планировщике ВВ что-то поломали. Ибо в сети полно жалоб на огромную латентность вывода при его использование, в частности совместно с dmcrypt (LUKS). Раньше такого точно не было.

[Bluetooth]

P. S. Я лично ни на домашних компьютерах, ни на рабочих станциях LVM не использую.

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

Ну и помимо производительности - это сложность, при отсутствии навыков, восстановления системы

Это тоже негативный момент.

=) Ну-ну... Как тебе многосекундные (!) задержки на sync_page при использовании планировщика CFQ, Device-mapper/LUKS, активной работе торрент-клиента в фоне, работе rsync и обычной работе в GNOME? Не нужно только говорить, что это проблемы винта и настроек.

Я не в теме. Почему у меня ничего такого нет, при том, что лвм - есть?

Судя по всему в последних версиях Device-mapper или планировщике ВВ что-то поломали.

А. Ну так пишите багрепорт, а не разводите "лвм - медленно!"

[serzh-z]

Я не в теме. Почему у меня ничего такого нет, при том, что лвм - есть?

Ммм? А мы сравниваем системы в одинаковых условиях? ЛОЛ.

А. Ну так пишите багрепорт, а не разводите "лвм - медленно!"

Где я написал "ЛВМ медленно"? У меня вообще LVM нет. И писал я про увеличившуюся латентность на дисковых операциях.

[NickLion]

А как LVM относится к отключению питания во время дисковых операций?

[rm_]

А как LVM относится к отключению питания во время дисковых операций?

Если как выше писали, он не даёт использовать barrier'ы, то его однозначно надо в морг.

Гораздо хуже то, что LVM часто советуют для объединения дисков "в один большой", не задумываясь, что при этом происходит с надёжностью такой этажерки. Для этого mhddfs (либо различные варианты unionfs/aufs) подходят лучше.
Для чего ещё нужен LVM? Чтобы легко увеличивать-уменьшать разделы - сомнительная причина, т.к. большинство современных ФС не умеют уменьшаться. Вот разве что Ext4 - умеет, и с нею это может иметь какой-то смысл. (Хотя, частая это ли задача?)
Ещё, говорят, оно умеет делать снапшоты. Но если нужны они, не лучше ли обратить внимание на ФС с такой функциональностью, BTRFS или NILFS2 (которые и работать с ними позволят без размонтирования ФС).
Преимущество, которым я пользуюсь на одном из компьютеров - возможность внутри одного криптодевайса создать несколько разделов. И в общем-то кроме этого, реальных причин использовать LVM как-то не видно.

[serzh-z]

Если как выше писали, он не даёт использовать barrier'ы, то его однозначно надо в морг. smile.gif

Ну, момент спорный... Особенно, если учесть, что в ext3 по умолчанию они отключены и разработчики ФС одно время призывали вообще от них отказаться (или как-то так) в новых ФС. Вот с ext4 дело уже другое, с ним dmesg завален предупреждениями. =)

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

Зачем тут нужен LVM? Вполне прекрасно работает стек "весь накопитель -> dmcrypt -> MBR/GPT -> разделы -> ФС".

[Bluetooth]

А. Ну так пишите багрепорт, а не разводите "лвм - медленно!"

Где я написал "ЛВМ медленно"? У меня вообще LVM нет. И писал я про увеличившуюся латентность на дисковых операциях.

В ответ на пост sash-kan про то, что "лишняя прослойка" на задержку влиять не будет, Вы начали писать про жестокие задержки. Как будто это относится к ЛВМ вообще. А дальше выясняется, что это просто баг.

Если как выше писали, он не даёт использовать barrier'ы, то его однозначно надо в морг.

А что его-то одного? Все системы в морг. Ибо барьер по дефолту нигде не включен. Значит, в морг!

Гораздо хуже то, что LVM часто советуют для объединения дисков "в один большой", не задумываясь, что при этом происходит с надёжностью такой этажерки

Да. За это руки обрывать надо

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

Я помню одну. Какие еще?
Кстати, помимо уменьшения-увеличения(не заметил, кстати, в этом удобства). Можно создавать толпу разделов. Большую толпу разделов. Если мы работаем с разделами в mbr, то их вместо толпы только 16 создать можно. А еще и имена для каждого раздела из этой толпы.

Ещё, говорят, оно умеет делать снапшоты. Но если нужны они, не лучше ли обратить внимание на ФС с такой функциональностью, BTRFS или NILFS2 (которые и работать с ними позволят без размонтирования ФС).

А если вернуться из 2015 года в 2010, то какую юзать?

[Davinel]

невозможность использовать барьеры для журналируемых ФС при записи

Хм. Не знал. Если так, то это весьма серьезный недостаток, вплоть до полного исключения из использования.

[Bluetooth]

А теперь внимание вопрос: Если барьеры - такая важная и мастхэвная фича, то почему нигде по дефолту не включена?

[serzh-z]

Bluetooth
Внимание, ответ, "man mount":

barrier=0 / barrier=1 / barrier / nobarrier
This enables/disables the use of write barriers in the jbd code. barrier=0 disables, barrier=1 enables. This also requires an IO stack which
can support barriers, and if jbd gets an error on a barrier write, it will disable again with a warning. Write barriers enforce proper on-
disk ordering of journal commits, making volatile disk write caches safe to use, at some performance penalty. If your disks are battery-
backed in one way or another, disabling barriers may safely improve performance. The mount options "barrier" and "nobarrier" can also be used
to enable or disable barriers, for consistency with other ext4 mount options.

The ext4 filesystem enables write barriers by default.

[Davinel]

Если как выше писали, он не даёт использовать barrier'ы, то его однозначно надо в морг.

А что его-то одного? Все системы в морг. Ибо барьер по дефолту нигде не включен. Значит, в морг!

Потому что к примеру в ext3 барьер не критичен.
С другой стороны в ext4 он таки критичен и там он по умолчанию включен.

[Bluetooth]

Если как выше писали, он не даёт использовать barrier'ы, то его однозначно надо в морг.

А что его-то одного? Все системы в морг. Ибо барьер по дефолту нигде не включен. Значит, в морг!

Потому что к примеру в ext3 барьер не критичен.
С другой стороны в ext4 он таки критичен и там он по умолчанию включен.

Спасибо. Теперь ясно.

[sash-kan]

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

[taaroa]

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

...ZFS забыли (:
http://www.opennet.ru/opennews/art.shtml?num=26751

ZFS Version 0.4.1 2009-01-21
ZFS Version 0.4.9 2010-05-23

[sash-kan]

taaroa
zfs тут пока не упоминали. как и десятки других файловых систем.

[rm_]

Зачем тут нужен LVM? Вполне прекрасно работает стек "весь накопитель -> dmcrypt -> MBR/GPT -> разделы -> ФС".

Да, у меня тоже было подозрение что не нужен, но debian-installer делает через него.

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

Я помню одну. Какие еще?

XFS и JFS. NILFS2 тоже вроде бы не умеет.
http://en.wikipedia.org/wiki/Comparison_of...ystems#Features

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

XFS включает, и правильно делает. И выключать их стоит только в случае, если у вашего дискового контроллера - энергонезависимый кэш записи. Иначе это безумие по отношению как к хранимым данным, так и к самой ФС.
http://xfs.org/index.php/XFS_FAQ#Write_barrier_support.

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

Да всё нормально, можно сконвертиться в Ext4, и спокойно ждать некоторой стабилизации BTRFS
Чтобы потом перейти на неё, опять-таки, без переформатирования: https://btrfs.wiki.kernel.org/index.php/Conversion_from_Ext3

[t.t]

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

А уж мне-то что говорить... У меня не только всюду ext2/ext3, я ещё и LVM ни разу в жизни не использовал и даже не понимаю, зачем он мог бы быть мне нужен. (:

[reji]

author Andi Kleen <ak@...>
Tue, 6 Jan 2009 03:05:09 +0000 (03:05 +0000)
committer Alasdair G Kergon <agk@...>
Tue, 6 Jan 2009 03:05:09 +0000 (03:05 +0000)
...
dm: support barriers on simple devices

Implement barrier support for single device DM devices

This patch implements barrier support in DM for the common case of dm linear
just remapping a single underlying device. In this case we can safely
pass the barrier through because there can be no reordering between
devices.

NB. Any DM device might cease to support barriers if it gets
reconfigured so code must continue to allow for a possible
-EOPNOTSUPP on every barrier bio submitted. - agk

git.kernel.org