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

"Для файловой системы Ext4 представлена поддержка шифрования"	+/–
Сообщение от opennews (ok), 13-Апр-15, 13:04
Разработчик файловой системы Ext4 Теодор Тсо (Theodore Ts'o), работающий в компании Google, представил (http://thread.gmane.org/gmane.comp.file-systems.ext4/48206) серию патчей, добавляющих поддержку шифрования в файловую систему Ext4. Предполагается что данные патчи войдут в состав следующего релиза Android "M". Код с реализацией поддержки шифрования подготовлен совместно с Майклом Хэлкроу (Michael Halcrow (https://plus.google.com/100085619228295047055/posts)), автором eCryptFS (http://ecryptfs.org/). Дополнительно отмечается, что подготовленные патчи могут послужить основой для поддержки шифрования в файловой системе F2FS. Реализация подразумевает (https://docs.google.com/document/d/1ft26lUQyuSpiu6VleP70_npa... предоставление возможности шифрования отдельных частей ФС, например, отдельных директорий. При этом шифруется только содержимое и имена файлов, а метаданные о файлах, такие как размер и права доступа, остаются видимыми. Ключ шифрования определяется во время монтирования ФС. Настройки шифрования выполняются посредством xattr. Новые файлы или директории могут быть зашифрованы отдельно или автоматически, в случае если они создаются в уже зашифрованной директории. Зашифрованные данные размещаются с использованием метода AES-256-XTS, для имён файлов применяется AES-256-CBC. Для каждого inode генерируется свой уникальный 521-битовый ключ шифрования, что позволяет блокировать атаки, в ситуациях когда злоумышленнику известна часть зашифрованного содержимого.  По сравнению с применением надстроек, таких как dm-crypt и  eCryptFS, интеграция поддержки шифрования непосредственно в драйвер ФС, позволяет добиться более высокой производительности, использовать текущий код для обработки прав доступа и обеспечить возможность работы с незашифрованной частью файлов на устаревших системах. URL: http://www.heise.de/open/meldung/Linux-Dateisysteme-Transpar... Новость: https://www.opennet.ru/opennews/art.shtml?num=42028
Ответить | Правка | Cообщить модератору

Сообщения

[Сортировка по ответам | RSS]

1. Сообщение от A.Stahl (ok), 13-Апр-15, 13:04	+1 +/–
Не дело это. Нечего шифрованию делать в коде ФС -- шифрование это не обязанность ФС. В случае необходимости это должно делаться внешними средствами. Чего только не придумают на волне истерии с АНБ, и прочими Б.
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #3, #10, #21, #27, #58

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

3. Сообщение от Аноним (-), 13-Апр-15, 13:20	–4 +/–
так это анб в истерике и придумало, а то не получается с лукса и трукрипта тырить данные народа
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #1

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

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

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

7. Сообщение от Анончик (?), 13-Апр-15, 13:34	+1 +/–
> Да, туда бу компрессию и снапшоты и я бы послал btrfs :) LVM?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #5 Ответы: #8

8. Сообщение от 3draven (ok), 13-Апр-15, 13:37	+/–
>> Да, туда бу компрессию и снапшоты и я бы послал btrfs :) > LVM? Сжатие?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #7 Ответы: #15, #52

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

10. Сообщение от ABATAPA (ok), 13-Апр-15, 14:22	+/–
Причём тут АНБ? Даже в самой новости видно - где это нужно: шифрование данных устройств на Android. Сейчас это делается через ту самую "надстройку". А про "не дело" - наверное, судить разработчику и компании, которая оплатила его труд, а не Вам?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #1 Ответы: #17

11. Сообщение от Templar3d (ok), 13-Апр-15, 14:39	+/–
Лучше поздно, чем никогда.
Ответить | Правка | Наверх | Cообщить модератору

12. Сообщение от Mike Lee (?), 13-Апр-15, 14:40	–1 +/–
> Реализация подразумевает предоставление возможности шифрования отдельных частей ФС. > Ключ шифрования определяется во время монтирования ФС. т.е. зашифровать с разными ключами разные директории не получится.
Ответить | Правка | Наверх | Cообщить модератору

