ФС

>>Use backups, Luke!

Лениво...

И ты при этом собираешься экспериментировать с ФС? По-моему, у тебя есть проблемы серьёзнее.

Они идиоты. Других слов просто нет. Впрочем, от фороникса вполне ожидаемо.

Почему?

И ты при этом собираешься экспериментировать с ФС? По-моему, у тебя есть проблемы серьёзнее.

По-твоему, правда. Проблемы с ФС - не проблемы. ;-) Я не собираюсь экспериментировать. Хочу просто найти что понадёжнее, побыстрее и, при этом, поддерживается. Затем, использовать. :-)

>Почему?
Мало того, что nilfs запомнит каждую запись в базу данных (которые ещё и не атомарны), так ещё оно и COW.

Кстати, а swap тоже шифруется?

Да

> У меня поверх LUKS находится LVM, а сверху XFS
Хм... LVM поверх LUKS, а не LUKS поверх LVM? Почему?

Про ext4 годная статья:
http://www.ibm.com/developerworks/ru/library/l-anatomy-ext4/index.html

LVM поверх LUKS, а не LUKS поверх LVM? Почему?

Чтобы не возиться с зоопарком ключей для нескольких разделов, очевидно. Да и вообще, нет никакой разницы, кроме вопросов удобства. Device Mapper'у вообще без разницы, что поверх чего.

1. Как я понял, ключи шифруются на базе парольной фразы, например. А разве нельзя, например иметь несколько LVM разделов, ключи которых требуют одну и ту же фразу, т.е. это, с точки зрения пользователя никак не будет отличаться от первого варианта (хотя, согласен, что LUKS «снизу» лучше в плане безопасности: все лишние данные, описывающие тома LVM тоже шифруются)?
2. А программный RAID чем-то принципиально отличается от LVM?

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

Можно, но ключ всё же придётся вводить для каждого тома отдельно.

LUKS «снизу» лучше в плане безопасности: все лишние данные, описывающие тома LVM тоже шифруются

Да в LVM metadata ничего особо ценного и нету.

А программный RAID чем-то принципиально отличается от LVM?

Тут я не очень в курсе, но есть подозрение, что когда нужен RAID, нужно использовать RAID, так же и с LVM. У них есть пересекающаяся функциональность, т.ч. кому-то, наверно, и LVM может заменить RAID...

> Можно, но ключ всё же придётся вводить для каждого тома отдельно.
В смысле, при создании томов?

Да в LVM metadata ничего особо ценного и нету.

Сам факт наличия LVM уже о чём-то говорит...
К тому же, в одной статейке советовали использовать рандомизацию, типа dd if=/dev/random of=/dev/hd*, на разделе, который будет зашифрован.
Для того, чтобы интересующийся не увидел где заканчиваются шифрованные данные, а где начинается пустое пространство. Всё-таки, LVM определённым образом структурирует дисковое пространство. Зачем давать дополнительную информацию, когда возможно хранить на диске просто бессмысленную мешанину?

У них есть пересекающаяся функциональность, т.ч. кому-то, наверно, и LVM может заменить RAID...

Просто две технологии... Похожие... Не очень понятно для чего.

В смысле, при создании томов?

При открытии.

Сам факт наличия LVM уже о чём-то говорит...

LUKS тоже не скрывает своего присутствия:

