Документ взят из кэша поисковой машины. Адрес оригинального документа : http://kodomo.fbb.msu.ru/pipermail/unix-2010/2010-May/000008.html
Дата изменения: Fri May 14 13:52:05 2010
Дата индексирования: Tue Oct 2 11:57:44 2012
Кодировка: koi8-r
[Unix-2010] LVM

[Unix-2010] LVM

Danya Alexeyevsky dendik на kodomo.fbb.msu.ru
Пт Май 14 13:52:03 MSD 2010


Привет,

On Fri, 14 May 2010 11:02:45 +0400, Nagaev Boris <bnagaev at gmail.com>
wrote:
> вопрос про LVM. Представим, что линукс сломался.
> При новой установке будут ли видны разделы LVM?

Если в новом устанавливаемом ядре есть поддержка LVM той же версии, то да.
(Сейчас есть LVM1 и LVM2 и оба поддерживаются всеми современными ядрами
линукса)

> Велик ли риск потерять данные?

Теоретически, как любое добавление технического элемента, оно должно
повышать вероятность поломки. На практике на этот вопрос нужно отвечать
статистикой. Ощутимой статистики у меня нет (пока что с поломками LVM
просто не сталкивался), и в сети её найти тоже трудно. Очевидно, что если
начинает сыпаться жёсткий диск, на котором находится LVM, то LVM от этого
может стать очень плохо; насколько я понимаю, LVM не рассчитан на работу
на
ломающихся жёстких дисках (и reiserfs, кстати, тоже): если что-нибудь в
этом месте сломается, то лучше всего всё-таки иметь резервные копии, иначе
я могу себе представить ситуацию, когда пришлось бы разбираться в том, как
именно заголовки lvm лежат на диске.

Кроме случаев сбоя именно самих жёстких дисков я о поломках LVM не слышал.

>> Ну так не используй XFS и ext4, по крайней мере, на тех разделах,
>> которые ты можешь захотеть уменьшать. Например, reiserfs4 можно в
>> offline и уменьшать и увеличивать и в online его можно увеличивать.
>>
> Но ведь именно XFS следует использовать на разделах с большими файлами.

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

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

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

> По поводу популярности python и perl - по числу результатов в гугле они
> примерно равны, однако среди русскоязычных находок лидирует perl.

Я говорил вот о чём: http://popcon.debian.org/
В дебиане (и в других дистрибутивах, как я понимаю, тоже) perl
используется в каких-то из самых ключевых скриптов. (Он входит
в essential packages). Установить debian так, чтобы в нём не было
perl, очень нетривиально, и вопрос, будет ли он после этого
работоспособен.

Но я не вижу в этом ничего хорошего, или, вообще говоря, и сильно плохого.


Подробная информация о списке рассылки Unix-2010