The OpenNET Project / Index page

[ новости /+++ | форум | теги | ]



Вариант для распечатки  
Пред. тема | След. тема 
Форум Разговоры, обсуждение новостей
Режим отображения отдельной подветви беседы [ Отслеживать ]

Оглавление

Для файловой системы Ext4 представлена поддержка шифрования, opennews (ok), 13-Апр-15, (0) [смотреть все]

Сообщения [Сортировка по времени | RSS]


2. "Для файловой системы Ext4 представлена поддержка шифрования"  +1 +/
Сообщение от Аноним (-), 13-Апр-15, 13:18 
Полезно конечно, но почему не компрессию? Оно ж намного полезнее, потому что согласен с мнением, что шифровать правильнее всё блочное устройство.
Ответить | Правка | Наверх | Cообщить модератору

4. "Для файловой системы Ext4 представлена поддержка шифрования"  +/
Сообщение от anonimus (?), 13-Апр-15, 13:23 
Кстати интересно как код будет написан, может можно будет заменить функцию шифрования функцией сжатия… с небольшим допилом…
Ответить | Правка | Наверх | Cообщить модератору

5. "Для файловой системы Ext4 представлена поддержка шифрования"  –1 +/
Сообщение от 3draven (ok), 13-Апр-15, 13:31 
Да, туда бу компрессию и снапшоты и я бы послал btrfs :)
Ответить | Правка | К родителю #2 | Наверх | Cообщить модератору

7. "Для файловой системы Ext4 представлена поддержка шифрования"  +1 +/
Сообщение от Анончик (?), 13-Апр-15, 13:34 
> Да, туда бу компрессию и снапшоты и я бы послал btrfs :)

LVM?

Ответить | Правка | Наверх | Cообщить модератору

8. "Для файловой системы Ext4 представлена поддержка шифрования"  +/
Сообщение от 3draven (ok), 13-Апр-15, 13:37 
>> Да, туда бу компрессию и снапшоты и я бы послал btrfs :)
> LVM?

Сжатие?

Ответить | Правка | Наверх | Cообщить модератору

15. "Для файловой системы Ext4 представлена поддержка шифрования"  +1 +/
Сообщение от asdasd (?), 13-Апр-15, 15:01 
Извращенцы создают ZFS пул и в нем создают ext4 o_O
Ответить | Правка | Наверх | Cообщить модератору

38. "Для файловой системы Ext4 представлена поддержка шифрования"  –1 +/
Сообщение от PnDx (ok), 13-Апр-15, 18:56 
Не такие уж и извращенцы. Словить dead-lock/панику на lvm - как 2 пальца, по моему довольно-таки богатому опыту совокупления со всякими виртуализаторами.
  Пример: qcow-контейнер + quemu nbd. Глучный nbd валится - смонтированный с него lvm встаёт колом.
  zpool как бы не постабильнее оказался, даже на linux...
Ответить | Правка | Наверх | Cообщить модератору

45. "Для файловой системы Ext4 представлена поддержка шифрования"  +/
Сообщение от pavel_simple (ok), 13-Апр-15, 20:38 
последовательность команд можно , а то что-то не сильно понятно чем вы там lvm залочили
Ответить | Правка | Наверх | Cообщить модератору

59. "Для файловой системы Ext4 представлена поддержка шифрования"  +/
Сообщение от PnDx (ok), 14-Апр-15, 10:36 
> последовательность команд можно , а то что-то не сильно понятно чем вы
> там lvm залочили

1. Подключаем контейнер на nbd, внутри чсх lvm, с него монтируем том.
#modprobe nbd max_part=63
#qemu-nbd -c /dev/nbd0 /mnt/images/130/vm-130-disk-1.qcow2
nbd: registered device at major 43
nbd0: p1 p2 < p5 >

2. Монтируем, что-то делаем (копируем файло), nbd рушится:
#mount /dev/nbd0p1 /nbd0/
#cd /nbd0/ && tar -cf www.tgz var/www/
EXT3-fs (nbd0p1): 5 orphan inodes deleted
EXT3-fs (nbd0p1): recovery complete
EXT3-fs (nbd0p1): mounted filesystem with ordered data mode
nbd (pid 117717: qemu-nbd) got signal 9

УСЁ. Для системы это теперь "Buffer I/O error on device dm-3", со стороны lvm - любая операция _намертво_ блокируется попыткой прочитать из device mapper'а.