15. Сообщение от asdasd (?), 13-Апр-15, 15:01	+1 +/–
Извращенцы создают ZFS пул и в нем создают ext4 o_O
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #8 Ответы: #38, #66

17. Сообщение от A.Stahl (ok), 13-Апр-15, 15:34	–6 +/–
Причём тут Android? Что, Ext* нигде кроме как в Android не используется? >судить разработчику и компании, которая оплатила его труд, а не Вам? При формировании своего мнения о каком-либо событии я не заглядываю в платёжные ведомости, штатные расписания и прочее. И вообще считаю эту информацию бесполезной при формировании своего мнения.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #10 Ответы: #20, #40, #53

18. Сообщение от Аноним (-), 13-Апр-15, 15:37	+/–
Ну и ZSTD сжатие тогда уж можно было запилить, зачем мелочиться?
Ответить | Правка | Наверх | Cообщить модератору

19. Сообщение от Нанобот (ok), 13-Апр-15, 15:40	–1 +/–
а юзер вася сможет, не имея прав админа, зашифровать файлы в своей домашней директории (на подобии виндовс)?
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #23

20. Сообщение от прохожий (?), 13-Апр-15, 16:05	–2 +/–
продолжайте информировать о своем мнении, оно очень важно для нас
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #17 Ответы: #32

21. Сообщение от Аноним (-), 13-Апр-15, 16:57	+/–
А компрессия? А в чём различие?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #1 Ответы: #22, #26

22. Сообщение от Aceler (ok), 13-Апр-15, 17:01	+3 +/–
А снапшоты? А LVM? А передача данных по сети? :-) У человека представления о ФС времён DOS, не трогайте его.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #21

23. Сообщение от Aceler (ok), 13-Апр-15, 17:03	+/–
> а юзер вася сможет, не имея прав админа, зашифровать файлы в своей > домашней директории (на подобии виндовс)? В рамках данной технологии нет. Ибо ключ определяется на моменте монтирования, а отмонтировать сам себе хомяк юзер не сможет. А сделать флешку с шифрованием, наверное, сможет, т.к. монтировать права у него будут.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #19

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

25. Сообщение от rshadow (ok), 13-Апр-15, 17:05	+/–
> шифровать правильнее всё блочное устройство Правильнее для чего? Я лично вижу много пользовательских проблем: забыли защитить файл и т.д. А в остальном только плюсы. > Ключ шифрования определяется во время монтирования ФС Плохо что не при первом обращении. Получается опять монтирование и запрос пароля для home при входе в систему.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #2

26. Сообщение от правдоруб (?), 13-Апр-15, 17:07	–1 +/–
компрессию и дедупликацию тоже нужно делать отдельными продуктами с переносимостью на уровне encfs
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #21 Ответы: #75, #78

27. Сообщение от Crazy Alex (ok), 13-Апр-15, 17:07	+/–
Или хотя бы это должен быть отдельный слой, который может быть включён поверх любой FS. А так - костыль, иначе и не назвать. Хотя сама затея - правильная. Смартфон - это ПРИВАТНОЕ хранилище, практически продолжение головы. Он, по идее, вообще не должен быть рассчитан на доступ кого-либо кроме хозяина.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #1 Ответы: #46

31. Сообщение от Аноним (-), 13-Апр-15, 18:08	–1 +/–
Метаданные не шифруются, чтобы полиция видела факт наличия файла и при желании смогла нагнуть юзера. Получается, для простых людей данные недоступны, а для силовых структур - доступны. И овцы целы, волки сыты.
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #33, #35

32. Сообщение от A.Stahl (ok), 13-Апр-15, 18:09	+11 +/–
Ты будешь ржать, но комментарии к статье предусмотрены именно для того, что люди выражали своё мнение. Так что сдуй щёки и засунь свой сарказм... обратно.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #20 Ответы: #60

