https://www.opennet.me/openforum/vsluhforumID3/102053.html Разработчик файловой системы 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.<br><br><br>Реализация подразумевает (https://docs.google.com/document/d/1ft26lUQyuSpiu6VleP70_npaWdRfXFoNnB8JYnykNTg/edit?pli=1#heading=h.9e2z5olpqevs) предоставление возможности шифрования отдельных частей ФС, например, отдельных директорий. При этом шифруется только содержимое и имена файлов, а метаданные о файлах, такие как размер и права доступа, остаются видимыми. Ключ шифрования определяет https://www.opennet.me/openforum/vsluhforumID3/102053.html#78 Mon, 20 Apr 2015 13:40:49 GMT ага, на отдельных хостах, стоящих в соседнем помещении.<br>специально для "тепло-ламповости" этого.<br> https://www.opennet.me/openforum/vsluhforumID3/102053.html#77 Mon, 20 Apr 2015 12:42:20 GMT &gt;&gt; Ты о чём, болезный? Какой Secure Boot на смартфоне?<br>&gt; эт слова в тему, об общем положении вещей. Хотя, судя по тенденциям, <br>&gt; скоро может быть и на смартфоне <br><br>А что его там уже отключили? Очень немногие девайсы не требуют разлочки загрузчика, чтобы прошить туда другую фирмварь. Чем это технически отличается от SecureBoot? <br><br><br> https://www.opennet.me/openforum/vsluhforumID3/102053.html#76 Sat, 18 Apr 2015 08:11:46 GMT толсто<br> https://www.opennet.me/openforum/vsluhforumID3/102053.html#75 Fri, 17 Apr 2015 12:46:28 GMT А вам не кажется, что делать дедупликацию без знания в каких физических блоках что находится довольно тяжело?<br> https://www.opennet.me/openforum/vsluhforumID3/102053.html#74 Thu, 16 Apr 2015 15:18:20 GMT А я вот не понял ваших доводов. ФС это такая черная коробка, на входе у которой данные для записи, а на выходе - ранее сохраненные данные. Что происходит с данными внутри - это дело черной коробки. Может исходя из каких-то особенностей физического носителя данные имеет смысл дробить, линчевать, добавлять дополнительную информацию для восстановления в случае частичной потери данных. А вы хотите запретить ФС делать это. Да кто вы такой? Есть интерфейс и предсказуемое поведение + удовлетворительные характеристики производительности - значит ФС годная. А то заладили, обязанность или не обязанность. <br> https://www.opennet.me/openforum/vsluhforumID3/102053.html#73 Wed, 15 Apr 2015 11:55:08 GMT &gt;&gt; kill -KILL не о чём не говорит? или таки пейсатель?<br>&gt; Ну извините. Я по Вашей простыне наискось пробежался. Свою, заметьте, <br>&gt; не поленился отфильтровать.<br><br>я и говорю не читатель, потому что моя простыня не большая это раз, а два это то что необходимое вам в подтверждение вы нашли быстро, а из этих вы потому что инженер в первую очередь пошел-бы искать причины падения вполне-себе userspace-ного сервиса по сигналу KILL, что делается в Linux давольно просто. Вместо поиска проблем с nbd вы стали лечить и жаловаться на симптомы (lvm).<br><br>&gt;&gt;&gt; У lvm видел на эту тему чью-то ученическую поделку, и только.<br>&gt;&gt; а вы из этих...<br>&gt; Из инженеров, собирающих заказанный продукт из имеющегося, ага.<br><br>инженер из говна конфету не лепит -- для этого есть другие люди.<br>&gt;[оверквотинг удален]<br>&gt; Оно развивается и вполне разумно задумано, но ruby в данном секторе лично <br>&gt; мне доставляет.<br>&gt; Там ещё есть ссылка на реально ученическую работу blocksync.py - <br>&gt; оно изначально КС по блокам считало через adler32 https:// https://www.opennet.me/openforum/vsluhforumID3/102053.html#72 Wed, 15 Apr 2015 08:39:15 GMT &gt; kill -KILL не о чём не говорит? или таки пейсатель?<br><br> Ну извините. Я по Вашей простыне наискось пробежался. Свою, заметьте, не поленился отфильтровать.<br><br>&gt;&gt; У lvm видел на эту тему чью-то ученическую поделку, и только.<br>&gt; а вы из этих...<br><br> Из инженеров, собирающих заказанный продукт из имеющегося, ага.<br>Специально для эстетов, нашёл: https://github.com/mpalmer/lvmsync<br>Оно развивается и вполне разумно задумано, но ruby в данном секторе лично мне доставляет.<br><br> Там ещё есть ссылка на реально ученическую работу blocksync.py - оно изначально КС по блокам считало через adler32 https://gist.github.com/rcoup/1338263/revisions. Теперь автор повзрослел и поправил на sha /а современный rsync до сих пор md4 считает afaik/. <br> Мда. Когда я обнаружил эту питонятину в одном довольно таки серьёзном проекте, получил неслабый заряд позитива. А отсмеявшись, воткнул на его место патченный rsync, который btw тоже не фонтан. Но уж что было...<br> https://www.opennet.me/openforum/vsluhforumID3/102053.html#71 Wed, 15 Apr 2015 01:24:34 GMT Как не пили ext4 он неисправим!<br> https://www.opennet.me/openforum/vsluhforumID3/102053.html#70 Tue, 14 Apr 2015 22:40:37 GMT А производительность? В ядре под ARM заточен только AES и SHA1. Да и отсутствие альтернативы настораживает.<br>А так да, идея весьма не плохая<br>