Вчера когда делал очередной сайт, заметил следующее, почему-то при распаковке архива bz2 некоторые текстовые файлы усекаются, а когда просто открывают в Ark архив посмотреть, то файлы нормальные, кто подскажет в чем дело ?
LinuxForum.Fans
Неправильно распаковываются архивы bz2
Автор: zet_lab
20 сообщений
6152 просмотров
Распаковываю их программой bunzip2, никогда ничего не усекалось.
Пётр.
Вчера когда делал очередной сайт, заметил следующее, почему-то при распаковке архива bz2 некоторые текстовые файлы усекаются, а когда просто открывают в Ark архив посмотреть, то файлы нормальные, кто подскажет в чем дело ?
наверное архивы битые. или памяти мало. Какой код ошибки? Какая версия bzip2? Какая команда распаковки? Можно маленький проблемный файл выложить?
Распаковываю их программой bunzip2, никогда ничего не усекалось.
нет такой программы. Это то-же bzip2, но с ключом -d.
(точнее, это симлинк на bzip2, и если через него запускать, добавляется ключ -d)
drBatty
открываю архив с помощью Ark без распаковки, просматриваю php файлы и все нормально, распаковываю, все нормально распаковывается без ошибок, но у одного или двух файлов отсутствует часть кода, приходится открывать этот же файл в архиве и копировать из него...
прикол в том, что если открою архив и тупо скопирую содержимое в папку, то все распакуется нормально...
[quote=Peter]Распаковываю их программой bunzip2, никогда ничего не усекалось.
нет такой программы. Это то-же bzip2, но с ключом -d.
(точнее, это симлинк на bzip2, и если через него запускать, добавляется ключ -d)[/quote]
А у меня есть такая программа
[console]-rwxr-xr-x 3 root root 31688 Sep 21 11:07 /bin/bunzip2[/console]
Пётр.
zet_lab, радуйтесь ;)
моя версия
[console]doc@dt:~$ ark --version
Qt: 4.6.2
KDE: 4.4.3 (KDE 4.4.3)
Ark: 2.14
[/console]
вообще bz2 не распаковывает. Только просмотр работает. Пользуйтесь консолью или mc (последний очень удобен - вы можете распаковывать файлы прямо на сайт по FTP или SSH).
А у меня есть такая программа
ну и что? возможно (надо сырцы глянуть), эта версия применяется например в инсталляторах для лёгкости - ведь инсталлятор ничего не пакует, а только запаковывает. Или ещё где-нибудь. (Кстати, замете, она у вас в /bin - там лежит необходимый МИНИМУМ для старта системы. А зачем при старте что-то паковать? А весь остальной софт лежит в /usr, который может быть и удалённо. Кроме того, не забывайте про встроенные системы)
[quote=Peter]А у меня есть такая программа
ну и что? возможно (надо сырцы глянуть), эта версия применяется например в инсталляторах для лёгкости - ведь инсталлятор ничего не пакует, а только запаковывает. Или ещё где-нибудь. (Кстати, замете, она у вас в /bin - там лежит необходимый МИНИМУМ для старта системы. А зачем при старте что-то паковать? А весь остальной софт лежит в /usr, который может быть и удалённо. Кроме того, не забывайте про встроенные системы)[/quote]
bzip2 и вообще все исполнимые файлы из пакета bzip2 у меня находятся в/bin.
А в /usr/bin нагодится pbzip2 - многопотоковая реализация bzip2.
Пётр.
bzip2 и вообще все исполнимые файлы из пакета bzip2 у меня находятся в/bin.
А в /usr/bin нагодится pbzip2 - многопотоковая речлизация bzip2.
зачем?
ЗЫЖ
text
PACKAGE NAME: bzip2-1.0.6-i486-1_slack13.1
...
lib/
lib/libbz2.so.1.0.6
bin/
bin/bzip2
bin/bzip2recover
usr/
usr/lib/
usr/lib/libbz2.a
...
usr/bin/
usr/bin/bzdiff
usr/bin/bzgrep
usr/bin/bzmore
...
многопоточность - не нужно. (С) Патрег ;)
[quote=Peter]bzip2 и вообще все исполнимые файлы из пакета bzip2 у меня находятся в/bin.
А в /usr/bin нагодится pbzip2 - многопотоковая речлизация bzip2.
зачем?
многопоточность - не нужно. (С) Патрег ;)[/quote]
Я ни разу не пользовался ни тем, ни другим, но многопоточнность нужна,
если процессор многоядерный.
Пётр.
Я ни разу не пользовался ни тем, ни другим, но многопоточнность нужна,
если процессор многоядерный.
Ой-ли? Пользовались. Только вы об этом не знаете. В Linux одна большая задача решается десятками, а иногда тысячами мелких утилиток.
Что до многозадачности... Понимаете, bzip2 безнадёжно устарел, и его держат исключительно ради совместимости. xz даёт намного более лучшие результаты (алгоритм LZMA2). Эффективно распараллелить сжатие почему-то не получается, ИМХО это связанно с особенностями архитектуры x86 (любопытный, кстати, случай - идеально распараллеливамый алгоритм с т.з. математики не распаралеливается на практике. Видимо это связано с тем, что архиваторы работают с огромными массивами памяти, но у нас нет "двух-памятных" компьютеров (двойная скорость - не то). Мало того, у нас даже двухпроцессорных нету - потому как ядро CPU это вовсе не процессор). Потому, в архивировании и распаковке данных многопоточность - не нужна.
(я не говорил о специальных случаях! например про MPEG).
zet_lab, кстати, распаковка "не нужна", в том смысле, что она часто выполняется сама по себе. Например можно сохранить web страничку с картинками и прочим, потом сжать, а потом просматривать этот архив обычным браузером как обычный каталог. Воспринимайте архив как обычный каталог ;)
(хотя почему у нас глючит ark - без понятия - по идее, можно прямо мышкой перетаскивать файлы из ark'а на ваш сайт, но у меня так не получается - Application: Ark (ark), signal: Segmentation fault )
Для выяснения проблем запускайте ark в консоли.
А пока не исправили - пользуйтесь консольными программами - они не глючат, я гарантирую это ;)
поправка:
Если использовать Dolphin 1.4, то всё работает. Мало того, можно переносить файлы мышкой не только в обычные, но и в сетевые каталоги, например на ssh. Из арка надо мышкой переносить, но вот в арк так не переносится. Ничего не усекается.
[quote=Peter]Я ни разу не пользовался ни тем, ни другим, но многопоточнность нужна,
если процессор многоядерный.
Ой-ли? Пользовались. Только вы об этом не знаете. В Linux одна большая задача решается десятками, а иногда тысячами мелких утилиток.
Что до многозадачности... Понимаете, bzip2 безнадёжно устарел, и его держат исключительно ради совместимости. xz даёт намного более лучшие результаты (алгоритм LZMA2). Эффективно распараллелить сжатие почему-то не получается, ИМХО это связанно с особенностями архитектуры x86 (любопытный, кстати, случай - идеально распараллеливамый алгоритм с т.з. математики не распаралеливается на практике. Видимо это связано с тем, что архиваторы работают с огромными массивами памяти, но у нас нет "двух-памятных" компьютеров (двойная скорость - не то). Мало того, у нас даже двухпроцессорных нету - потому как ядро CPU это вовсе не процессор). Потому, в архивировании и распаковке данных многопоточность - не нужна.[/quote]
Я имел в виду, что руками его не запускал, а log-файлы сжимаются gzip'ом.
Вот о существовании xz действительно не знал, хотя он у меня есть.
Я не силён в терминологии, но аппаратное ядро считаю процессором, т.к. в нём есть всё,
чтобы так называться, и при работе кэш 3-го уровня у каждого ядра свой. Они могут
изменять свой размер, но всё же область памяти у каждого ядра своя.
Пётр.
Я имел в виду, что руками его не запускал, а log-файлы сжимаются gzip'ом.
Вот о существовании xz действительно не знал, хотя он у меня есть.
используйте. только учтите - он может пожрать сотни метров памяти. И если памяти мало - начать свопиться, и тормозить.
Я не силён в терминологии, но аппаратное ядро считаю процессором
зря. по моим тестам - это совсем не процессор.
т.к. в нём есть всё,
чтобы так называться, и при работе кэш 3-го уровня у каждого ядра свой.
а я больше верю своим тестам, чем памфлеткам от Intel. К тому-же, жалкий и ничтожный размер самого малого кеша делённый на число процессов кагбэ намекает...
Они могут
изменять свой размер, но всё же область памяти у каждого ядра своя.
вот только обращаться к каждой области они будут строго по очереди. Сначала первый, потом второй. И никак иначе.
Да не, когда можно вписаться в 1000-10000 байт, всё нормально, многоядерность рулит. Вот только в царстве сжатия правят величины >1048576. Забудьте о кешировании.
Ну грубо говоря: один процесс забирает себе 100Мб, причём на каждой следующей итерации алгоритм обращается к ЛЮБОЙ из этих 100 000 000 ячеек памяти. Кеширование невозможно В ПРИНЦИПЕ. Ну и тут уже совсем не важно, один процессор, или 1024 - всё упирается в память, которая тормозит всё остальное.
Самое обидное - чем более "кешируем" алгоритм, тем он хуже по степени сжатия. Т.е. для максимального сжатия нужен максимально случайный разброс по памяти. Ну и память как можно больше. Потому сегодня лучшие алгоритмы работают на скорости работы DDR. Для HDD это просто смешно, для кеша - грустно (лучше юзать LZ77/78).
Выводы: на сегодня, имея несколько гигов памяти, на них и надо рассчитывать. четверть гига, пол гига, гиг, два гига, четыре гига, восемь гигов, 16 гигов, 32 гига... Ну вот и вся линейка на сегодня. Я из этого исхожу. Я не прав?
Всё-таки аппарато ядро - это отдельный процессор, в нём же есть всё,
что есть в отдельном процессоре.
Насчёт работы с памятью и использования кэша 3-го уровня - точно не знаю,
но, насколько мне запомнилось, одно ядро не может захватить весь кэш
процессора, что-то всегда остаётся и другим ядрам, т.е. они работают всё же
каждое со своим кэшем.
Вот шина памяти для обращения к ОЗУ действительно одна, если одно ядро
инетенсивно обменивается с памятью, то другим приходится ждать, но от
этого они не перестают же быть процессорами.
Пётр.
Peter, в общем плане - не могу не согласиться. Но только в общем. Сжатие данных - специфическая задача - требуется случайный доступ в большой кусок памяти, потому никакое кеширование тут попросту не работает (невозможно предсказать в какую ячейку будет доступ, потому как именно эту задачу и решает архиватор - предсказание следующего байта на основе истории предыдущих). Если как-нибудь выключить все кеши, то это не изменило-бы скорость сжатия. А шина у памяти всего одна...
ЗЫЖ всё-же, не все модули в многоядерном процессоре персональные для каждого ядра. Только я не знаю, какие из них общие...
У последних моделей кэши большие. но речь была о том, является ли ядро
самостоятельным процессором. Если бы вместо многоядерного процессора
было бы несколько одноядерных, то они точно так же использовали одну и
ту же шину для доступа к памяти, т.е. в этом смысле разницы нет,
а в многоядерном узел, координирующий доступ ядер к общим ресурсам
системы, находится в самом кристалле, что лучше, если бы он был
отделной микросхемой. Хотя, возможно, в многопроцессорных платах
эту задачу выполняет один из процессоров.
Пётр.
Если бы вместо многоядерного процессора
было бы несколько одноядерных, то они точно так же использовали одну и
ту же шину для доступа к памяти, т.е. в этом смысле разницы нет,
там для каждого процессора своя память. например: http://www.f1cd.ru/news/motherboard/111/
[quote=Peter]Если бы вместо многоядерного процессора
было бы несколько одноядерных, то они точно так же использовали одну и
ту же шину для доступа к памяти, т.е. в этом смысле разницы нет,
там для каждого процессора своя память. например: http://www.f1cd.ru/news/motherboard/111/[/quote]
Вот этого то ли не знал, то ли не обращал внимания. С учётом этого,
т.е. с точки зрения функциональности, ядро действительно не совсем
процессор.
Пётр.
Войдите или зарегистрируйтесь, чтобы ответить.
