Сжатие дисков/папок в Linux?

Question

[Сергей]

Есть у меня сервер, на котором под Centos 8 работают шары самбы, фтп, службы печати, почта и т.д. Некоторые папки используются очень активно, а есть 2 очень "жирных" папки с различными курсами и документами в формате .pdf/.doc/.html и папка с данными уволенных пользователей. В папке уволенных пользователей файлы в форматах .pdf/.doc/.xml. Есть потребность хранить данные в более компактном виде, но без необходимости постоянно архивировать-разархивировать данные вручную.
Подскажите пожалуйста по следующим вопросам:
1. Есть система btrfs. Прочитал пару сильно негативных комментариев про нее. У кого есть опыт работы с ней, как ощущения?
2. Аналогично про SquashFS
3. Есть ли еще какие то варианты решения задачи?

Comments

[pfg21]

сделать холодное зеркало из hdd
можно даже б/у, только дисков побольше наложить :) и плюс бекап на м-диски

2. если только документы не изменяемые, ибо squashfs только для чтения.
в принципе можно данные сжимать в файлы со squashfs, потом монтировать и собирать в одно дерево через aufs.
xml пожмется хорошо. pdf doc уже не очень. docx сам по себе уже сжат zip и т.д.
весь вопрос в том есть ли желание с этим возится при том что hdd стоят копейки.

[xotkot]

если доступ read-only то есть замечательная штука dwarfs

[rPman]

Какие негативные коментарии про btrfs вы слышали?

Официально проблемы с raid56 и у меня такое ощущение что этот статус не меняется годами, хотя тут же написано что патчи применяются с каждым релизом, патчи уже написаны (еще про версию 4.12 - 2017г) но требуют переработки... но уже 5.15 вышла (5.11 в lts ubuntu).

Я слышал о сложностях восстановления сломанных разделов (например проблемы с питанием, проблемы с контроллером дисков и т.п.) но чтобы вот само по себе сломалось это реально редкость.

Напоминаю, когда у тебя падает питание/виснет ядро/прилетает нейтрино в чип ram вероятность того что прямо сейчас все сломается - минимальна, но косяк никуда не девается, он просто ждет момента когда его затронут, зато потом может поломать все, и это не зависит от файловой системы, сломается все.

p.s. реально совет, не нужно делать один огромный раздел на все, особенно когда рейд из 100500 дисков. Дели на небольшие независимые файловые системы, тематические или нет, почти всегда это возможно, все разруливается от симлинков до mount -t bind.

Answer 1

[Drno]

самый простой - купить 2 hdd и вынести на них эти данные

можно попробовать zfs compression но хватит ли оперативки

Comments

[Сергей]

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

Answer 2

[Adamos]

файлы в форматах .pdf/.doc/.xml

Попробуйте взять и заархивировать чем угодно PDF.
Сюрприз - скорее всего, файл станет только больше за счет заголовков архиватора.
Если DOC - не DOC, а DOCX - то затея проваливается по тому же сценарию.
А XML у вас прямо такие залежи, что архивация высвободит уйму места? Что-то с трудом такое представляю. Зачем?..

Вообще, я бы сначала оценил, что именно жрет место. Если это именно PDF - вполне вероятно, что там навалены какие-нибудь сканы документов с диким разрешением, и их можно просто взять и пожать, скажем, ps2pdf -dPDFSETTINGS=/ebook (ну, или /print, а то и /screen, уж какое там качество на самом деле нужно).

Comments

[rPman]

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

p.s. как ни странно, пережать docx (и вообще весь класс таких документов) перед помещением в архив нужно 'с отключением сжатия' или даже распаковав zip файл чем они являются в каталог с сохранением информации о том что это было именно документом... в этих файлах много повторяющихся частей, плюс сторонний архиватор скорее всего будет эффективнее устаревшего zip, плюс можно включить режим solid, что еще лучше все в итоге пожмет

[Adamos]

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

[rPman]

Adamos, давай таблицы экселя сконвертируй в pdf, потом посмотрю 'как тебя их пользователи в сортире ногами будут пинать'

главная задача тут не навреди

[Adamos]

rPman, с тех пор, как таблицы Ёкселя были актуальной технологией хранения данных, Акцесс успел родиться и сдохнуть.

[rPman]

нуну
я тут поспрашивал (вопрос удалили), а для обывателя другого софта одновременно простого, удобного и функционального не придумали

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

[Adamos]

rPman, я прекрасно понимаю причины стабильной популярности Ёкселя среди чайников.
Но они ни разу не оправдывают его применение там, где решаются вопросы архивации, например.

[rPman]

Но они ни разу не оправдывают его применение там, где решаются вопросы архивации, например.

с каких пор выбор инструмента теперь должен обосновываться удобством ... его архивации О_о

[Adamos]

