>> как ты сделаешь снимок / или /var неотмонтировав их?

Командой lvcreate. Отмонтировать ничего не нужно. Всегда ваш, К.О.

Надо проверить.

Проверил. Вручную снял снэпшот с корневого раздела при работающей системе, а потом подмонтировал его:

[wizard@fedora ~]$ sudo lvcreate -L 1G -s -n rootfssnapshot /dev/system/rootfs
  Logical volume "rootfssnapshot" created
[wizard@fedora ~]$ sudo mount /dev/system/rootfssnapshot /mnt/rootfs2
[wizard@fedora ~]$ ls /mnt/rootfs2
bin  boot  cgroup  dev  etc  home  lib  lib64  lost+found  media  mnt  opt  proc  root  sbin  selinux  srv  sys  tmp  usr  var

Ошибок при монтировании нет.

Бывают ситуации, когда заранее определить, как будет идти распределение места на разделах, не удается. В этих случаях LVM очень удобен, ибо позволяет расширить место на лету.

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

Ну и в целом с LVM удобнее: не надо думать о primary/logical, не надо думать о порядке разделов, о их номерах и т.д., не надо думать о размере конкретных хардов.

> Да кому это вообще может понадобиться чаще чем раз в три года?

LVM?

Тем, кто не использует Debian stable.

>> На живой подмонтированной ФС создаются?

А нахрена оно было бы нужно, если бы требовало отмонтирования?

1. Ресайз — да я не знаю как будет расти раздел под торенты, раздел под фотки и музыку, раздел для написание кода.

2. Выделение разделов под вирт. машины. Их лекгий ресайз и удаление если вирт. машина свое отработала.

3. Легкая миграция на диск(и) больших размеров (pvmove, vgreduce)

4. снапшоты

5. ???

6. ПРОФИТ

Скажите, для чего?

Делал им нарезку стораджа для клауда.

На живой подмонтированной ФС создаются?

да

>Как RAID 0? Тогда это такое ССЗБ, что ни в сказке сказать, ни пером описать!
Обычно как linear raid. А в чём проблема с RAID0 дома? Бэкапы что с ним, что без него нужны.

- Снапшоты LVM непригодны для работы.

Обоснуй или GTFO.

Из презентации товарища по имени Chris Mason на прошлогоднем LinuxCon:

COW Comparison (next two graphs)

BTRFS

• Create 20 snapshots of a 400MB file
• Overwrite the file
• 400MB written to a new location on disk
• Total time: 1.6s

LVM

• Create 20 snapshots of a LVM logical volume
• Overwrite 400MB of the original
• 400MB copied and written to exception table for each snapshot
• Total time: 558s

Ну и картинки на двух последующих слайдах веселые.

Ну и вот это собственно:

A snapshot of the <origin> block device is created. Changed chunks of <chunksize> sectors will be stored on the <COW device>. Writes will only go to the <COW device>. Reads will come from the <COW device> or from <origin> for unchanged data. <COW device> will often be smaller than the origin and if it fills up the snapshot will become useless and be disabled, returning errors. So it is important to monitor the amount of free space and expand the <COW device> before it fills up.

Прикинь, ты такой весь в белом сделал себе снапшот и бэкапишь его потихоньку ночью. Утром приходишь и опаньки - <COW device> переполнился, бэкап не завершился, начинай с начала.. И будешь ты этот ночной бэкап днем делать, предварительно потрахавшись с поиском дополнительного места, которого днем понадобится гораздо больше, ввиду более высокой активности. Уверен, что получится быстро место высвободить для COW device? Как там у файловых систем с уменьшением размера? А какая будет производительность днем в присутствии снапшота? См. презу Криса.

Так что то, что оно есть - оно хорошо, спору нет. На поиграться - пойдет. Для серьезного применения? Не уверен.

>> На живой подмонтированной ФС создаются?

А нахрена оно было бы нужно, если бы требовало отмонтирования?

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

Точно это работает для ext*, XFS (xfs_freeze нужно выполнить), JFS. Должно быть для ReiserFS. Об остальных ничего сказать не могу.

Снапшоты в lvm говно, а вот разделы нарезает вполне нормально. Сам по себе lvm используется редко т.к. обычные юзеры не так часто апгрейд делают. А вот мой знакомый в банке говорит что постоянно ресайзит разделы. Там, правда, aix а не линукс.

