@russianfedora - страница 5137

Alexander

Будет ли это влиять на скорость работы

Да, будет.

Alexander

Зависит от многих параметров, но можешь прикинуть, загуглив luks benchmark

Alexander

В определённых ситуациях может влиять существенно (например, при включенной поддержке integrity)

Où va le monde

Понял спасибо

Sergei

Да, будет.

При аппаратной поддержке там влияние ничтожное.

Sergei

В определённых ситуациях может влиять существенно (например, при включенной поддержке integrity)

Если ты про dm-integrity, то при чём он тут вообще?

Alexander

При аппаратной поддержке там влияние ничтожное.

выполнение AES дешифрования в памяти — довольно быстре, да (хотя и не незаметное).

Alexander

Если ты про dm-integrity, то при чём он тут вообще?

https://security.stackexchange.com/questions/190670/luks2-dm-integrity

Alexander

При этом crytpsetup без integrity + integritysetup != cryptsetup с integrity

Alexander

При аппаратной поддержке там влияние ничтожное.

У меня, в целом, насколько я помню, падение с cryptsetup --integrity было примерно двухкратным или даже более. Без --integrity, вроде, в полтора раза (хотя, я уже точно не помню)

Sergei

При этом crytpsetup без integrity + integritysetup != cryptsetup с integrity

dm-intergrity очевидным образом вносит оверхед, да, но шифрование-то тут при чём? Использование intergrity с dm-crypt - это даже не умолчание.

Alexander

dm-intergrity очевидным образом вносит оверхед, да, но шифрование-то тут при чём? Использование intergrity с dm-crypt - это даже не умолчание.

luks сам по себе не умолчание, и что? О чем вопрос-то?

Sergei

luks сам по себе не умолчание, и что? О чем вопрос-то?

Вопрос был о галочке "шифровать раздел" в установщике федоры. Она dm-integrity не включает вроде как.

Alexander

Вопрос был о галочке "шифровать раздел" в установщике федоры. Она dm-integrity не включает вроде как.

А, в этом случае, по идее, да, integrity у cryptsetup не вкючается. Но там всё равно оверхед на бенчмарках будет заметный.

Vasiliy Glazov

А, в этом случае, по идее, да, integrity у cryptsetup не вкючается. Но там всё равно оверхед на бенчмарках будет заметный.

А на реальную работу?

Alexander

Другое дело, какое снижение производительности допустимо в качестве платы за шифрование

Alexander

А на реальную работу?

Зависит от работы же

Vasiliy Glazov

А это снижение в скорости чтения/записи или в увеличении нагрузки на процессор?

Sergei

А на реальную работу?

Там ничтожное влияние. Яббл и Гугл вон на всех своих новых девайсах включают шиврование по-умолчанию, вероятно, полагая, что это не может негативно сказаться на UX.

Alexander

А это снижение в скорости чтения/записи или в увеличении нагрузки на процессор?

Нагрузка на проц вырастает при включении шифрования не так сильно. А вот IO, вроде, падает, заметнее.

Alexander

Но не в 2 раза, опять же.

Alexander

Там ничтожное влияние. Яббл и Гугл вон на всех своих новых девайсах включают шиврование по-умолчанию, вероятно, полагая, что это не может негативно сказаться на UX.

https://blog.cloudflare.com/speeding-up-linux-disk-encryption/ Всё не только к производительности алгоритма шифрования сводится же

Anonymous

Отличная экспертная оценка. Правда, первое не занимается шифрованием, а второе вообще к нему отношения не имеет и не влияет на производительность I/O.

Брат спасибо, я читал исследования ученых https://www.researchgate.net/publication/284897601_LVM_in_the_Linux_environment_Performance_examination

Anonymous

