Ext4 и прозрачное сжатие директорий

купи постгрю про энтерпрайз, он умеет сжимать нативно )

Кстати вот ещё, hfs+ под макОС 10.6+ умеет в сжатие:

https://github.com/RJVB/afsctool

Не знаю правда, открыта ли ядерная часть драйвера ….

Кстати, чем та Санта-Барбара закончилась? На Грега все наплевали?

Кстати, чем та Санта-Барбара закончилась? На Грега все наплевали?

Ну, да? Как и на Лойнуса. Потому что а херли они сделают-то? В суд подадут? Хахахахахахахахахах!

в NTFS есть что-то вроде CoW, называется Shadow Copy

Прозрачное сжатие в «люниксе» прекрасно работает в btrfs, просто ТС - потужный клоун в амплуа «горлопанчик-обличитель», ему не проблему решить, а покрасоваться какой он молодец, облив говном тех, кто что-то делает, типичное поведение латентного педераста среднего возраста.

Теоретически да. Нештатным патчем с шансами поработать бэта-тестером. На практике возьми лучше zfs или btrfs.

Так CoW или дедупликация? Это разные вещи.

Вот кстати сложный вопрос. NTFS классическая, хорошо обкатана (причём и через ntfs-3g и по-другому) и под неёкуча софта восстановления данных.

ext4 не поддерживает сжатие на уровне ФС. Как бы для того разные ФС и существуют, что у них набор фич разных. ... Если в ext4 добавить сжатие, она перестанет быть ext4

Ага, она станет ext5. Ext это внезапно он extended, т.е. расширяемая ФС. Сейчас в ней есть инструменты для ключения прозрачного шифрования, а алгоритм шифрования и алгоритм сжатия отличаются довольно мало.

Ага, она станет ext5. Ext это внезапно он extended, т.е. расширяемая ФС.

Да, возможно, но не ext4 ;)

алгоритм шифрования и алгоритм сжатия отличаются довольно мало

А вот тут не соглашусь. Алгоритмы как таковые, вне контекста ФС — да, имеют что-то общее. Но в контексте ФС, инод, экстентов, подсчёта занятого и свободного места, и всей вот этой фигни, разница огромная. Мало просто применить условный zstd к записываемым данным, это как раз легко (как и применить шифрование), важно здесь как раз запилить все окружающие это дело интерфейсы.

Потому что прозрачного сжатия без CoW/RoW (оно же «write anywhere») не бывает.

Легко, NTFS. Просто добавляешь флаг сжатия и если он есть прогоняешь данные через компрессор и забиваешь на то, что экономия будет только целыми блоками.

Но в контексте ФС, инод, экстентов, подсчёта занятого и свободного места, и всей вот этой фигни, разница огромная.

Ладно, согласен, тут нужен не просто флаг, но ещё 1 дополнительное поле: размер файла реальный и сжатый. К сожалению с необходимостью провести декомпрессию при проверке ФС, но это того стоит.

Полноценного CoW не требуется. Атомарности можно достичь блокировкой ожидания доступа пока идёт запись нового блока/экстента и пометка старого как пустой. И можно сгладить всё это кешированием. Собственно как сейчас в ехт2-4 работает механизм изменения размера файла в середине без полной перезаписи?

Сжатие предполагает изменение размера блока, а блочное шифрование специально гарантирует что шифрованный блок будет такой же длинны и его можно положить в тот же блок на диске. Причём это в первую очередь требование безопастности а не удобство для ФС.

Если грамотно и вовремя писать метаданные, то всего лишь останешься с версией файла до перезаписи, а на ФС бразуются некорректно помеченные занятыми блоки, которые высвободятся в процессе проверки.

И тем не менее, это эффективно работает и многие хотели бы увидеть эту фишку в ext*. Хотя наверняка можно и лучше, но даже так хорошо.

но ещё и двойной оверхед на его журналирование

Да откуда ты вообще взял, что его нужно полностью журналировать?

Ей богу, проще сервер передеплоить уже с ZFS. Займёт гораздо меньше времени.

Скорее всего именно так и стоит поступить. Это вроде даже очевидно, если бы вклчюаение сжатия было простым и доступным прямо на ехт4, то это было бы галочкой в инсталяторе каждого первого дистрибутива.

это не в нтфс :)
Shadow Copy - сервис в операционке, надстройка «чуть повыше» файловой системы.
сама нтфс про CoW ничего не знает.

тоноко намекаю: есть утилита прозрачной конвертации ext* в btrfs без перезаписи файлов на разделе.
при этом сколь помню ext* остается и можно както к чему даже вернутся.