Другой пример: раздел с логами биллинга «внезапно переполнился»(если что, ту тачку не я админил). Тут тоже lvm чувака выручил.

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

LVM sucks?

- Снапшоты LVM непригодны для работы.

iZEN, уважаемый, я понимаю, что это уже сто раз обсуждалось, но может быть вы дадите ссылку на статью, в которой будет сказано почему снимки LVM это плохо, а Btrfs/ZFS — хорошо.

Сам нашёл.

Сам уже нашёл.

LVM'овские снапшоты не надо делать более одного на LV (20 как в вышеприведенной статье)

Основная цель снапшотов а-ля zfs/btrfs — откатиться и/или иметь доступ к предыд. версиям файлов (типа бэкап)

Основная цель снапшотов LVM — заморозить систему на время бэкапа.

Ну, например, реши следующую задачу:

Есть 3 жёстких диска не очень большого объёма. Как сделать сервер-файлопомойку, чтобы их пространство использовалось наиболее эффективно, и при этом не нужно было вручную задавать, на какой физический диск кидать очередной файл?

Ну, например, реши следующую задачу:

man mdadm

>Зачем мне нужен LVM?
это ты у меня спрашиваешь? о_О

> Основная цель снапшотов LVM — заморозить систему на время бэкапа.

Чего оно с успехом и делает :)

и да:

LVM'овские снапшоты не надо делать более одного на LV (20 как в вышеприведенной статье)

напоминает известное высказывание про то, что 640К ОЗУ хватит всем.

mhddfs
http://romanrm.ru/mhddfs

Для изменения размеров разделов, к примеру swap обычно определяется по формуле RAM * 2, добавил памяти и парой команд привёл swap в соответствие. очень удобен при замене винчестера, одной командой можно перенести всю информацию с винта на винт. у меня к примеру апгрейд винчестера в среднем раз в 1-1,5 года

Плюсов много, например:
-Ресайз и присоединение физических томов
-Снэпшоты на ФС, их не поддерживающих (хоть на vfat). Снэпшоты на ZFS и btrfs - это конечно круто, но для начала надо иметь их на томе:)
-Снэпшоты на запись и интеграция снэпшотов в основное дерево (сделал снэпшот, обновился, перезагрузился со снэпшота, понравилось - заменил снэпшотом основное дерево ФС)
-Создание томов для вирт. машин, iSCSI и прочей фигни (работают быстрее за счет прямого доступа к диску в обход VFS)
Недостатки:
-Падение производительности в 2 раза при создании снэпшота (за счет необходимости писать на диск в 2 раза больше инфы, плата за ФС-независимые снэпшоты)

mukoh> заморозить систему

заморозить ФС

frankincent> -Падение производительности в 2 раза при создании снэпшота

Это если писать в снапшот. Если же сделать снапшот для чтения (для бэкапа), то падения производительности быть не должно.

А теперь еще раз повтори dd

Зачем?

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

А ты последний dd погоняй пару-тройку раз и расскажи почему так?

~ # dd if=/dev/zero of=/var/tmp/000 bs=1M count=500
500+0 records in
500+0 records out
524288000 bytes (524 MB) copied, 10.0688 s, 52.1 MB/s
~ # lvcreate -L1G -s -n varbackup /dev/vg/var
  Logical volume "varbackup" created
~ # dd if=/dev/zero of=/var/tmp/000 bs=1M count=500
500+0 records in
500+0 records out
524288000 bytes (524 MB) copied, 54.7255 s, 9.6 MB/s
~ # lvextend -L 1300M /dev/vg/varbackup
  Extending logical volume varbackup to 1.27 GiB
  Logical volume varbackup successfully resized
~ # dd if=/dev/zero of=/var/tmp/000 bs=1M count=500
500+0 records in
500+0 records out
524288000 bytes (524 MB) copied, 17.3008 s, 30.3 MB/s

Какая-то странная вариация вышла.

И расширять снапшот не требовалось %)

Это к http://www.linux.org.ru/jump-message.jsp?msgid=6204003&cid=6205411

По самым скромным заниженным прикидкам LVM раз в 100000 нужнее тебя. Думай, делай выводы.