Как сжать раздел в Linux (как в винде на диске хранятся сжатые файлы) (Linux Mint (Ubuntu))

ZoL

two cups for this man
любой вопрос о файловых системах нужно скатывать к ZFS
zfs create -o compression=lz4 -o exec=off -o setuid=off rpool/mystore

Форматируешь раздел в zfs и выбираешь с 5 по 7 уровень компрессии.
Меньше будет не дожимать, больше заметного профита без относительно к затрачиваемым ресурсам.

compression=lz4

может лучше zlib, алгоритм старый и окатаный, глюков не будет.
И 4 будет не дожимать, надо ставить 6

может лучше

творчески переработал выхлоп zpool history
использую ZFS но не ZoL, выбор лишь из опций compression=on | off | lzjb | gzip | gzip-N | zle | lz4

Ну почему обязательно zfs? Можно и Raiser4, например ;).

Ну почему обязательно zfs?

моё мнение не относится к теме треда, всё же, zfs один из лучших примеров работы инженеров.
не идеальный пример, есть свои минусы, но среди остальных fs или lvm конкурентов не вижу.

всё же, zfs один из лучших примеров работы инженеров.

Согласен :). Упомянул Reiser4 для объективности, чтобы создать у автора темы иллюзию выбора ;).

Я имел ввиду gzip-6, забыл как еравильно, так как давно не пользовался.

К стати, а мелкие файлы которые долго не читали zfs больше не теряет?

Я имел ввиду gzip-6

gzip немного лучше сжимает, но накладные расходы на процессор делают его очень медленным, в некоторых тестах, в 6 раз медленнее lz4
если есть терабайты хорошо сжимаемых данных, вроде текста и не критична скорость чтения\записи наверное можно использовать gzip.
lz4 требует немного больше памяти, сжимает примерно на 50% хуже чем gzip-9, но с ним скорость выше, чем вообще без сжатия.

К стати, а мелкие файлы которые долго не читали zfs больше не теряет?

ничего об этом не знаю

мелкие файлы которые долго не читали zfs больше не теряет?

General — не место для городских легенд, мифов и прочих баек.

Из линуксовых ФС прозрачное сжатие поддерживает только Btrfs, включается оно опцией монтирования compress=lzo или compress=zlib. Первое сжимает хуже, но работает быстрее, это подойдёт для корня или /home. Второе жмёт лучше, но медленнее, это подойдёт для файлопомойки.

Как уже писали, есть всего пару fs которые подерживают прозрачное шифрование, но и в них практически нельзя переключать сжатие отдельных файлов, только все целиком.

Со всеми ними есть сложности, сначала стоит проверить на некритичных данных.

Более надежный вариат - squashfs. Чтение прозрачное, но создается\дозаписывается как архив.

среди остальных fs или lvm конкурентов не вижу.

Верно, особенно если забыть о ресурсоемкости, низком быстродействии, которое пытаются компенсировать большой памятью, фрагментации из-за COW, требования к RAM чтобы ECC, требования к дискам чтобы не домашнее говно, кол-во опций настроек больше чем у всего ядра (высокий порог вхождения), ...

А так то да замечательный комбайн!

но и в них практически нельзя переключать сжатие отдельных файлов

В btrfs можно. Чуть менее удобно, чем в винде, но по смыслу идентично.

General — не место для городских легенд, мифов и прочих баек.

пять 4.2 из шести, если прочесть «требования к ECC» как «рекомендация». иначе, все шесть из шести.

Поищи на ЛОРе, как только есть проблема с ZFS, то местные сектанты сразу: «У тебя же память без ECC, у тебя диски не ынтерпрайзные» и т.д. и т.п.

А так-то да отличный комбайн!

послушай, если бы это была какая то очень редкая технология или продукт, вроде эльбруса — я бы понял почему у тебя такая реакция и вера в мифы. даже накидал ссылок по каждому пункту.
но, дружище, весь интернет переполнен статьями. теоретическими, практическими, где на разном уровне доступности объясняются\опровергаются эти мифы.
даже, внезапно, не относящиеся к ZFS: у тебя диски не ынтерпрайзные

У меня архив порнушки накрылся известным органом, причем, что самое символичное, на FreeBSD (FreeNAS)

Не, я конечно понимаю, что 160-гиговый ide диск это не Ъ, но все же...

Ой, у тебя припекает?

Энтерпрайзные диски не то и энтерпрайзные, что если что сломалось, не тормозят по секунде на сектор, пытаясь скорректировать данные с помощью ECC, а сразу без тормозов выдают «Полимеры про..люблены»

ИЧСХ, для той-же ZFS этот вариант лучше.

Никто не говорит, что другие ФС не получат плюшек от ECC RAM.

Только вот из-за сложности структуры, ZFS (как и reiser4, внезапно) имеет куда большую площадь поражения. Соответственно инцидентов было больше.

Samba + Qemu + Windows 10 + NTFS. Получаешь выборочное сжатие файлов и папок. Стабильность и Enterpise.

Не желание принимать действительность это уже диагноз.

ресурсоемкости, низком быстродействии, которое пытаются компенсировать большой памятью

Миф? Нет!

фрагментации из-за COW

Миф? Нет!

требования к RAM чтобы ECC

Миф? Да миф, но только до первых проблем, потом не миф.

требования к дискам чтобы не домашнее говно

Миф? Да миф, но только до первых проблем, потом не миф.

кол-во опций настроек больше чем у всего ядра (высокий порог вхождения), ...

Миф? Миф, но только до первых проблем, потом тебе тыкают в пятитомник «как настроить ZFS за 21 день»

Возражай!

