From: Oskar Sharipov
Date: 2021-01-10 02:01:32Z
О, вижу на http://www.goredo.cypherpunks.ru/Install.html#Install, что
архивы сжимаются с помощью Zstandard. Сначала хотел спросить, почему про
него вы ничего в блоге не писали, а потом решил полистать коммиты...
Оказалось, писали не мало, я почему-то всё пропустил.
Вот для остальных читателей, если кому интересно:
Быстрое сжатие: ac4f39d3d92ce51278c5baf50b560608ddb6163f
Нужен ли в долгом сжатии: 738fc2e95a295879f990c1a307c792d8e91b9018
NNCP использует zstd: 952451ff289323ded1f32806d494dde17b6db4f1
Еще в 63d24800bdf210844289b627cf87e90da83b6e5d про OpenZFS 2.0, где
Zstandard наконец релизнули (сколько за этим следил!). Но тут я, пока
шифрование для FreeBSD-версии не добавят, переходить не хочу. Лучше, как
минимум, FreeBSD 13, где он по-умолчанию будет, подожду.
Очень рад, что goredo улучшается! С момента, как впервые собрал,
пользуюсь и радуюсь. Но я до сих пор не могу сказать, радуюсь ли я
именно идее redo или этой реализации, потому что мне так и не
понадобилось пробовать другие. Но всё равно еще раз спасибо!
--
Oskar Sharipov
gpg fingerprint: BAC3 F049 748A D098 A144 BA89 0DC4 EA75 714C 75B5
From: Sergey Matveev
Date: 2021-01-10 11:01:46Z
*** Oskar Sharipov [2021-01-10 04:44]:
>Оказалось, писали не мало, я почему-то всё пропустил.
Писал, писал. И заменил у себя им полностью все xz/gzip вещи. Использую
либо просто zstd вызов, как штука отлично сжимающая (лучше gzip) и
которая упирается почти всегда только в жёсткие диски, либо "zstdmt
--ultra -22" как замена "xz -9". Последнее хоть вроде бы работает и
медленнее чем xz, совсем чуть-чуть хуже сжимает (иногда всего лишь доли
процента разницы), но скорость декомпрессии решает! Я прежде даже и не
предполагал что декомпрессия всяких tarball-ов упиралась в CPU/RAM и что
она может быть на глаз чуть ли не моментальной.
>Еще в 63d24800bdf210844289b627cf87e90da83b6e5d про OpenZFS 2.0, где
>Zstandard наконец релизнули (сколько за этим следил!). Но тут я, пока
>шифрование для FreeBSD-версии не добавят, переходить не хочу. Лучше, как
>минимум, FreeBSD 13, где он по-умолчанию будет, подожду.
Я тоже жду 13 или ещё более позднего релиза чтобы всё там сразу было и
хоть сколько-то но проверено временем (ведь OpenZFS же будет
использоваться). zstd в ZFS интересно проверить -- ибо не уверен что там
не упрусь в процессор.
Ну а шифрование лично меня не сильно там волнует. С самого начала опыта
с ZFS использую GELI. Что не так удобно конечно, но и не сильно где-то
доставляет проблем. Backup-ы всё равно делаю zfs send/recv обёрнутыми в
zstd и gpg шифрование. Ну и чисто с криптографической точки зрения в ZFS
шифровании более утекают метаданные о том что происходит на дисках...
хотя даже меня бы это не сильно в домашних условиях беспокоило.
>Очень рад, что goredo улучшается! С момента, как впервые собрал,
>пользуюсь и радуюсь. Но я до сих пор не могу сказать, радуюсь ли я
>именно идее redo или этой реализации, потому что мне так и не
>понадобилось пробовать другие. Но всё равно еще раз спасибо!
Вам спасибо за отзыв! Когда я написал goredo, то временами запускал
Python реализацию на всякий случай чтобы убедиться что всё работает
одинаково и поведение корректно. А когда перенёс ещё и тесты в goredo,
то другие реализации были удалены полностью.
Радуетесь вы 100% именно идее redo. Ибо, грубо говоря, даже визуально
разницы между apenwarr/redo и goredo не будет видно. Только скорость
работы между ними разнится (Python vs Go всё же, да и вроде
apenwarr/redo не умеет unlimited jobs). Ну и разнится в местах связанных
с redo-stamp (который в goredo является пустышкой), но я уверен что
меньшинство проектов используют redo-always/redo-stamp.