Данный пример дёрнул из debian 6.0.7 + proxmox.

Ответить | Правка | Наверх | Cообщить модератору

67. "Для файловой системы Ext4 представлена поддержка шифрования"  +/
Сообщение от pavel_simple (ok), 14-Апр-15, 20:51 
>[оверквотинг удален]
> #mount /dev/nbd0p1 /nbd0/
> #cd /nbd0/ && tar -cf www.tgz var/www/
> EXT3-fs (nbd0p1): 5 orphan inodes deleted
> EXT3-fs (nbd0p1): recovery complete
> EXT3-fs (nbd0p1): mounted filesystem with ordered data mode
> nbd (pid 117717: qemu-nbd) got signal 9
> УСЁ. Для системы это теперь "Buffer I/O error on device dm-3", со
> стороны lvm - любая операция _намертво_ блокируется попыткой прочитать из device
> mapper'а.
> Данный пример дёрнул из debian 6.0.7 + proxmox.

эмммм... proxmox использует сильно специфичное ядро

вот например debian wheeze + backport
# uname -srv
Linux 3.16.0-0.bpo.4-amd64 #1 SMP Debian 3.16.7-ckt7-1~bpo70+1 (2015-04-07)
modprobe nbd  max_part=63
qemu-nbd -c /dev/nbd0 test.img
fdisk /dev/nbd0
ls -la /dev/nbd0p1
brw-rw---T 1 root disk 43, 1 Apr 14 22:28 /dev/nbd0p1
mkfs.ext4 /dev/nbd0p1
mount /dev/nbd0p1 /mnt/
cd /mnt/
dd if=/dev/urandom of=/mnt/test.file bs=1k count=100
cat >>test.file <<EOF
печатаем либерду и одновременно kill -KILL на qemu-nbd

EOF
-su: test.file: Read-only file system

dmesg

[10047.450190] nbd: registered device at major 43
[10091.031143]  nbd0: unknown partition table
[10108.135157]  nbd0: p1
[10130.033100] block nbd0: Other side returned error (22)
[10130.033112] end_request: I/O error, dev nbd0, sector 34816
[10152.637827] EXT4-fs (nbd0p1): mounted filesystem with ordered data mode. Opts: (null)
[10273.090016] nbd (pid 4693: qemu-nbd) got signal 9
[10273.090032] block nbd0: shutting down socket
[10273.090043] block nbd0: Receive control failed (result -4)
[10273.090148] block nbd0: queue cleared
[10274.763185] block nbd0: Attempted send on closed socket
[10274.763198] end_request: I/O error, dev nbd0, sector 61704
[10274.763242] block nbd0: Attempted send on closed socket
[10274.763247] end_request: I/O error, dev nbd0, sector 61960
[10274.763270] block nbd0: Attempted send on closed socket
[10274.763274] end_request: I/O error, dev nbd0, sector 62216
[10274.763296] block nbd0: Attempted send on closed socket
[10274.763299] end_request: I/O error, dev nbd0, sector 62472
[10274.763320] block nbd0: Attempted send on closed socket
[10274.763324] end_request: I/O error, dev nbd0, sector 62728
[10274.763345] block nbd0: Attempted send on closed socket
[10274.763349] end_request: I/O error, dev nbd0, sector 62984
[10274.763370] block nbd0: Attempted send on closed socket
[10274.763374] end_request: I/O error, dev nbd0, sector 63240
[10274.763395] block nbd0: Attempted send on closed socket
[10274.763398] end_request: I/O error, dev nbd0, sector 63496
[10274.763419] block nbd0: Attempted send on closed socket
[10274.763423] end_request: I/O error, dev nbd0, sector 63752
[10274.763444] block nbd0: Attempted send on closed socket
[10274.763448] end_request: I/O error, dev nbd0, sector 64008
[10274.763469] block nbd0: Attempted send on closed socket
[10274.763490] block nbd0: Attempted send on closed socket
[10274.763512] block nbd0: Attempted send on closed socket
[10274.763533] block nbd0: Attempted send on closed socket
[10274.763554] block nbd0: Attempted send on closed socket
[10274.763575] block nbd0: Attempted send on closed socket
[10280.100946] block nbd0: Attempted send on closed socket
[10280.100962] blk_update_request: 6 callbacks suppressed
[10280.100968] end_request: I/O error, dev nbd0, sector 3672472
[10280.100978] Aborting journal on device nbd0p1-8.
[10280.101001] block nbd0: Attempted send on closed socket
[10280.101005] end_request: I/O error, dev nbd0, sector 3672064
[10280.101011] Buffer I/O error on device nbd0p1, logical block 458752
[10280.101015] lost page write due to I/O error on nbd0p1
[10280.101041] JBD2: Error -5 detected when updating journal superblock for nbd0p1-8.
[10281.715909] block nbd0: Attempted send on closed socket
[10281.715920] end_request: I/O error, dev nbd0, sector 2048
[10281.715927] Buffer I/O error on device nbd0p1, logical block 0
[10281.715931] lost page write due to I/O error on nbd0p1
[10281.715966] EXT4-fs error (device nbd0p1): ext4_journal_check_start:56: Detected aborted journal
[10281.715973] EXT4-fs (nbd0p1): Remounting filesystem read-only
[10281.715978] EXT4-fs (nbd0p1): previous I/O error to superblock detected
[10281.715993] block nbd0: Attempted send on closed socket
[10281.715997] end_request: I/O error, dev nbd0, sector 2048
[10281.716001] Buffer I/O error on device nbd0p1, logical block 0
[10281.716005] lost page write due to I/O error on nbd0p1

