В прошлом году отправлял посылку (шоколад, конфеты - скоропортящийся товар) из Москвы в Псков через EMS с доставкой до адресата. Ускоренная посылка с доплатой дошла дней за 5. И потом неделю лежала в отделении связи. Помог только звонок на 8-800. При этом ежедневные звонки в само псковское отделение с вопросом "а когда?" заканчивались словами "ваша посылка слишком тяжелая (12 кг), везти ее некому".
Для отправки же сейчас обычно уходит минут 5 (Москва, Марьино). Дома заполнил отправитель-получатель, распечатал бланк, а в отделении оператор сканирует штрихкод с бланка и опечатывает коробку лентой. Всё.
Volume — это том. Sub-volume — это подтом. Сабвольюм — это для обычного человека непонятно что. И по своей структуре sub-volume как раз является отдельным томом внутри контейнера. На Btrfs, может быть, это не так очевидно, но на APFS каждый подтом можно рассматривать как независимую файловую систему (если не учитывать изобретенные ими фирмлинки).
«Собеседовался» около 10 лет назад в отдел разработки одной очень известной в мире компании. Как раз в то время они решили перенести часть своих ресурсов из Москвы в мой недалекий провинциальный город. Зарплата в долларах, выше рынка, корпоративные плюшки меня вообще не интересовали. Перед собеседованием честно сказал, что по части их требований вообще нет опыта. Ответили: «все равно приходи, мол, поговорим, разберемся».
Пришел. Белая рубашка, правда, без галстука. Перед, прости, Господи, их офисом на втором этаже самостроя с хозяйственным магазином во весь этаж, но с отдельным входом, попросили позвонить. Вышел, даже не знаю кто, не представился, PM вроде бы должен быть по идее. Поставил чашку кофе на капот своей машины, закурил, и спросил, а писал ли я что-нибудь под Linux. Ответил честно, что данной мовой в совершенстве не владею. После вопроса «а чё вообще тогда приходил?», пришлось таким красивым ехать домой.
Сейчас уже шестой год пишу под линукс в том числе и для их рогатых железок драйвера файловых систем уже в другой известной на весь мир компании, а они нам жалуются на их проблемы с перфомансом. Спасибо вам, дорогие!
Работаю по специальности с 2000 года. Синьором себя не считаю, потому что есть столько всего, что я не знаю/не понимаю. Так, обычный узкоспециализированный миддл, который не пройдет собеседование на джуниора в среднестатистическую компанию.
Платон говорил: «Я знаю, что ничего не знаю!.. Я с ним полностью согласен.
В ext2/3 файлы в директории хранятся линейно, в отличие от ext4, где большие директории конвертятся в hash tree. Отсюда проблемы с поиском файла по имени. И да, ситуация сильно зависит от длины имени файла.
Речь идет о битмапе блоков, по-видимому. Такой способ плох тем, что придется «исправлять» слишком много метаданных, иначе можно спалиться на первом же fsck, после которого «программист уже будет знать, что где следует искать».
Другое дело — занятые кластера приписать к badblock inode, но тут опять же придется обновлять все его метаданные и вносить изменения в битмап блоков, суперблок и таблицы дескрипторов.
1. Для бекапа проблем нет. Могу долго и нудно про это рассказывать (вкратце уже изложил ниже), но это совершенно другая тема.
2. ecryptfs — насколько я понял, шифрование в ext4 как раз реализовано на ее основе.
3. LUKS, насколько помню, шифрует сразу всё и сразу, т.е. это не совсем то.
4. Если злоумышленник вроде меня снимет dd со всего раздела, то я навскидку не могу придумать, как расшифровать содержимое директории, владея всеми этими заумными аббревиатурами. Ключи всё-таки ого-го.
5. Видны папки с кракозябрами? Это еще пол-дела. Эти кракозябры совершенно не соответствуют тому, что непосредственно прописано в direntry, т.е. для вывода пользователю оно еще раз шифруется по типу base64, дабы исключить невалидные символы в именах. А для find вообще не должно быть вопросов: ну получит он restrict, ему же лучше
1. Зачем нужно шифрование на уровне файловой системы? Ну, как минимум, для улучшения производительности без использования сторонних продуктов. Это чисто мое мнение, а лучше спросить у Гугла, как у заказчика.
2. Зачем с него грузиться, я, честно, вообще не задумывался. Подозреваю, что моя паранойя еще не прогрессирует
3. Шифровать отдельные папки способы есть, несомненно. Но, может, пришло уже время выкинуть этот бубен, когда есть способ сделать это из коробки.
Хороший вопрос. Резервное копирование — это вообще отдельная тема.
В данном примере содержимое зашифрованного файла получается при непосредственном чтении кластеров, которые принадлежат этому айноду — сначала необходимо найти айнод в таблице и затем пройти по его дереву экстентов, читая занятые кластера. Обратите внимание на рис. 4, где показан айнод зашированного файла и выделен его один единственный кластер. Здесь рассмотрен очень простой случай. Но в целом — задача, мягко говоря, не самая тривиальная.
Что же касается резервного копирования, то выполнение этой операции через readdir() с последующим read/write здесь не годится, если я правильно понял вопрос. Придется либо подружиться с деревом экстентов, либо вычитывать битмап блоков для каждой группы дескрипторов и копировать занятые кластера.
В прошлом году отправлял посылку (шоколад, конфеты - скоропортящийся товар) из Москвы в Псков через EMS с доставкой до адресата. Ускоренная посылка с доплатой дошла дней за 5. И потом неделю лежала в отделении связи. Помог только звонок на 8-800. При этом ежедневные звонки в само псковское отделение с вопросом "а когда?" заканчивались словами "ваша посылка слишком тяжелая (12 кг), везти ее некому".
Для отправки же сейчас обычно уходит минут 5 (Москва, Марьино). Дома заполнил отправитель-получатель, распечатал бланк, а в отделении оператор сканирует штрихкод с бланка и опечатывает коробку лентой. Всё.
Пришел. Белая рубашка, правда, без галстука. Перед, прости, Господи, их офисом на втором этаже самостроя с хозяйственным магазином во весь этаж, но с отдельным входом, попросили позвонить. Вышел, даже не знаю кто, не представился, PM вроде бы должен быть по идее. Поставил чашку кофе на капот своей машины, закурил, и спросил, а писал ли я что-нибудь под Linux. Ответил честно, что данной мовой в совершенстве не владею. После вопроса «а чё вообще тогда приходил?», пришлось таким красивым ехать домой.
Сейчас уже шестой год пишу под линукс в том числе и для их рогатых железок драйвера файловых систем уже в другой известной на весь мир компании, а они нам жалуются на их проблемы с перфомансом. Спасибо вам, дорогие!
Платон говорил: «Я знаю, что ничего не знаю!.. Я с ним полностью согласен.
чтогде следует искать».Другое дело — занятые кластера приписать к badblock inode, но тут опять же придется обновлять все его метаданные и вносить изменения в битмап блоков, суперблок и таблицы дескрипторов.
2. ecryptfs — насколько я понял, шифрование в ext4 как раз реализовано на ее основе.
3. LUKS, насколько помню, шифрует сразу всё и сразу, т.е. это не совсем то.
4. Если злоумышленник вроде меня снимет dd со всего раздела, то я навскидку не могу придумать, как расшифровать содержимое директории, владея всеми этими заумными аббревиатурами. Ключи всё-таки ого-го.
5. Видны папки с кракозябрами? Это еще пол-дела. Эти кракозябры совершенно не соответствуют тому, что непосредственно прописано в direntry, т.е. для вывода пользователю оно еще раз шифруется по типу base64, дабы исключить невалидные символы в именах. А для find вообще не должно быть вопросов: ну получит он restrict, ему же лучше
2. Зачем с него грузиться, я, честно, вообще не задумывался. Подозреваю, что моя паранойя еще не прогрессирует
3. Шифровать отдельные папки способы есть, несомненно. Но, может, пришло уже время выкинуть этот бубен, когда есть способ сделать это из коробки.
Не знаю, где находятся ваши родные репозитории, но для меня нет большой разницы между apt install и git clone https://github.com/tytso/e2fsprogs
В данном примере содержимое зашифрованного файла получается при непосредственном чтении кластеров, которые принадлежат этому айноду — сначала необходимо найти айнод в таблице и затем пройти по его дереву экстентов, читая занятые кластера. Обратите внимание на рис. 4, где показан айнод зашированного файла и выделен его один единственный кластер. Здесь рассмотрен очень простой случай. Но в целом — задача, мягко говоря, не самая тривиальная.
Что же касается резервного копирования, то выполнение этой операции через readdir() с последующим read/write здесь не годится, если я правильно понял вопрос. Придется либо подружиться с деревом экстентов, либо вычитывать битмап блоков для каждой группы дескрипторов и копировать занятые кластера.