Комментарии 15
А то, что в (стабильной ветке) ZoL не работает TRIM, вас не смущает?
Несмотря на то, что все мои проекты ведутся в гите, не весь код полностью мой, и не хочется его выкладывать на гитхаб.
Bitbucket дает бесплатно приватные репозитории.
Интересный опыт!
Но всё же, почему не стандартная для linux связка md+lvm+ext4? Почему для вас zfs перевешивает даже с таким не самым интуитивным инсталлом?
Но всё же, почему не стандартная для linux связка md+lvm+ext4? Почему для вас zfs перевешивает даже с таким не самым интуитивным инсталлом?
Потому что в схеме выше — 4 компонента (ещё шифрование) и тяжёлые снэпшоты. Пусть даже md возможно убрать. При этом, нет сквозного контроля: люди обсуждают, лучше хранить хэши файлов рядом с ними или в отдельном каталоге.
ZFS берёт на себя управление дисками, сквозной контроль, сжатие, создание снэпшотов, синхронизацию между разными ФС (zfs send), функционал рэйд-массивов, управление опциями монтирования, дедупликацию и так далее.
В идеале ещё и шифрование.
Кроме того, проблем с масштабированием не возникнет на 100%.
ZFS берёт на себя управление дисками, сквозной контроль, сжатие, создание снэпшотов, синхронизацию между разными ФС (zfs send), функционал рэйд-массивов, управление опциями монтирования, дедупликацию и так далее.
В идеале ещё и шифрование.
Кроме того, проблем с масштабированием не возникнет на 100%.
Статей про ZFS становится все больше, это радует.
Зачем вы забили SSD случайными данными перед blkdiscard, который потом все очистит?
Зачем вы забили SSD случайными данными перед blkdiscard, который потом все очистит?
Потому что это разные операции. :)
Зря минусуют предыдущего комментатора, т.к. это на самом деле разные операции для разных целей. ioctl BLKDISCARD (ATA TRIM) не гарантирует какого-то общего поведения на всех устройствах, все зависит от firmware конкретно диска. После discard'а контроллер диска может возвращать нули, прошлые данные, случайные данные, а может поведение вообще не быть четко описанным. Также есть и другие ata комманды: ATA SECURE TRIM (ioctl BLKSECDISCARD,
Поэтому топикастер заполняет сначала весь диск случайными данными, чтобы точно нельзя было достать прошлые данные напрямую с диска. После чего делается
Ну и для dd лучше поднять bs хотя бы до 1M-2M — меньше write iops на диск будет, больше по скорости можно будет разогнаться. И oflag=direct добавить, мы же хотим быть уверены, что сразу по факту все перезаписано. Ну или можно использовать специализированную утилиту — shred.
blkdiscard -s), ATA SECURITY ERASE UNIT (hdparm --security-erase), но опять же их поведение может быть по разному реализовано в firmware различных дисков.Поэтому топикастер заполняет сначала весь диск случайными данными, чтобы точно нельзя было достать прошлые данные напрямую с диска. После чего делается
blkdiscard уже для других целей — помечаем все блоки как свободные, чтобы вернуть показатели производительности ssd диска к изначальным. При этом мы уже не волнуемя, что с диска можно будет достать старые данные при любом поведение discard'а.Ну и для dd лучше поднять bs хотя бы до 1M-2M — меньше write iops на диск будет, больше по скорости можно будет разогнаться. И oflag=direct добавить, мы же хотим быть уверены, что сразу по факту все перезаписано. Ну или можно использовать специализированную утилиту — shred.
До этого я на эти SSD уже ставил систему: у меня не всё сразу взлетело.
И, как заметил комментатор выше, это просто гарантированное стирание.
Про hdparm --security-erase я в курсе. Но у этого способа есть проблема: он не везде работает.
В том числе и у меня. Некоторые платы блокируют secure erase (хотя, мои SSD его поддерживают). Для того, чтобы разблокировать, предлагалось вытащить провод «на горячую», а для этого надо открывать корпус, чего мне делать не хотелось.
А blkdiscard действительно гарантирует лишь то, что блоки будут помечены, как неиспользуемые, хотя в моём случае «свободные» блоки и возвращают нули (специально сейчас проверил).
Что, конечно, несколько понижает уровень криптостойкости (хотя, не критично).
И, как заметил комментатор выше, это просто гарантированное стирание.
Про hdparm --security-erase я в курсе. Но у этого способа есть проблема: он не везде работает.
В том числе и у меня. Некоторые платы блокируют secure erase (хотя, мои SSD его поддерживают). Для того, чтобы разблокировать, предлагалось вытащить провод «на горячую», а для этого надо открывать корпус, чего мне делать не хотелось.
А blkdiscard действительно гарантирует лишь то, что блоки будут помечены, как неиспользуемые, хотя в моём случае «свободные» блоки и возвращают нули (специально сейчас проверил).
Что, конечно, несколько понижает уровень криптостойкости (хотя, не критично).
при шифровании /boot раздела можно использовать специальный файлик с ключом от остальных дисков на зашифрованном /boot или внутри образа ядра;
плюсы: пароль вводиться только для /boot раздела
минусы: при компрометации оси пасс от дисков несколько проще украсть из файла, нежели из памяти. хотя при такой компрометации оси с дальнейшем физическим доступом к дискам, это не самая большая ваша проблема имхо…
плюсы: пароль вводиться только для /boot раздела
минусы: при компрометации оси пасс от дисков несколько проще украсть из файла, нежели из памяти. хотя при такой компрометации оси с дальнейшем физическим доступом к дискам, это не самая большая ваша проблема имхо…
Как вариант. Под «образом ядра», вы имели ввиду initrd, я так понимаю?
Небольшие минусы способа:
— Дешифровку будет производить граб. Он делает это медленно (видимо, aes-ni не использует).
— При подключении раздела (для обновления ядра/initrd) его надо будет расшифровать.
Ну и пока вы пароль не введёте, консоль граба не будет доступна.
Небольшие минусы способа:
— Дешифровку будет производить граб. Он делает это медленно (видимо, aes-ni не использует).
— При подключении раздела (для обновления ядра/initrd) его надо будет расшифровать.
Ну и пока вы пароль не введёте, консоль граба не будет доступна.
А как построение ZFS пула поверх зашифрованных устройств сказывается на надежности пула?
При замене диска, он будет перезаписываться на 100% или частично, только в объеме записанных данных, как на ZFS без шифрования?
При замене диска, он будет перезаписываться на 100% или частично, только в объеме записанных данных, как на ZFS без шифрования?
На надёжности пула, в каком смысле?
Добавляется ещё одна потенциальная точка отказа (шифрующее ПО и возможно менее отлаженное взаимодействие между ним и ZFS, по сравнению с "голым диском"), так что конечно положительно это сказаться не может.
Но с этим приходится мириться, либо искать альтернативные варианты: SED, шифрование ZFS, которое ZoL пока не выпущено, и оставляет открытой структуру ФС, либо шифрование zvol, поверх чего накатывать другую ФС, лишаясь возможности управлять файлами средствами ZFS, либо просто усложнять систему.
При замене диска, он будет перезаписываться на 100% или частично, только в объеме записанных данных, как на ZFS без шифрования?
При замене диска, рекомендуется предварительно записать на него случайные данные.
После того как шифрованный диск будет дешифрован и интегрирован в пул, ZFS будет видеть его, как обычное блочное устройство и работать аналогично. При этом, LUKS шифрует лишь то, что ему подаётся на вход, никакой полной перезаписи не будет.
Т.е., записано туда примерно столько же, что и на нешифрованный диск.
Кроме того, если процессор поддерживает AES-NI, на производительности это сильно не скажется.
Зарегистрируйтесь на Хабре , чтобы оставить комментарий
Установка Debian с корнем на шифрованном ZFS зеркале