• LVM provides reduced level of performances when compared to non-LVM file system, which confirms H1. • Decrease in performances highly depends on the complexity of LVM configuration, thus confirming H3. LVM shows greater loading and weaker performance if realized in a more complex way, meaning that if an LVM is created from several different volumes it is possible to achieve significantly lower performances. It is also expected that the performances will further decrease if a LVM is created from volumes located on different physical disks, which was not directly tested in this paper and will be discussed in some further work. • The performance decrease depends directly on the workload, number of the required disk operations, metadata operations and number of direct file block operations (confirmation of the H4 hypothesis). • The main cause of the noticed performance decline is the feature of remapping. The remapping in the case of the LVM is performed by the DMD. This procedure is weakly compensated by the remapping caching. The obtained results confirm the H2 hypothesis.

Alexander

Брат спасибо, я читал исследования ученых https://www.researchgate.net/publication/284897601_LVM_in_the_Linux_environment_Performance_examination

К слову, я как-то в районе 2009 года нс CentOS 5 смотрел, во сколько мне обходится LVM. И получалось, что с ним производительность тогда падала в 2 раза. Впрочем, у меня задача в диск не упиралась, потому я LVM все равно заюзал для более простого управления блочными устройствами.

Andrey

интересно сравнить btrfs vs lvm vs raw disks

Alexander

интересно сравнить btrfs vs lvm vs raw disks

btrfs с lvm некорректно сравнивать, т.к. первое — это ФС

Anonymous

btrfs с lvm некорректно сравнивать, т.к. первое — это ФС

Их используют ради похожих вещей

Andrey

btrfs с lvm некорректно сравнивать, т.к. первое — это ФС

и да и нет.

Alexander

Их используют ради похожих вещей

Для каких? o_O

Andrey

ок. сравнить btrfs vs xfs+lvm и btrfs vs ext4+lvm

Anonymous

Для каких? o_O

Снапшоты и управление томами

Andrey

так тебя устроит?

Andrey

в конечном итоге конечному потребителю ПОХЕР что где, главное удобство управления томами

Andrey

и минимальные издержки в плане производительности

Alexander

Снапшоты и управление томами

Это ничего не говорит о нагрузке. Подходящие профили нагрузки у них кардинально отличаются.

Alexander

в конечном итоге конечному потребителю ПОХЕР что где, главное удобство управления томами

Был тут уже один потребитель, который хаял btrfs за то, что у него на ней виртуалка медленно работала :)

Andrey

Был тут уже один потребитель, который хаял btrfs за то, что у него на ней виртуалка медленно работала :)

значит она ему не подходит в его кейсе

Alexander

значит она ему не подходит в его кейсе

Внезапно!

Sergei

Брат спасибо, я читал исследования ученых https://www.researchgate.net/publication/284897601_LVM_in_the_Linux_environment_Performance_examination

То, что они там намеряли, даже близко не похоже на результаты ни одного другого источника. Возможно, это потому, что они просто устарели >32bit Linux ext3 file system with kernel version 2.6

Anonymous

То, что они там намеряли, даже близко не похоже на результаты ни одного другого источника. Возможно, это потому, что они просто устарели >32bit Linux ext3 file system with kernel version 2.6

Покажи, пожалуйста, источник, в котором написано, что при использовании LVM нет оверхеда для I/O

Anonymous

Отвергаешь — предлагай

Alexander

То, что они там намеряли, даже близко не похоже на результаты ни одного другого источника. Возможно, это потому, что они просто устарели >32bit Linux ext3 file system with kernel version 2.6

Да, староват сетап. А что за другой источник?

Sergei

Покажи, пожалуйста, источник, в котором написано, что при использовании LVM нет оверхеда для I/O

Я не писал, что его нет. Я высказал недоверие к достоверности результатов, в котором он даёт почти двукратную разницу.

Anonymous

Я не писал, что его нет. Я высказал недоверие к достоверности результатов, в котором он даёт почти двукратную разницу.

Anonymous

Чем крыть будете?

Alexander

Я не писал, что его нет. Я высказал недоверие к достоверности результатов, в котором он даёт почти двукратную разницу.