Если не соблюдать атомарность (без data=journal), то без сжатия ты получишь смесь старых и новых данных, а со сжатием — мусор.

kirill_rrr

Да откуда ты вообще взял, что его нужно полностью журналировать?

См. выше.

Ты тут ересь какую-то извергаешь

Да нет, ты. В предыдущем треде с «уязвимостью» run0 обосрался, теперь ещё и здесь пытаешься строить из себя умника 🙃

То есть, и правда не было, но непонятно как это к размеру кластера-то относится, потому что кластеры по 4к как раз были.

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

Полноценного CoW не требуется. Атомарности можно достичь блокировкой ожидания доступа пока идёт запись нового блока/экстента и пометка старого как пустой.

Ну то есть ты придумал CoW?

Собственно как сейчас в ехт2-4 работает механизм изменения размера файла в середине без полной перезаписи?

Это всё очень здорово, только extent splitting означает, что начало и конец старого экстента сами по себе остаются валидными экстентами. У FALLOC_FL_COLLAPSE_RANGE есть соответствующее ограничение на выравнивание границ операции. А если экстент сжат, то ты не можешь просто обрубить его в произвольном месте и сказать «теперь начало этого экстента здесь».

Для работы со сжатыми экстентами тебе нужна совсем другая структура данных, и ФС с этой структурой данных будет иметь совсем другие свойства. То есть это будет не ext4.

Ну то есть ты придумал CoW?

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

Это всё очень здорово, только extent splitting означает...

Или можно например отказаться от работы со сжатыми файлами с помощью экстентов и перейти на мелкоблочную разметку и прикрутить сверху ещё какую нибудь оптимизацию упаковки. Или не прикручивать и просто смириться что файлы меньше 1 блока сжиматься не будут. Блин, да даже этот примитивный метод ntfs доказал свою эффективность!

См. выше.

Я читал всё выше. Там «ну просто потому что», причём даже несмотря на «но вот смотри, ntfs». Достаточное подобие атомарности достигется и без CoW, и даже без журнала, и возможное изменение размера в середине файла это не непреодолимое препятствие. По кроайней мере не большая проблема, чем аналогичные операции над несжатыми классическими ФС со всей сопутствующей фрагментацией и перезаписью.

Если не соблюдать атомарность (без data=journal)

Запись данных в журнал точно так же не физически не атомарна. Будем журналировать журнал? Или всё таки ограничимся псевдоатомарностью через быстрые операции редактирования метаданных, никак не связанные с журналируемостью?

ты точно понимаешь, что такое атомарность операций?

Кстати, ехт* что так, что так просто выбрасывает огрызки файла, если сбой ФС произошёл прямо во время записи и метаданные оказались сильно повреждены. И эти огрызки совершенно точно не восстановятся в целый файл - где то там будут откушенные блоки. Сжатие не сильно усугубит ситуацию.

Млять, вместо того что бы выгуливать своё клоунское эго, лучше бы реально раскопал и притащил какую-нибудь ссылку на то, как NTFS пишет пожатые данные.

С твоим участием любая потенциально интересная дискуссия превращается в унылую клоунаду.

Послужи уже на благо экологии - забанься.

По определению - совершение всей операции либо целиком корректно, либо никак. Причём таким образом, что в логике системы это можно было считать мгновенным.

По определению - совершение всей операции либо целиком корректно, либо никак

ну, и зачем тогда журналировать журнал?

Из уже мелькавшей в треде ссылки https://www.ntfs.com/ntfs-compressed.htm только такое описание :

NTFS provides real-time access to a compressed file, decompressing the file when it is opened and compressing it when it is closed. When writing a compressed file, the system reserves disk space for the uncompressed size. The system gets back unused space as each individual compression buffer is compressed.

Там «ну просто потому что», причём даже несмотря на «но вот смотри, ntfs»

Значит, у тебя проблемы с восприятием письменного текста.

Запись данных в журнал точно так же не физически не атомарна

А ты в курсе, что такое журнал?

Ничё так тебя рвёт. Иди траву потрогай, что ли.

Кстати, ехт* что так, что так просто выбрасывает огрызки файла, если сбой ФС произошёл прямо во время записи и метаданные оказались сильно повреждены

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

Запись метаданных журналируется всегда.

если сбой ФС произошёл прямо во время записи

Я удивлён, что об этом нужно рассказывать человеку, который пытается участвовать в дискуссиях об ФС, но когда говорят об отказоустойчивости, имеют в виду не сбои самой ФС, а прерванные записи: сбой питания, сбой системы в целом. В этом случае без сжатия на диске окажется смесь старых и новых данных, а со сжатием (без CoW или журналирования данных) — мусор вместо перезаписываемого экстента/блока. Нужно объяснять, почему?