33. Сообщение от Аноним (-), 13-Апр-15, 18:36	+/–
Давай, у меня есть директория, в которой пара  тысяч файлов с ннеодинаковыми именами и зашифрованным содержимым. Ты можешь прочитать права и время доступа к ним. Нагни меня! Нагни меня полностью!
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #31 Ответы: #36, #41

35. Сообщение от Аноним (-), 13-Апр-15, 18:38	+1 +/–
> При этом шифруется только содержимое и имена файлов Итого спецслужбы увидят, что 8-го марта был создан какой-то файлик размером 10 килобайт. А что это - поздравление любимой или код запуска ракет - они не увидят.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #31 Ответы: #37

36. Сообщение от Аноним (-), 13-Апр-15, 18:44	+2 +/–
Когда тебя ТАМ станут нагибать, главное, что-бы кто-то ещё хотел тебя слушать, как ты будешь верещать, что сейчас сейчас, я всё вам расшифрую. Потому что, если всем будет уже пофигу, то твоё дело - совсем дрянь.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #33

37. Сообщение от Аноним (-), 13-Апр-15, 18:45	+/–
Ещё они увидят, что "поздравление любимой" зашифровано.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #35 Ответы: #39

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

39. Сообщение от Аноним (-), 13-Апр-15, 19:07	+/–
> зашифровано Поздравляю любимая/любимый! И да, не забудь купить рулона 4 туалетной бумаги, пачку (на 250 грамм) масла ... <далее, на что хватит фантазии - за классику типа "книжка, страница, строка" я уж молчу> И помни! Одинадцатого, рейсом в 12:10, прилетает твоя тетя Оба-на, ее нужно забрать! Смотри, забудешь - будешь успокаивать сам!
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #37

40. Сообщение от Тот самый с плаката (?), 13-Апр-15, 19:16	–5 +/–
> Что, Ext* нигде кроме как в Android не используется? Поставим вопрос иначе: есть ли смысл использовать Ext* где-либо в принципе, если есть файловые системы лучше по всем релевантным параметрам?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #17 Ответы: #51, #55, #62

41. Сообщение от Аноним (-), 13-Апр-15, 19:20	+/–
>Нагни меня! Нагни меня полностью! Я медленно подключаю свой большой паяльник к сети и он начинает нагреваться... Всё жарче и жарче...
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #33

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

46. Сообщение от Аноним (-), 13-Апр-15, 20:43	+/–
> Он, по идее, вообще не должен быть рассчитан на > доступ кого-либо кроме хозяина. а также разработчиков ОС, разработчиков приложений, провайдеров сервисов, разработчков чипов, контрольных органов, органов контролирующих контрольных.. И права отрубить у пользователя на всякий случай. А то ишь чего ещё задумал! Ключи ему разрешай в Secure boot добавлять! Ишь чего надумал..
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #27 Ответы: #48, #49, #56

47. Сообщение от CrazyAlex25 (ok), 13-Апр-15, 20:47	–1 +/–
Лучше б продвинули сжатие на лету
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #57

48. Сообщение от vbv (ok), 13-Апр-15, 20:49	+/–
А про root на android я вообще молчу.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #46

49. Сообщение от Аноним (-), 13-Апр-15, 20:56	+/–
"Ишь ты!" https://www.youtube.com/watch?v=BNkRSETRkaU&feature=youtu.be... э-э.. сейчас уже таких не снимают :-)
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #46

50. Сообщение от Аноним (-), 13-Апр-15, 21:39	–1 +/–
>> Предполагается что данные патчи войдут в состав следующего релиза Android "M" а в ванильном ядре будет?
Ответить | Правка | Наверх | Cообщить модератору

51. Сообщение от Аноним (-), 13-Апр-15, 22:04	+3 +/–
Чиво?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #40