# pvs
  /dev/nbd0p1: read failed after 0 of 4096 at 4293853184: Input/output error
  /dev/nbd0p1: read failed after 0 of 4096 at 4293910528: Input/output error
  /dev/nbd0p1: read failed after 0 of 4096 at 0: Input/output error
  /dev/nbd0p1: read failed after 0 of 4096 at 4096: Input/output error
  PV         VG     Fmt  Attr PSize   PFree
  /dev/sda5  ***    lvm2 a--  295.52g 4.08g
  /dev/sdc3  ***    lvm2 a--  111.82g    0
  /dev/sdc5  ***    lvm2 a--   52.52g 1.37g
# lvs
  /dev/nbd0p1: read failed after 0 of 4096 at 4293853184: Input/output error
  /dev/nbd0p1: read failed after 0 of 4096 at 4293910528: Input/output error
  /dev/nbd0p1: read failed after 0 of 4096 at 0: Input/output error
  /dev/nbd0p1: read failed after 0 of 4096 at 4096: Input/output error
  LV          VG     Attr     LSize   Pool Origin Data%  Move Log Copy%  Convert
  ***      ***    -wi-ao-- 136.97g                                          
  ***      ***    -wi-a---  14.00g                                          
  ***      ***    -wi-ao--  12.00g                                          
  ***      ***    -wi-ao-- 281.43g                                          
  ***      ***    -wi-ao--  10.00g                                          
# lvcreate -n asd -L 4M ***
mkfs.ext4 /dev/mapper/***-asd
mkdir /tmp/asd
mount /dev/mapper/***-asd /tmp/asd/
cd /tmp/asd
echo 1> test.file
cd -
umount /tmp/asd/
lvremove /dev/***/asd
  /dev/nbd0p1: read failed after 0 of 4096 at 4293853184: Input/output error
  /dev/nbd0p1: read failed after 0 of 4096 at 4293910528: Input/output error
  /dev/nbd0p1: read failed after 0 of 4096 at 0: Input/output error
  /dev/nbd0p1: read failed after 0 of 4096 at 4096: Input/output error
Do you really want to remove active logical volume asd? [y/n]: y
  Logical volume "asd" successfully removed
qemu-nbd -c /dev/nbd0 test.img
mount -o remount,rw /mnt/
mount: cannot remount block device /dev/nbd0p1 read-write, is write-protected
# blockdev --setrw /dev/nbd0
# blockdev --setrw /dev/nbd0p1
# mount -o remount,rw /mnt/
mount: cannot remount block device /dev/nbd0p1 read-write, is write-protected

что собственно логично.
НО никакого лока на nbd у lvm нет, или нет уже, а то ядро которое идёт с proxmox'ом оставляет много лучшего, как и сама система  (proxmox) в целом. (чего только стоит распад кластера при недоступности удалённой fs (например nfs))

Ответить | Правка | Наверх | Cообщить модератору

68. "Для файловой системы Ext4 представлена поддержка шифрования"  +/
Сообщение от PnDx (ok), 14-Апр-15, 21:11 
> [10273.090016] nbd (pid 4693: qemu-nbd) got signal 9

  Как в анекдоте, "я 'рад, что по предыдущему вопросу у Вас воз'ражений нет".