А как вообще журнал связан с атомарностью?

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

А ты в курсе, что такое журнал?

Блоее менее да. Это (внезапно) журнал событий и операций, куда дублируются изменения метаданных. Очень помогает при восстановлении. Не уверен, но кажется сначала будущая операция записыватся в журнал и только потом производится, это помогает организации атомарности, но не является обязательным для неё.

Значит, у тебя проблемы с восприятием письменного текста.

А у тебя с аргументацией.

Так вроде и без него можно. ехт2 довольно близка к этому а жкрнал нужен чтобы ускорить восстановление сбоя.

но не является обязательным для неё

да, вместо журнала можно использовать cow

Блоее менее да. Это (внезапно) журнал событий и операций

Это такая штука, запись в которую идёт строго подряд, и каждая операция сопровождается порядковым номером и чексуммой. Атомарность записи в журнал достигается тупо логически: если мы нашли там запись с подходящим номером и совпадающей чексуммой — значит, она целая. Если номер прыгнул назад или чексумма не совпала — значит, запись невалидна и чтение журнала прекращается.

А у тебя с аргументацией.

Да нет, с аргументацией всё норм: я привёл несколько способов реализовать прозрачное сжатие без CoW, и пояснил, почему каждый из них сосёт.

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

Обрыв питания именно в момент их записи. Шансы 1 раз на 10 лет аптайма, но бывает же!

а со сжатием

...внезапно тоже смесь старых и новых данных, потому что даже если не атомизировать операцию через запись метаданных, никто со времён ФАТ (или даже раньше, потому что в ХР недозаписанные файлы часто выживали) не затирает данные прямо поверх старых блоков. А особенно это будет маразмом если блоки сжатые!

имеют в виду не сбои самой ФС

С питанием всё понятно, но что если крах в ядре, драйвере чего то, связанного с дисками, в оперативке или собственно в драйвере ФС - а я такое встречал на ntgs-3g, f2fs и btrfs.

Да и по отвалам дисков и сбоям питания - принципиальной разницы в атомарности и выживаемости файлов на ехт2 и ехт4 я не вижу, а ведь юсб2-сата хабы мегабренда dexp обеспечивают мне богатый опыт! ехт2 точно так же находит сбойный файл при прверке и утилизирует его. А ехт4 точно так же может потерять файл несмотря на журнал - просто проверится быстрее и легче вычистит мелкие огрехи.

Да нет, с аргументацией всё норм

Нет аргументации, нет проблем.

и пояснил, почему каждый из них сосёт.

Неа. И главное - ты не дал никаких аргументов против описанного мной очевидного способа, который не является CoW.

Обрыв питания именно в момент их записи. Шансы 1 раз на 10 лет аптайма, но бывает же!

Естественно, в момент их записи. Любой другой обрыв питания рассматривать не имеет смысла.

В случае обрыва питания в момент записи метаданных они останутся в полном порядке, т. к. любое их изменение в ext3+ журналируется.

…внезапно тоже смесь старых и новых данных, потому что даже если не атомизировать операцию через запись метаданных, никто со времён ФАТ (или даже раньше, потому что в ХР недозаписанные файлы часто выживали) не затирает данные прямо поверх старых блоков. А особенно это будет маразмом если блоки сжатые!

А я тебе о чём говорю?

даже если не атомизировать операцию через запись метаданных

Что такое «атомизировать операцию через запись метаданных» (кроме того что это бессмысленный набор слов)?

Если ты не умеешь читать, проблем действительно нет.

против описанного мной очевидного способа, который не является CoW

Описанный тобой способ называется CoW (только ты ещё и предлагаешь выкинуть экстенты, что тоже сосёт по производительности).

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

Процитирую тебя же:

обосрался, теперь ещё и здесь пытаешься строить из себя умника 🙃

От безысходности я начал пилить сжатие на базе ext2, правда с потерей совместимости…

timdorohin

Лол у нас на бенчах тупо смена ext4 на zfs+lz4 увеличила производительность запросов почти в два раза. На одинаковом железе, одинаковой версии postgresql и так далее.

А базу бэкап-рестором переносили?

А уж из-за 300G городить всё это ещё более странно.

Схерали? Я за этот диск деньги плачу.

Вы на спичках тоже экономите?

Ну в базе 95% операций - это чтение обычно.

1. «база» и «обычно» это крайне сферично.
2. Вы из какого гугла цифирку «95%» взяли?