Если Вы восстановили ту же версию ядра и получаете ту ошибку, возможности являются патчем, который Вы применили, изменил что-то, что в ядре, на которое ссылается модуль. Это в значительной степени гарантирует, что собирается аварийно завершиться. Необходимо будет найти источник для того модуля и скомпилировать его снова против нового ядра так, чтобы он имел корректные ссылки.
Существует также некоторый шанс, который это не скомпилирует вообще и должно быть изменено для соответствия безотносительно модификаций сделанный патч ядра.
AFAIK там не является никаким пределом размера для gzip
- по крайней мере, не 30 ГБ. Конечно, Вам нужно пространство для заархивированного файла на Вашем диске, обе версии будут там одновременно при сжатии.
bzip2
файлы сжатий (не только большие :-) лучше, но и это (иногда много) медленнее.
при необходимости в хорошем уровне сжатия можно попробовать lzma., это быстрее и более эффективно, чем bzip2 и может быть быстрее даже, чем gzip (я не знаю это наверняка),
http://www.thegeekstuff.com/2010/06/lzma-better-compression-than-bzip2-on-unix-linux/
lzma
удерживается от использования в пользу xz
теперь. Тот же алгоритм, несколько отличающийся (улучшенный?) формат файла перенес его. LZMA медленнее, чем gzip, но в максимальной скорости это - все еще довольно хорошее сжатие на очень избыточном материале как данные JSON. (xz -0
)
– Peter Cordes
11.08.2015, 22:41
Формат gzip представляет входной размер по модулю 2 ^ 32, поэтому опция
- list
сообщает о некорректных размерах несжатых файлов и степени сжатия для несжатых файлов размером 4 ГБ и больше.
Итак, возьмите bzip2
(v1.0.2 и выше) или xz
.
Если вы работаете в предел, переставьте. Вместо:
gzip file
сделать:
gzip < file > file.gz
работает просто хорошо.
pbzip
, также - который будет использовать больше чем одно ядро процессора. Но все еще путь медленнее, чемgzip
. – Nils 10.06.2012, 23:45pbzip2
– rubo77 29.08.2013, 19:31