0000000: 4c55 4b53 babe 0001 6165 7300 0000 0000  LUKS....aes.....
0000010: 0000 0000 0000 0000 0000 0000 0000 0000  ................
0000020: 0000 0000 0000 0000 6362 632d 6573 7369  ........cbc-essi
0000030: 763a 7368 6132 3536 0000 0000 0000 0000  v:sha256........
0000040: 0000 0000 0000 0000 7368 6131 0000 0000  ........sha1....
0000050: 0000 0000 0000 0000 0000 0000 0000 0000  ................
0000060: 0000 0000 0000 0000 0000 0808 0000 0020  ............... 
0000070: c164 d309 c047 1d10 639a 6997 46b0 d9c6  .d...G..c.i.F...
0000080: b8a8 5371 5d2b 0c35 a7fe c06d ad21 8031  ..Sq]+.5...m.!.1
0000090: 03b3 5ca3 4f85 d390 1ac0 6d0c 60a2 8b99  ..\.O.....m.`...
00000a0: f399 d996 0000 000a 6664 6534 3466 6662  ........fde44ffb
00000b0: 2d66 3665 392d 3433 3832 2d61 3764 652d  -f6e9-4382-a7de-
00000c0: 3735 3561 6537 3762 3336 6465 0000 0000  755ae77b36de....
00000d0: 00ac 71f3 0005 4886 73cc da16 8a5d d9b0  ..q...H.s....]..
00000e0: 8838 cf71 eb76 5800 1cbd 0b3b 0ed9 47eb  .8.q.vX....;..G.
00000f0: 760a bd67 3256 8cdd 0000 0008 0000 0fa0  v..g2V..........
0000100: 00ac 71f3 0005 477c 5667 8db1 5a6b cfca  ..q...G|Vg..Zk..
0000110: d0b6 ff29 d8a0 c693 f86c a5e8 4724 1c4c  ...).....l..G$.L
0000120: 50c0 444c 0cf5 3db3 0000 0108 0000 0fa0  P.DL..=.........
0000130: 0000 dead 0000 0000 0000 0000 0000 0000  ................
0000140: 0000 0000 0000 0000 0000 0000 0000 0000  ................
0000150: 0000 0000 0000 0000 0000 0208 0000 0fa0  ................
0000160: 0000 dead 0000 0000 0000 0000 0000 0000  ................
0000170: 0000 0000 0000 0000 0000 0000 0000 0000  ................
0000180: 0000 0000 0000 0000 0000 0308 0000 0fa0  ................
0000190: 0000 dead 0000 0000 0000 0000 0000 0000  ................
00001a0: 0000 0000 0000 0000 0000 0000 0000 0000  ................
00001b0: 0000 0000 0000 0000 0000 0408 0000 0fa0  ................
00001c0: 0000 dead 0000 0000 0000 0000 0000 0000  ................
00001d0: 0000 0000 0000 0000 0000 0000 0000 0000  ................
00001e0: 0000 0000 0000 0000 0000 0508 0000 0fa0  ................
00001f0: 0000 dead 0000 0000 0000 0000 0000 0000  ................

> При открытии.
Эм... Но разве, при открытии тома нужна не только парольная фраза, которая расшифровывает ключ. Ключ же хранится (в шифрованном виде) в служебной области «LUKS-тома». Или я не правильно понял/прочитал?

LUKS тоже не скрывает своего присутствия

Я и не говорю, что это уж такой огромный плюс. Но, всё-таки, лучше уж будет известно, что используется только LUKS, чем LUKS и LVM вместе взятые. %-) Ну мало ли что..? o.O

Ещё по LVM'у вопросы:
1. /boot надо располагать обязательно в не LVM разделе?
2. Если / располагается на разделе поверх LVM тома, никаких проблем с загрузкой не будет (не нужен никакой initrd или что-то там дополнительное)?
3. Как я понял, был LVM, сейчас LVM2 и они весело несовместимы между собой. LVM2 не планируют чем-либо заменить?
4. Всё-таки, меня терзают смутные сомнения. При сбоях питания, например, том LVM не может полететь? Что, если полетит? Проблем с восстановлением не оберёшься (если до этого хватило бы fsck, то что теперь)? С использованием утилит, типа Partition Magic Explorer (ну или новее), ФС на LVM будут недоступны? Какие ещё с ним могут быть проблемы?
5. А так ли, вообще, нужен LVM, с учёт всего?

Эм... Но разве, при открытии тома нужна не только парольная фраза, которая расшифровывает ключ. Ключ же хранится (в шифрованном виде) в служебной области «LUKS-тома». Или я не правильно понял/прочитал?

Да, нужна парольная фраза, либо бинарный ключ, который используется вместо фразы (или одновременно — в LUKS есть семь кей-слотов). Я что пытаюсь сказать: для каждого тома при открытии придётся вводить фразу, либо предоставлять ключ (man cryptsetup). С ключами, в принципе, можно это дело и автоматизировать в некоторой степени.

Но, всё-таки, лучше уж будет известно, что используется только LUKS, чем LUKS и LVM вместе взятые.

Ну хз, лично мне факт использования LVM ни о чём особо не говорит.

/boot надо располагать обязательно в не LVM разделе?

Да, если хочешь использовать GRUB Legacy.

> Зачем давать дополнительную информацию, когда возможно хранить на диске просто бессмысленную мешанину?

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

И ещё... Говорят скорость падает. Я, кажется, уже спрашивал, но вроде про загрузку CPU. %-) Не помню.
1. Сильно ли снижает скорость доступа к диску LUKS?
2. Сильно снижает скорость LVM?
3. Сильно ли они совместно будут грузить систему?

1. /boot надо располагать обязательно в не LVM разделе?

Только для GRUB 1. LILO и GRUB 2 (его не пробовал) умеют LVM.

2. Если / располагается на разделе поверх LVM тома, никаких проблем с загрузкой не будет (не нужен никакой initrd или что-то там дополнительное)?

Правильный initrd соберётся автоматически при установке. В дальнейшем, при использовании update-initramfs, его образы будут генерироваться корректно, на основе текущей конфигурации томов.

3. Как я понял, был LVM, сейчас LVM2 и они весело несовместимы между собой. LVM2 не планируют чем-либо заменить?

Не в курсе. Думаю, что если и планируют, то очень нескоро, поскольку существенных недостатков у LVM2 нету, и по сути, он является именно улучшением/исправлением LVM1.

4. Всё-таки, меня терзают смутные сомнения. При сбоях питания, например, том LVM не может полететь? Что, если полетит? Проблем с восстановлением не оберёшься (если до этого хватило бы fsck, то что теперь)? С использованием утилит, типа Partition Magic Explorer (ну или новее), ФС на LVM будут недоступны? Какие ещё с ним могут быть проблемы?

Разрушение метаданных LVM достаточно маловероятно, кроме того, существует возможность хранить их в двух экземплярах (как таблицу FAT в одной ФС). В общем, лучше думать о ФС, а не о LVM, по моему мнению.

5. А так ли, вообще, нужен LVM, с учёт всего?

Мне нужен.

1. Сильно ли снижает скорость доступа к диску LUKS?

Кажется, я уже говорил недавно... В пределах 10% потеря скорости. Обычно даже меньше — «на глаз» я не вижу никаких тормозов, если сравнивать с системой не на LUKS.

2. Сильно снижает скорость LVM?

Не снижает. Даже если сделаешь размер экстента в 4Кб :-D

3. Сильно ли они совместно будут грузить систему?

См. выше. Почему бы просто не проверить самому?

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

Ну хз, лично мне факт использования LVM ни о чём особо не говорит.

В статейке, вообще, сферический криптоаналитик в вакууме имелся ввиду.
Про LVM не было там ничего, а додумал я уже, в связи с этой темой.
По-идее, это не важно, только ради любопытства, пофантазировать на эту тему.
Ну, например:
1. Факт наличия LVM указывает на то, что размещение ФС может быть нетипично. Т.е., если в случае отсутствия информации, нельзя было исключать наличие LVM или отсутствие LVM. Т.е. было неизвестно: это шифрованные физические разделы на которых находятся ФС «в целом виде» или это набор экстентов, по которым раскидано содержимое ФС (причём, если на нескольких дисках...). Опять же, если взять только два простых случая. Плюс, известно что используемая ОС - Linux (ещё по наличию LUKS). Логично предположить, что, если используется LVM, то, скорее всего, не используется нечто другое, типа программных рэйдов всяких и ещё чёрт знает чего.
2. LVM содержит дополнительные данные. Возможно, что по метаданным LVM есть вероятность узнать дополнительные данные о системе. Например версию ядра с определённой точностью, следовательно список возможно используемых файловых систем (ну, никто не гарантирует, что там, вообще не всё своё %-D ). Это значит, что возможно ограничиться опеределённым набором сигнатур, например. И приблизительно оперделить какой набор инструментов потребуется.
3. Плюс, как я понял, метаданные LVM содержат имена логических томов, и групп томов. Будет известна структура «верхней» ФС. Хм... Как у вас называются тома: er223weq3, s39dpo и т.п.? Или всё-таки: files, home, bckp..? Логично предположить, что человек, если он не совсем уж, будет хранить любые данные на томе home, а не томе, например rootf.

Ну и т.п., и т.д.
Вот, в общем-то всё это мои домыслы и реально что возможно, а что нет - я не знаю... Вероятно, я не прав.

Главное, что «поменять местами» LUKS и LVM не составит большого труда, потому, если нет особых причин ставить LUKS сверху, то лучше ставить снизу. :-)

> Парадокс в то, что ...
Ну да. Только в этом случае вы говорите: вероятно, я использую шифрование. Возникает вопрос: «Зачем?»
А в случае, когда информация осмысленна: я не использую шифрования, у меня столько-то разделов, такая-то система, хранятся на ней такие-то файлы, я пользуюсь такими-то программами, захожу вот на эти сайты, а так вот я провожу рабочее и свободное время. Ну и т.д.
Тут больше вопросов может возникнуть. И большей возможностей для поиска ответов. :-) И прицепиться больше возможностей (вряд ли кто подумает: «да он же честный человек»). И, всё-равно, остаётся вопрос: а не скрывает ли он что-то так хорошо, что этого не видно?
Ну, опять же, если это кому-то нужно.

> Только для GRUB 1. LILO и GRUB 2 (его не пробовал) умеют LVM.
LILO даже умеет? Хм...

Правильный initrd соберётся автоматически при установке.

В дальнейшем, при использовании update-initramfs,

его образы будут генерироваться корректно, на основе текущей конфигурации томов.

А, вообще, без initrd возможно обойтись?

Не снижает. Даже если сделаешь размер экстента в 4Кб :-D

Вот тут:
http://www.linux.org.ru/forum/general/3660395#comment-3660478
Говорили, что скорость падает...

Почему бы просто не проверить самому?

Так не просто... Надо сделать разбивку диска, поставить LVM. А, если не прокатит? Снова всё переустанавливать? Бррр.

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

Не знаю, это же обычно всё в загрузочных скриптах, и запоминать фразу там типа некому...

В статейке, вообще, сферический криптоаналитик в вакууме имелся ввиду.

<...>

Вот, в общем-то всё это мои домыслы и реально что возможно, а что нет - я не знаю... Вероятно, я не прав.

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

Главное, что «поменять местами» LUKS и LVM не составит большого труда

Боюсь, что это не так просто.

LILO даже умеет?

Блочная адресация — ему плевать на ФС и прочие тонкости.

А, вообще, без initrd возможно обойтись?

Думаю, нет. Но не знаю точно.

Говорили, что скорость падает...

Это какая-то хрень с hdparm. Он показывает такие же проседания и с LUKS. В реальности всё иначе — это подтверждают проверки с dd и прочими.

А, если не прокатит? Снова всё переустанавливать?

Сколько не спрашивай на форумах, на практике можно всегда словить нештатную ситуацию...

> Не знаю, это же обычно всё в загрузочных скриптах, и запоминать фразу там типа некому...
Ну, в смысле, написать свой скрипт. Я не знаю просто, если / тоже на LUKS как тогда...

Боюсь, что это не так просто.

Во время установки системы. :-)

> Блочная адресация — ему плевать на ФС и прочие тонкости.
Хм, он же, вроде, тоже должен найти ядро в ФС..? Или он просто запоминает адрес блока, начиная с которого оно хранится?
Но ведь ядро должно быть полностью загружено в память (к тому же оно сжато)?
А, если, например, оно фрагментировано? Или это уже проблемы ядра (его загрузчика)?

Это какая-то хрень с hdparm.

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

Сколько не спрашивай на форумах, на практике можно всегда словить нештатную ситуацию...

Ну это понятно. Однако, вероятность уменьшается.

Или он просто запоминает адрес блока, начиная с которого оно хранится?

Да. Других подробностей не знаю, проблем тоже никогда не было.

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

У меня проблем нет. Вообще не почувствовал разницы. А hdparm предназначен для физических устройств, и чёрт его знает, как он воспринимает блочные устройства LVM %)

С линуксулатором у меня работает ZFS вполне нормально. Предпочитаю использовать UFS2+SU на флэшках. На работе — NTFS и FAT32 без альтернатив.

С 1998 года не припомню случая, чтобы у меня посыпалась или ещё каким-либо образом испортиласть ФС. Дискеты?

>>> Парадокс в то, что ...

Ну да. Только в этом случае вы говорите: вероятно, я использую шифрование. Возникает вопрос: «Зачем?»

На который напрашивается ответ: «Значит есть что скрывать.»

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

Один из способов хорошо спрятать - это положить на самое видное место ))

> С линуксулатором у меня работает ZFS вполне нормально.
1. Что есть «Линуксулатор»?
2. В смысле на ZFS стоит ОС? Он же, вроде, только с FUSE? И, если в принципе, всё-таки, возможно сделать / на ZFS, всё-равно придётся с initrd делать. :-( Или нет?

С 1998 года не припомню случая, чтобы у меня посыпалась или ещё каким-либо образом испортиласть ФС. Дискеты?

HDD, причём проблема не аппаратная (если не считать any key).

> На который напрашивается ответ: «Значит есть что скрывать.»
Ну да, это понятно. Только: «скорее всего есть, что скрывать.»

Один из способов хорошо спрятать - это положить на самое видное место ))

Думаю, что если кто-то будет что-то искать, он об этом знает и, вероятно, посмотрит и видное место. Шифрование ему сильно может осложнить задачу.