(nbd до сих пор валится)
  Ну а что lvm постепенно допиливают - оно не может не радовать. Те же thin volumes и т.п. постепенно перестают быть рисковыми технологиями.
  Правда, у zpool пока остаётся киллер-фича в виде репликации журналов. У lvm видел на эту тему чью-то ученическую поделку, и только.

* Проблема в данном раскладе не столько в proxmox'е (хотя гуано, согласен, но работать сплошь и рядом приходится с тем, что какой-нибудь пионер вклячил до тебя), сколько в старых ядрах. На rhel'5x-образных ещё и паника ловилась тупо при дёргании снапшотов.

Ответить | Правка | Наверх | Cообщить модератору

69. "Для файловой системы Ext4 представлена поддержка шифрования"  +/
Сообщение от pavel_simple (ok), 14-Апр-15, 21:15 
>> [10273.090016] nbd (pid 4693: qemu-nbd) got signal 9
>   Как в анекдоте, "я 'рад, что по предыдущему вопросу у
> Вас воз'ражений нет".
> (nbd до сих пор валится)

kill -KILL не о чём не говорит? или таки пейсатель?

>   Ну а что lvm постепенно допиливают - оно не может
> не радовать. Те же thin volumes и т.п. постепенно перестают быть
> рисковыми технологиями.
>   Правда, у zpool пока остаётся киллер-фича в виде репликации журналов.
> У lvm видел на эту тему чью-то ученическую поделку, и только.

а вы из этих...

> * Проблема в данном раскладе не столько в proxmox'е (хотя гуано, согласен,
> но работать сплошь и рядом приходится с тем, что какой-нибудь пионер
> вклячил до тебя), сколько в старых ядрах. На rhel'5x-образных ещё и
> паника ловилась тупо при дёргании снапшотов.

Ответить | Правка | Наверх | Cообщить модератору

72. "Для файловой системы Ext4 представлена поддержка шифрования"  +/
Сообщение от PnDx (ok), 15-Апр-15, 11:39 
> kill -KILL не о чём не говорит? или таки пейсатель?

  Ну извините. Я по Вашей простыне наискось пробежался. Свою, заметьте, не поленился отфильтровать.

>> У lvm видел на эту тему чью-то ученическую поделку, и только.
> а вы из этих...

  Из инженеров, собирающих заказанный продукт из имеющегося, ага.
Специально для эстетов, нашёл: https://github.com/mpalmer/lvmsync
Оно развивается и вполне разумно задумано, но ruby в данном секторе лично мне доставляет.

  Там ещё есть ссылка на реально ученическую работу blocksync.py - оно изначально КС по блокам считало через adler32 https://gist.github.com/rcoup/1338263/revisions. Теперь автор повзрослел и поправил на sha /а современный rsync до сих пор md4 считает afaik/.
  Мда. Когда я обнаружил эту питонятину в одном довольно таки серьёзном проекте, получил неслабый заряд позитива. А отсмеявшись, воткнул на его место патченный rsync, который btw тоже не фонтан. Но уж что было...

Ответить | Правка | Наверх | Cообщить модератору

73. "Для файловой системы Ext4 представлена поддержка шифрования"  +/
Сообщение от pavel_simple (ok), 15-Апр-15, 14:55 
>> kill -KILL не о чём не говорит? или таки пейсатель?
>   Ну извините. Я по Вашей простыне наискось пробежался. Свою, заметьте,
> не поленился отфильтровать.

я и говорю не читатель, потому что моя простыня не большая это раз, а два это то что необходимое вам в подтверждение вы нашли быстро, а из этих вы потому что инженер в первую очередь пошел-бы искать причины падения вполне-себе userspace-ного сервиса по сигналу KILL, что делается в Linux давольно просто. Вместо поиска проблем с nbd вы стали лечить и жаловаться на симптомы (lvm).

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

инженер из говна конфету не лепит -- для этого есть другие люди.
>[оверквотинг удален]
> Оно развивается и вполне разумно задумано, но ruby в данном секторе лично
> мне доставляет.
>   Там ещё есть ссылка на реально ученическую работу blocksync.py -
> оно изначально КС по блокам считало через adler32 https://gist.github.com/rcoup/1338263/revisions.
> Теперь автор повзрослел и поправил на sha /а современный rsync до
> сих пор md4 считает afaik/.
>   Мда. Когда я обнаружил эту питонятину в одном довольно таки
> серьёзном проекте, получил неслабый заряд позитива. А отсмеявшись, воткнул на его
> место патченный rsync, который btw тоже не фонтан. Но уж что
> было...