> в котором он даёт почти двукратную разницу. Я исследование не открывал, но это вполне соотносится с моим опытом в похожих условиях (правда, ОС была 64-битная). Другое дело, что сейчас уже больше 10 лет прошло и ситуация, скорее всего, совсем иная.

Sergei

Чем крыть будете?

Например, тем, что я имел в виду "в некотором приближении". Как и ты, говоря про LUKS (dm-crypt, видимо), который тоже вроде как некоторый оверхед вносит, но можно считать, что нет.

Anonymous

Например, тем, что я имел в виду "в некотором приближении". Как и ты, говоря про LUKS (dm-crypt, видимо), который тоже вроде как некоторый оверхед вносит, но можно считать, что нет.

Ну его нет практически если у тебя AES инструкции есть

Sergei

Ну его нет практически если у тебя AES инструкции есть

Он есть. Но очень мал. Как и у LVM. Вот и я имел в виду практически.

Sergei

> в котором он даёт почти двукратную разницу. Я исследование не открывал, но это вполне соотносится с моим опытом в похожих условиях (правда, ОС была 64-битная). Другое дело, что сейчас уже больше 10 лет прошло и ситуация, скорее всего, совсем иная.

Если мне не изменяет память, за это время вообще роль device mapper'а в ядре успела измениться и через него теперь работают чуть ли не все блочные устройства.

Alexander

Если мне не изменяет память, за это время вообще роль device mapper'а в ядре успела измениться и через него теперь работают чуть ли не все блочные устройства.

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

Sergei

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

Сейчаса что только не через него работает. Разве что обычные разделы?

Alexander

Сейчаса что только не через него работает. Разве что обычные разделы?

mdraid все еще сам по себе (хотя и несколько больше интегрирован с dm, нежели ранее).

Sergei

mdraid все еще сам по себе (хотя и несколько больше интегрирован с dm, нежели ранее).

Разве?

Alexander

Разве?

Да. Хотя они с dm и лежат в одном каталоге, у mdraid-а своя инфраструктура.

Sergei

Да. Хотя они с dm и лежат в одном каталоге, у mdraid-а своя инфраструктура.

А вообще вроде логично, dm не может мапить логические блоки в физические за mdraid, если только raid не реализован в самом dm.

Alexander

А вообще вроде логично, dm не может мапить логические блоки в физические за mdraid, если только raid не реализован в самом dm.

им обоим, в общем-то, плевать на "физическость" блоков. Можно собирать как dm поверх md (lvm на raid-е), так и md поверх md (raid LV в lvm). Просто dm — это универсальный фреймворк для построения блочных устройств в ядре (у которого, к слову, есть собственные реализации некоторых вариантов raid-а, но они почти не используются), а md — специализированная подсистема для RAID, которую не закопали в пользу DM просто потому что она намного эффективнее.

Sergei

им обоим, в общем-то, плевать на "физическость" блоков. Можно собирать как dm поверх md (lvm на raid-е), так и md поверх md (raid LV в lvm). Просто dm — это универсальный фреймворк для построения блочных устройств в ядре (у которого, к слову, есть собственные реализации некоторых вариантов raid-а, но они почти не используются), а md — специализированная подсистема для RAID, которую не закопали в пользу DM просто потому что она намного эффективнее.

Ну, я имел в виду "нижний" и "верхний" слой, скорее. Нижний, как правило, физический (хотя в случае lvm поверх md - нет).

Alexander

Ну, я имел в виду "нижний" и "верхний" слой, скорее. Нижний, как правило, физический (хотя в случае lvm поверх md - нет).

Там нет четких ролей "нижний" и "верхний". Можно делать ставить их и так и эдак в зависимости от задач.

Sergei

Там нет четких ролей "нижний" и "верхний". Можно делать ставить их и так и эдак в зависимости от задач.

dm всё равно так или иначе мапит одно блочное устройство в другое(ие). Вроде даже в его терминологии они называются physical и virtual.

Où va le monde

Кто юзает кде у вас была такая штука когда переключаешь язык,в центре экрана выскакивает квадратное окошко типа на какой язык переключился?