52. Сообщение от maximnik0 (?), 13-Апр-15, 22:09	–1 +/–
>>> Да, туда бу компрессию и снапшоты и я бы послал btrfs :) >> LVM? > Сжатие? Были падчи для ext2 и ext3 с потдержкой сжатия - до версии ядра 2.6.6 входили в ядра от Zen-kernel и  Кона Коливаса ,из за невостребованости потдержка прекращена :-( Проект  Next3 - ext3/4 с снапшотами ,обновлений нет  3 года  Ж-( Проект ext3cow -ext3 c снапшотами ,обновлений нет уже 7 лет ...
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #8

53. Сообщение от ABATAPA (ok), 13-Апр-15, 22:35	+/–
> Причём тут Android? Новость ни читай, комментарии пиши быстрей давай? Цитирую специально для не читающих: > работающий в компании Google > данные патчи войдут в состав следующего релиза Android "M". Совсем не причём, да? И абсолютно понятно - для чего это: http://habrahabr.ru/company/eset/blog/252027/ http://www.oszone.net/25728/Android_5_0_FDE_cause_performanc... Откуда вас столько берётся, горе-комментаторов нечитающих...
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #17 Ответы: #54

54. Сообщение от Какаянахренразница (ok), 13-Апр-15, 22:47	+7 +/–
> Совсем не причём, да? Совсем не причём. У меня корневая ФС на десктопной машине -- именно Ext*. Какая мне нахрен разница, какие патчи войдут в состав следующего релиза Андроида??? И если гражданин Шталь этажом выше сказал, что к нему Андроид никаким боком не относится, то вполне возможно, что так оно и есть.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #53 Ответы: #61

55. Сообщение от Анонимище (?), 13-Апр-15, 23:27	+5 +/–
> есть ли смысл использовать Ext* где-либо в принципе, если есть файловые системы лучше по всем релевантным параметрам? Если есть, то нет. А так - есть.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #40

56. Сообщение от Crazy Alex (ok), 14-Апр-15, 00:24	+/–
Ты о чём, болезный? Какой Secure Boot на смартфоне? А так - ну да, есть разница между идеальным положением вещей и реальностью. Так что - предлагаешь лапки сложить и даже не думать, как должно бы быть по уму?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #46 Ответы: #64

57. Сообщение от Crazy Alex (ok), 14-Апр-15, 00:29	+1 +/–
Да что вы все так жать рвётесь? Объемных данных есть, грубо говоря, всего два варианта - разного рода BigData, где движки при нужде со сжатием сами прекрасно разобраться могут, а вот лишний слой с непредстказуемыми характеристиками - только ко вред, и мультимедиа-данные, которые толком жмутся только специфическими алгоритмами. Да и в остальных областях где было нужно и возможно - вплоть до паршивых офисных документов - сжатие уже в комплекте.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #47

58. Сообщение от ram_scan (?), 14-Апр-15, 07:18	+/–
> Не дело это. Нечего шифрованию делать в коде ФС -- шифрование это не обязанность ФС А сжатие - обязанность ФС. Таки в чем великая разница между сжатием и шифрованием, когда на носителе физически лежат не те данные которые при чтении отдаются ? Такшта вы или крестик оденьте или трусы сымите.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #1 Ответы: #63, #74

59. Сообщение от 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ообщить модератору
Родитель: #45 Ответы: #67

60. Сообщение от Аноним (-), 14-Апр-15, 12:00	+/–
Что за ерунда? Комментарии предназначены для хамства и распространения заведомо ложных утверждений, почитай комментарии на opennet.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #32

61. Сообщение от Анонимоус (?), 14-Апр-15, 13:32	+/–
Вас под палками заставляют пользоваться всеми функциями ФС? Уберете галочку о шифровании Ext4 и будете жить дальше. Я такую галочку поставлю, и буду жить с шифрованными папками без левого корявого софта
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #54 Ответы: #65

62. Сообщение от Аноним (-), 14-Апр-15, 15:53	+1 +/–
> Поставим вопрос иначе: есть ли смысл использовать Ext* где-либо в принципе Ext4 - простой и быстрый. Если это все что надо от ФС - Ext4 вполне подходит. Он не требует гигантских ресурсов и шустро работает в большинстве типовых нагрузок.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #40

63. Сообщение от Ocean (??), 14-Апр-15, 16:51	+/–
> Такшта вы или крестик оденьте или трусы сымите. Правильнее "Или крестик снимите или трусы оденьте"
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #58

64. Сообщение от Аноним (-), 14-Апр-15, 18:59	+/–
> Ты о чём, болезный? Какой Secure Boot на смартфоне? эт слова в тему, об общем положении вещей. Хотя, судя по тенденциям, скоро может быть и на смартфоне > Так что - предлагаешь лапки сложить и даже не думать, как должно бы быть по уму? Протри монитор, такого в посте не было. (если не в курсе https://ru.wikipedia.org/wiki/%D0%A1%D0%...
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #56 Ответы: #77

65. Сообщение от Какаянахренразница (ok), 14-Апр-15, 19:16	+2 +/–
> Вас под палками заставляют пользоваться всеми функциями ФС? Уберете галочку о шифровании > Ext4 и будете жить дальше. Я такую галочку поставлю, и буду > жить с шифрованными папками без левого корявого софта Нет, не заставляют. Но, как юзер этой ФС, я интересуюсь её новыми фичами.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #61

66. Сообщение от iZEN (ok), 14-Апр-15, 20:32	+2 +/–
> Извращенцы создают ZFS пул и в нем создают ext4 o_O ada0 <-> GEOM ELI <-> zpool <-> ZVOL (с установленным свойством сжатия LZ4) <-> ext4 чем не вариант для бедных линуксоидов, озабоченных проблемой шифрования и сжатия данных на ФС, которая не поддерживает ни того, ни другого?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #15 Ответы: #71

67. Сообщение от 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ообщить модератору
Родитель: #59 Ответы: #68

68. Сообщение от 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ообщить модератору
Родитель: #67 Ответы: #69

69. Сообщение от 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ообщить модератору
Родитель: #68 Ответы: #72

70. Сообщение от Аноним (-), 15-Апр-15, 01:40	+/–
А производительность? В ядре под ARM заточен только AES и SHA1. Да и отсутствие альтернативы настораживает. А так да, идея весьма не плохая
Ответить | Правка | Наверх | Cообщить модератору

71. Сообщение от Аноним (-), 15-Апр-15, 04:24	+/–
Как не пили ext4 он неисправим!
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #66 Ответы: #76

72. Сообщение от 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ообщить модератору
Родитель: #69 Ответы: #73

73. Сообщение от 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ообщить модератору
Родитель: #72

74. Сообщение от azure (ok), 16-Апр-15, 18:18	+/–
А я вот не понял ваших доводов. ФС это такая черная коробка, на входе у которой данные для записи, а на выходе - ранее сохраненные данные. Что происходит с данными внутри - это дело черной коробки. Может исходя из каких-то особенностей физического носителя данные имеет смысл дробить, линчевать, добавлять дополнительную информацию для восстановления в случае частичной потери данных. А вы хотите запретить ФС делать это. Да кто вы такой? Есть интерфейс и предсказуемое поведение + удовлетворительные характеристики производительности - значит ФС годная. А то заладили, обязанность или не обязанность.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #58

75. Сообщение от Alex (??), 17-Апр-15, 15:46	+/–
А вам не кажется, что делать дедупликацию без знания в каких физических блоках что находится довольно тяжело?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #26

76. Сообщение от kurokaze (ok), 18-Апр-15, 11:11	+/–
толсто
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #71

77. Сообщение от maniaq (?), 20-Апр-15, 15:42	+/–
>> Ты о чём, болезный? Какой Secure Boot на смартфоне? > эт слова в тему, об общем положении вещей. Хотя, судя по тенденциям, > скоро может быть и на смартфоне А что его там уже отключили? Очень немногие девайсы не требуют разлочки загрузчика, чтобы прошить туда другую фирмварь. Чем это технически отличается от SecureBoot?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #64

78. Сообщение от Аноним (-), 20-Апр-15, 16:40	+/–
ага, на отдельных хостах, стоящих в соседнем помещении. специально для "тепло-ламповости" этого.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #26

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

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