Ой, у тебя припекает?
имеет куда большую площадь поражения
инцидентов было больше

мне абсолютно очевидно, что пытаться завязать дискуссию таким образом — это путь в никуда.
начиная с недопонимания моего лексикона, из за чего, ты некоторые обороты речи считаешь моей эмоциональной реакцией.
заканчивая очередными пространными утверждениями о сложности структуры, площади поражения и большем количестве инцидентов.
последнее вообще, читать можно только отдельными фразами, если прочесть как предложения — теряется вообще любая смысловая нагрузка.
будь так добр, объясни последние два предложения общепринятыми хоть где-то в IT терминами.

я возражаю по всем пунктам. прошу занести в протокол, последний пункт вызывает у подзащитного особо резкое порицание, как ценителя красивых UI\UX решений.

Всё так, но фанбоям хоть в глаза писай

Это не миф, а реально пропавщие картинки с сохранёных вебстраниц и сообщения при скрубе о том, что в таких то файлах ошибка.

Это не миф, а реально пропавщие картинки

Выяснили же пару-тройку недель назад, что у тебя железо неисправно. Ты сам признался, что у тебя все ФС, кроме btrfs, крашатся и теряют файлы.
ZFS не теряет файлы, от слова совсем. У меня есть сторадж на одном проекте, примечателен тем, что там десятки миллионов мелких файлов, которые копятся с 2013 года, все живы.

кол-во опций настроек больше чем у всего ядра (высокий порог вхождения), ...

Но они логично организованы по задачам, по этому этот пункт имхо не правилен, по крайней мере года четыре назад талмуд читать было удобно.

Это были флешки, а не вестерны в райдовой редакции и вообще другой компьютер.

Во вторых ext4 теряли файлы после выключения ПК, в некоторых случаях после перезагрузки, и то только в том случае, если я не отмонтировал раздел в ручную выполнив тройной синк до и после отмонтирования раздела.
Так что не рассказывай мне, zfs теряла ДАВНО удачно сохранённые файлы и на приличных дисках с райдконтролёром(я для полного фарша даже мнтеловские карзины купил).

Самый эпичный пример это когда фс фейлиться сразу после установки чистой системы, с тех пор прежде чем завершить установку отмонтировываю /target руками.

Считаешь что /sys организован не логично?

Ну мне туда редко надо, а скорее даже ни когда, по этому логику этого раздела я не понимаю.

Так что не рассказывай мне, zfs теряла ДАВНО удачно сохранённые файлы и на приличных дисках

Что говорил scrub?

Точно не помню, про ошибки чексум.

ошибки чексум

Битое железо. Если ошибки чексум были на всех дисках массива, то это 100% битая память.

Диски были НОВЫЕ Western Digital Raid Edition, в 5 рейде с включёнными чексуммами блоков.
1) Как могло получиться что блок одновременно повреждался на двух разных дисках?
2) Почему аппаратные агрехи не сказывались на крупных файлах, а только на мелочи и не менее как пол года лежания?
Недавно сохранённые страницы открывались нормально.

Как могло получиться что блок одновременно повреждался на двух разных дисках?

Битая память.

Почему аппаратные агрехи не сказывались на крупных файлах, а только на мелочи и не менее как пол года лежания?

Неисправность железа может проявляться самым причудливым образом.

В общем нормальных объяснений у тебя нету.

Я объяснил предельно понятно. Если это объяснение лично тебе не нравится, это не значит что оно неправильное.

Э, ну ты же сказал что настройки zfs организованы лучше, а это сравнение с чем-то (ядром). Так с чем ты сравнивал и получил в результате «лучше»?

вместо того чтобы спорить, лучше бы обнародовал ядро, версию и свои суперудачные настройки zfs

там десятки миллионов мелких файлов, которые копятся с 2013 года, все живы.

Если бы дело было в оборудовании то глючила бы вся ФС в целом, а не какая то малая, нечто вроде 1МБ/2ТБ её часть, а глюки бы корелировали не с размером файла, а с кажем с объёмом записи или чтения с диска в момент их записи.

Ну не так логично как ман к btrfs или zfs.
Во всяком случае в последних проще разобраться.

Ничего особенного

/etc/modprobe.d/zfs.conf
options zfs zfs_arc_max=17179869184
options zfs zfs_read_chunk_size=1310720
options zfs zfs_vdev_cache_size=1310720
options zfs zfs_vdev_cache_max=131072
options zfs zfs_vdev_cache_bshift=17
options zfs zfs_vdev_async_read_max_active=12
options zfs zfs_vdev_async_read_min_active=12
options zfs zfs_vdev_async_write_max_active=12
options zfs zfs_vdev_async_write_min_active=12
options zfs zfs_vdev_sync_read_max_active=12
options zfs zfs_vdev_sync_read_min_active=12
options zfs zfs_vdev_sync_write_max_active=12
options zfs zfs_vdev_sync_write_min_active=12

Только вот из-за сложности структуры, ZFS (как и reiser4, внезапно) имеет куда большую площадь поражения.

Что за такая «площадь поражения»? В каких единицах она измеряется?

inotify + любое сжатие, и плевать на фс (выше отписавшиеся хомячки)

предугадывая вопли о своей якобы компетентности смею заметить, что с помощью inotify можно хоть по MIME типу указать каким алгоритмом сжимать, и сжимать ли вообще, на что никакая фс ещё не способна

inotify + любое сжатие, и плевать на фс

Ну, тогда ФС наплюёт на твоё сжатие. Отведёт под сжатый 4К-файл целый блок. Сжимай, не сжимай - на диске занято столько же - 4К.