Предложите метод сжатия файла при отсутствии свободного места ФС

[smaharbA]

Есть файл - пусть 20 Гб, на ФС 1 - 2 Гб свободного места. Предложите варианты сжатия исходного файла без привлечения внешних/сетевых носителей.
Файл должен быть сжат как единое целое, т.е. с возможностью его использования в приложениях.

Варианты есть, нужен вариант без временных файлов (не считая самого гз бз2) и вариант распаковки сжатого без наличия свободного места, зная, что свободное+архив достаточно для распаковки


(Все в пределах штатных и общедоступных команд/утилит шела)

[Bizdelnick]

Файл насколько сильно жмётся, в нём текст? А оперативки сколько?

[smaharbA]

Файл насколько сильно жмётся, в нём текст? А оперативки сколько?

а в сабже не понятен размер файла ?

предположим заданный в сабже размер файла, т.е. 20 Гб, свободного места ФС 1 Гб, ОЗУ свободно или все 256 Мб
+ и нет внешних хранилищь

[Bizdelnick]

а в сабже не понятен размер файла ?

Непонятен хотя бы приблизительный размер файла после сжатия. И непонятно, сколько файл реально занимает на диске. Хотя прочих условий достаточно, чтобы сказать, что сие почти наверняка невозможно.

[smaharbA]

ФС одна однешенька
есть файл в ФС - его размер 20 Гб
есть свободного места в ФС - 1-2 Гб
степень сжатия файла неизвестна (но более 1)
есть ОЗУ - 256-1024 Мб

нужно сжать исходный файл с заменой несжатого на сжатый

методы ? (желательно без временных файлов, с временными метод существует)

Можно и с временными - может будет интересен метод.

[/dev/random]

Есть (опасный) вариант: dd'шкой читаем файл большими блоками, передаём компрессору, другой dd'шкой пишем обратно без обрезания. В конце смотрим, сколько записалось, и обрезаем.

Не делайте этого, если не уверены, что в файле нет плохо сжимаемых частей. Не делайте этого, если используете btrfs или что-то подобное. Не делайте этого, если есть риск, что процесс что-то прервёт.

Метод непригоден для декомпрессии.

[smaharbA]

Есть (опасный) вариант: dd'шкой читаем файл большими блоками, передаём компрессору, другой dd'шкой пишем обратно без обрезания. В конце смотрим, сколько записалось, и обрезаем.

Не делайте этого, если не уверены, что в файле нет плохо сжимаемых частей. Не делайте этого, если используете btrfs или что-то подобное. Не делайте этого, если есть риск, что процесс что-то прервёт.

Метод непригоден для декомпрессии.

метод близок к существующему
опасности в потере не существует

а теперь пожалуйста напишите как Вы будете обрезать от начала ?
архив нужен такой же как если бы был сделан при достаточности свободного пространства

[/dev/random]

а теперь пожалуйста напишите как Вы будете обрезать от начала ?
архив нужен такой же как если бы был сделан при достаточности свободного пространства

Простейший способ узнать требуемую длину (bash only):
(... | tee >(wc -c >&3) | ...) 3>&1
Если шелл не поддерживает конструкцию >( ), придётся, например, парсить stderr-вывод dd или делать второй (точнее, предварительный) проход сжатия.

Когда длина известна, обрезать файл можно с помощью dd или truncate.

[smaharbA]

как обрезать от начала ?

[/dev/random]

как обрезать от начала ?

Зачем?
Вы, видимо, меня не поняли. Вы, похоже, решили, что я предлагаю _дописывать_ сжатые данные в файл. Вы не правы. Я не зря назвал метод опасным. То, как вы меня поняли, было бы безопасно... если бы работало. Я же предлагаю писать _поверх_.

Не хотелось приводить команду целиком, чтобы кто-нибудь вдруг не применил её на важных данных, но...

truncate -s $( (dd if=file bs=256M | xz | tee >(wc -c >&3) | dd of=file conv=notrunc) 3>&1) file

Да, я в курсе, что если некоторый фрагмент файла, считая от начала, окажется после сжатия длиннее, чем до, то перезапишутся ещё не прочитанные данные. Поэтому я и написал, что метод нельзя применять, если вы не уверены в сжимаемости каждого фрагмента файла. И поэтому я написал, что читать нужно большими блоками (в примере - 256M): это несколько уменьшит "флуктуации" сжимаемости.

[smaharbA]

т.е. обрезать и в подстановке сразу сжимать ?
если верно понимаю, то вариант

на текущтй момент действует авриант разбиение исходного файла с нумерацией от обратного и потоком последовательное сжате с удалением отправленного куска (файла)

спасибо (если верно понял) - сделаю и такой вариант Вами предложенный

и еще попутно - существует ли возможность создания из шела временных файлов - как FILE_ATTRIBUTE_TEMPORARY ?

[/dev/random]

т.е. обрезать и в подстановке сразу сжимать ?
если верно понимаю, то вариант

Скорее, сжать и обрезать, а не обрезать и сжать, т.к. соманда truncate будет выполнена лишь после того, как отработает всё остальное.

* первая dd читает файл
* xz сжимает его
* tee копирует сжатый поток на счётчик wc
* вторая dd перезаписывает данные в файле сжатыми
* когда процесс завершается, wc выдаёт длину сжатых данных
* эта длина подставляется в truncate
* файл обрезается по этой длине.

[smaharbA]

т.е. обрезать и в подстановке сразу сжимать ?
если верно понимаю, то вариант

Скорее, сжать и обрезать, а не обрезать и сжать, т.к. соманда truncate будет выполнена лишь после того, как отработает всё остальное.

* первая dd читает файл
* xz сжимает его
* tee копирует сжатый поток на счётчик wc
* вторая dd перезаписывает данные в файле сжатыми
* когда процесс завершается, wc выдаёт длину сжатых данных
* эта длина подставляется в truncate
* файл обрезается по этой длине.

не суть, понятно

[drBatty]

Есть файл - пусть 20 Гб, на ФС 1 - 2 Гб свободного места. Предложите варианты сжатия исходного файла без привлечения внешних/сетевых носителей.
Файл должен быть сжат как единое целое, т.е. с возможностью его использования в приложениях.

no way в общем случае.

Есть (опасный) вариант: dd'шкой читаем файл большими блоками, передаём компрессору, другой dd'шкой пишем обратно без обрезания. В конце смотрим, сколько записалось, и обрезаем.

я-бы не стал пользоваться такими методами...

и еще попутно - существует ли возможность создания из шела временных файлов - как FILE_ATTRIBUTE_TEMPORARY ?

man 1 mktemp
не?

[NickLion]

Можно дополнить вариант /dev/random'а буфером во временном файле, если сжатый блок превысил размер исходного. Но на shell'е такое сделать, наверное, сложновато. Я бы на Си писал. Хотя может просто потому, что я его значительно лучше знаю.

[smaharbA]

man 1 mktemp
не?

Нет, нужно что то подобное tmpfs, но как атрибут объекта (файла)

[Ленивая Бестолочь]

Можно дополнить вариант /dev/random'а буфером во временном файле, если сжатый блок превысил размер исходного. Но на shell'е такое сделать, наверное, сложновато. Я бы на Си писал. Хотя может просто потому, что я его значительно лучше знаю.

есть такое - stdbuf.

[Ism]

Все это садомазохизм.
Если у компа есть сеть, все решается netcat http://blog.vpsville.ru/blog/howto/10.html
Если usb , то большой флешкой.
Если DVD, то записью кусками