>У меня стоит слакварь 10 версии. А проблемы вот какого рода.
>Есть сервак samba+ftp все это на слакваре 9. Туда абсолютно нормально можно
>по фтп или самба залить файлы обьемом 5 Гигабайт (к примеру)
>с машины w2000. Оттуда же их взять.... Но если их
>оттуда брать linuxом 10 слакварь... то скопировать например, по фтп еще
>как-то получается, а вот потом скопировать в другой локальный каталог, или
>переместить не получается. Файловая система ext3.... Пробовал разными сресдтвами. cp mc
>файловые менеджеры гнома и кде.... Все одинаково на 2 Гб происходит
>прекращение операции.... Вопрос: Ясно что это проблема слаквари, как с ней
>дела в других дистрах и как ее решить в слаквари? Есть
>ли эти же пакеты для работы с файлами уже собранные с
>поддержкой большЕго объема. Очень не хочется самому компилировать.....
я уже очень давно не имел дела с установкой линукс или его апгрейдом,
обычно эту грязную работу уже выполняют до меня, но примерно могу
обрисовать схему с узкими местами:
характерной особенностью линукса является - раздельные апгрейды ЯДРА
и системы с бинарниками. Что в итоге имеем:
- устанавливаем Linux "Name/Vendor" версия X.Y - это ни о чем не говорит,
потому как поддержку file >= 2GB сперва реализуют в ядре. Значит:
1. Поддержка в ядре File >= 2GB (возможно и скорей всего плюс в той или
иной FS, так как они ко всему прочему пишутся отдельно, НО с расчетом
на то или иное ядро)
- допустим у нас был RH8.x, мы обновили ядро, но бинарники системы
и всяких пакетов остались СТАРЫЕ, нужно объяснить что версии их
могли быть старыми и тут два варианта:
2. Установленный софт не поддерживает >= 2GB
a) версии софта были поправлены на работу с файлами >=2GB, а система
в которой собраный (вызовы, fs и тд и тп...) обрезала эту поддержку
b) софт старых версий и изначально не был ориентирован на поддержку >=2GB
теперь должно быть понятно где могут быть узкие места.
В случае же с compress - либо дело в compress исходя из верхнего, либо
проблема с pipe во что слабо верится:
[alone]~ > ls -la /mnt/pub/lavr/porno/la*
-rw-r--r-- 1 lavr sysct 2939627600 6 окт 12:30 /mnt/pub/lavr/porno/la
-rw-r--r-- 1 lavr sysct 13418496 6 окт 13:02 /mnt/pub/lavr/porno/la.Z
[alone]~ > du -k /mnt/pub/lavr/porno/la
2871456 /mnt/pub/lavr/porno/la
[alone]~ > du -h /mnt/pub/lavr/porno/la
2.7G /mnt/pub/lavr/porno/la
[alone]~ > ls -la /mnt/pub/lavr/porno/la*
-rw-r--r-- 1 lavr sysct 2939627600 6 окт 12:30 /mnt/pub/lavr/porno/la
-rw-r--r-- 1 lavr sysct 374800384 6 окт 13:07 /mnt/pub/lavr/porno/la.Z
[alone]~ > ls -la /mnt/pub/lavr/porno/la*
-rw-r--r-- 1 lavr sysct 2939627600 6 окт 12:30 /mnt/pub/lavr/porno/la
-rw-r--r-- 1 lavr sysct 3002843136 6 окт 13:47 /mnt/pub/lavr/porno/la.Z
[alone]~ > ls -la /mnt/pub/lavr/porno/la*
-rw-r--r-- 1 lavr sysct 2939627600 6 окт 12:30 /mnt/pub/lavr/porno/la
-rw-r--r-- 1 lavr sysct 3456942080 6 окт 14:02 /mnt/pub/lavr/porno/la.Z
[alone]~ > ls -la /mnt/pub/lavr/porno/la*
-rw-r--r-- 1 lavr sysct 2939627600 6 окт 12:30 /mnt/pub/lavr/porno/la
[alone]~ >
Вот реальный пример, результат работы compress - ничего, в данном случае
ответ прост - исходный файл был сжат более плотно чем это можно было
сделать с compress, но факт работы compress с файлами >= 2GB на лицо
и потение процессора на конкретном верхнем примере ~ 30 минут.
Вариант для распечатки
OpenNET: Виртуальная конференция (Public)
(??) on
30-Сен-04, 21:03 (MSK)