rPman, естественно, не только архивации. Важен весь жизненный цикл данных.
А вот если ставить во главу угла удобство чайников и низкий порог вхождения - получаешь бардак и захлестывающий технический долг. Проверено многими и многими организациями.

[rPman]

Adamos, не то место где о техническом долге вспомнил

а вот если ты к требованиям нанимаемых сотрудников запишешь - умение работать с sql базами данных, gnuplot, apache zepiln/spark , python и т.п.... то либо ты таких сотрудников не найдешь, либо потребуется планку зарплаты поднимать раза в четыре минимум.

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

[Adamos]

rPman, не болтайте ерундой. Какой дурак организует работу так, чтобы сотрудникам приходилось напрямую работать с питоном и БД?
CRM с веб-мордой - и никаких rocket science с оверскиллами.

[rPman]

Adamos, там где люди рабтают с таблицами в эксель это не решение
анализ данных, составление отчетов, ты хочешь посадить специального программиста который будет это пилить все в вебморде? но тогда зачем остальные сотрудники? ой внезапно они все перетекут в разработчиков этой вебморды,.. поздравляю, ты повысил затраты своего отдела в несколько раз на пустом месте

[Сергей]

>Попробуйте взять и заархивировать чем угодно PDF.
>Сюрприз - скорее всего, файл станет только больше за счет заголовков архиватора.
Решил проверить. Файл стал меньше. Что я делаю не так?

>Если DOC - не DOC, а DOCX - то затея проваливается по тому же сценарию.
Создал вордовский документ на 15000 страниц. 1,5 мегабайта. Сжал - 40 килобайт. Что я делаю не так?

>А XML у вас прямо такие залежи, что архивация высвободит уйму места? Что-то с трудом такое представляю. Зачем?..
Ошибся, не .xml, a .xls. В офисе ворд и эксель - миллионы файлов. На виндовом сервере сжатие папки сжимает раз в 8.

>Вообще, я бы сначала оценил, что именно жрет место. Если это именно PDF - вполне вероятно, что там навалены какие-нибудь сканы документов с диким разрешением, и их можно просто взять и пожать, скажем, ps2pdf -dPDFSETTINGS=/ebook (ну, или /print, а то и /screen, уж какое там качество на самом деле нужно).
В винде у меня одна галка "сжать папку" решает проблему. В линуксе мне нужен аналог функции. Мне не нужны предлагаемые "костыли", мне нужно решение задачи.

[Сергей]

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

[Сергей]

Adamos,
>весь класс таких документов желательно архивировать не мастурбацией с повторяющимися частями, создающей головную боль на ровном месте, а конвертацией в тот же PDF.
Я не могу изменять пользовательские документы. Если пришел файл на диск, то он должен остаться в неизменном виде.

[Сергей]

Adamos, >я прекрасно понимаю причины стабильной популярности Ёкселя среди чайников.
Эксель - это отличный инструмент, решающий огромное количество разных задач. Даже расположение стоек в серверной удобно накидывать на скорую руку. А отчеты, диаграммы и еще миллион задач проще в экселе обрабатывать. Можно под конкретные задачи можно CRM, 1C, БД прикручивать с интерфейсами. Только на мелкие задачи накладные расходы выйдут дикие.

[Сергей]

Adamos,
>CRM с веб-мордой - и никаких rocket science с оверскиллами.
В бизнесе все трудозатраты переводятся в деньги. Если у пользователя стоит задача вбить хотелки по отпускам сотрудников отдела, ты будешь городить 1С и CRM? Таких задач есть еще миллион. А людей, которые тратят десятки и сотни тысяч рублей на переизбыточную автоматизацию, увольняют. CRM - для одних задач, 1С - для других. В офисе огромное количество задач, для которых эти системы нафиг не нужны.

[rPman]

sergey_privacy, я ответил на вопрос, штатный инструмент архивации файлов 'на лету' есть в btrfs, он же как мне кажется лучший (его степень сжатия выше ntfs при той же нагрузки на процессор или незначительно выше, а если взять среднюю то вообще вне конкуренции).

если боишься проблем, не включай поддержку raid5 (реализуй ее через mdadm) и не меняй размеров файловой системы на лету/не добавляй удаляй устройств (хотя лично у меня процесс удаления с устройства с raid5 из 5 дисков прошел нормально, файлов много, используется годами, но да это не показатель), максимально простой сценарий использования без необычностей.

p.s. да не получится чекбоксик нажать, необходимо в консоли у файловой системы настроить степень сжатия а затем с помощью утилиты ос chattr изменить флаги на файлах и каталогах, затем нужно либо повторно скопировать каждый файл либо запустить дефрагментацию (по факту это то же самое)

Answer 3

[Рональд Макдональд]

Ну поехали.
1. Юзайте. Её более-менее довели до ума, можете поюзать. Разумеется, у вас должны быть бэкапы.
2. Она ридонли.
3. Докинуть памяти на сервер.

Answer 4

[rPman]

btrfs + zstd сжатие