мне эта тема неинтересна - я не вижу где подобные техники можно применить (особенно если это делается как в приведённых примерах), но для для того чтобы иметь возможность копировать изменённые блоки с lv давно есть dm-era https://github.com/jthornber/thin-provisioning-tools

в частности у разрабов всевозможных утилит архивирования данная техника может быть применена по алгоритму
1. получаем изменённые блоки
2. через lib2fs/debug2fs получаем имя файла/ов находящегося в данном блоке
3. проводим синхронизацию.

Ответить | Правка | Наверх | Cообщить модератору

66. "Для файловой системы Ext4 представлена поддержка шифрования"  +2 +/
Сообщение от iZEN (ok), 14-Апр-15, 20:32 
> Извращенцы создают ZFS пул и в нем создают ext4 o_O

ada0 <-> GEOM ELI <-> zpool <-> ZVOL (с установленным свойством сжатия LZ4) <-> ext4 чем не вариант для бедных линуксоидов, озабоченных проблемой шифрования и сжатия данных на ФС, которая не поддерживает ни того, ни другого?

Ответить | Правка | К родителю #15 | Наверх | Cообщить модератору

71. "Для файловой системы Ext4 представлена поддержка шифрования"  +/
Сообщение от Аноним (-), 15-Апр-15, 04:24 
Как не пили ext4 он неисправим!
Ответить | Правка | Наверх | Cообщить модератору

76. "Для файловой системы Ext4 представлена поддержка шифрования"  +/
Сообщение от kurokaze (ok), 18-Апр-15, 11:11 
толсто
Ответить | Правка | Наверх | Cообщить модератору

52. "Для файловой системы Ext4 представлена поддержка шифрования"  –1 +/
Сообщение от maximnik0 (?), 13-Апр-15, 22:09 
>>> Да, туда бу компрессию и снапшоты и я бы послал btrfs :)
>> LVM?
> Сжатие?

Были падчи для ext2 и ext3 с потдержкой сжатия - до версии ядра 2.6.6 входили в ядра от
Zen-kernel и  Кона Коливаса ,из за невостребованости потдержка прекращена :-(

Проект  Next3 - ext3/4 с снапшотами ,обновлений нет  3 года  Ж-(
Проект ext3cow -ext3 c снапшотами ,обновлений нет уже 7 лет ...

Ответить | Правка | К родителю #8 | Наверх | Cообщить модератору

6. "Для файловой системы Ext4 представлена поддержка шифрования"  +1 +/
Сообщение от Анончик (?), 13-Апр-15, 13:33 
Правильнее-то правильнее.
Но есть шанс, что при выборе "Допилить аппаратный загрузчик для поддержки полного шифрования девайса" и "ничего не делать, оставить всё как сейчас" большинство Андроидных вендоров предпочтёт последнее.

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

Ответить | Правка | К родителю #2 | Наверх | Cообщить модератору

9. "Для файловой системы Ext4 представлена поддержка шифрования"  +1 +/
Сообщение от Аноним (-), 13-Апр-15, 14:16 
А кто-то сказал, что _пользователю_ дадут шифровать данные?
Ответить | Правка | Наверх | Cообщить модератору

24. "Для файловой системы Ext4 представлена поддержка шифрования"  +/
Сообщение от Аноним (-), 13-Апр-15, 17:04 
Компрессия уже в ssd и если её и развивать то уж проще в устройствах.
Ответить | Правка | К родителю #2 | Наверх | Cообщить модератору

25. "Для файловой системы Ext4 представлена поддержка шифрования"  +/
Сообщение от rshadow (ok), 13-Апр-15, 17:05 
> шифровать правильнее всё блочное устройство

Правильнее для чего? Я лично вижу много пользовательских проблем: забыли защитить файл и т.д. А в остальном только плюсы.

> Ключ шифрования определяется во время монтирования ФС

Плохо что не при первом обращении. Получается опять монтирование и запрос пароля для home при входе в систему.

Ответить | Правка | К родителю #2 | Наверх | Cообщить модератору

Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема




Партнёры:
PostgresPro
Inferno Solutions
Hosting by Hoster.ru
Хостинг:

Закладки на сайте
Проследить за страницей
Created 1996-2024 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру