> Сколько будет считано с харда при этом при размере архива 20 гиг?

Ты хочешь сказать, что в случае mc будет считано меньше?

Не пойму какие проблемы?

Ты пишешь с одной стороны в трубу (pipe), я с другой читаю

фильтрую нужное, все остальное выбрасывается.

Зачем для этого много озу?

# mount name.tar.gz path
mount: error while guessing filesystem type
mount: name.tar.gz is not a block device (maybe try `-o loop'?)
# mount -o loop name.tar.gz path
/dev/loop0: Invalid argument
mount: you must specify the filesystem type
#

Забей, Майкл, глупости это все.

Мы - первые!!!

Я выиграл коньяк!!!

>Развернутое - это временный файл, который создает mc. Это обычный tar-архив и его, естественно, нужно полностью прочитать, чтобы получить список.

Зачем? Я так понимаю, что в таре хранится заголовок файла (включающий размер файла, права доступа, размер), потом файл. Таким образом читаешь заголовок, прибавляешь размер файла, читаешь заголовок следующего файла и т. д. - пропорционально количеству файлов, а не размеру. Файлы же произвольного доступа. А в случае сжатия файлы становятся последовательного доступа.

> в DN есть удобная фича) выделение текста по вертикали) никакие mc тут рядом не стоят)

man vim ? ;-))))

cpio и современный tar рулят.
Я сделал нетворк драйв на базе Pentium166/64M (пол-терабайта диски - в сумме) и для регулярного зеркалирования - rsync уходит в своп (видимо - даже индекс не помещается в память),
а делая
(сd /mnt/1; tar cvf - .) | (cd /mnt/2; tar xvf -)
через пайп прогоняются сотни гигабайт без аопросов аки-стрела.
Пайпы рулят.

Если файлов миллионы - любая гуя показывающая такую файлопомойку - навернётся (при 65k файлов в дире я не могу посмотреть диру в XP), подозреваю что то-же самое будет и в любом менагере, так как он должен разместить хотя-бы имена, метадату файлов в структурах. Если жы му делаем какой-нибудь find и пайпим выход на что-то и то что-то не создаёт структур а пишет либо в консоль либо в файл - то могут обрабатываться любые объёмы.

до физиков - далекоооо....

Ну полностью прошагать, разница небольшая.

> Если файлов миллионы

То впору вспомнить, что в свое время, когда дискеты стали большими и файлов на них стало помещатся слишком много, добрые люди придумали такую вещь как каталог.

ИМХО

dump+restore работают существенно быстрее.

Более спец. утилиты работают на уровне inode.

md5sum dir1/* dir2/* | sort | less

А Билл Гейц примерно тогда же придумал Иньтерьнет.

>Ты пишешь с одной стороны в трубу (pipe), я с другой читаю для cat это справедливо на 100%

ещё пример полезных пайпов которые мной используются (можно добавить всякие там --preserve, убрать там -v итд):
cd / ; tar cvf - bin root ... | ssh -l whoyouare remotehost "cd /mnt/1; cat - > backup.tar
обратно:
ssh -l whoyouare remotehost "tar cvf - /bin /root ..." | cat - > backup.tar

можно так для первого:
tar c /mnt/1 | bzip2 | ssh -l whoyouare remotehost "cat > backup.tar.bz2"

а не хотите создавать tar - пайпим сразу на раскрытие - на удалённый хост.

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

>Ну полностью прошагать, разница небольшая.

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

Кстати, а ты точно уверен, что mc не сохраняет список файлов отдельно при извлечении?

2 Sun-ch

я просто не пользовался dump.

>Более спец. утилиты работают на уровне inode.

наверное

кстати я делал когда-то dd для бекапа тож

Эээ... man scp

каталоги - зло ;)

>Ты пишешь с одной стороны в трубу (pipe), я с другой читаю для cat это справедливо на 100%

Да, для gzip это так же справедливо...

> Заметь, что количество прочитанной информации (а следовательно скорость) прямо пропорционально количеству файлов, а не размеру (так как файл на диске произвольного доступа в отличии от ленты). Это аналогично (правда медленнее в константное небольшое число раз) прочтению списка файлов.

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

> Кстати, а ты точно уверен, что mc не сохраняет список файлов отдельно при извлечении?

А ты посмотри. По-моему нет.

поправка:
точнее, не как внутренний хак чтобы скомпенсировать немасштабируемость конкретной файловой системы, а как метод группирования человеком. Либо он из хака _превращается_ в такой метод. Для обхода (поисков) приходится делать рекурсивный find ;)

всё просто: тот, кто сделал архив в 20ГБ, пусть убьёт себя. А для меньших архивов mc рулит, и пусть админы запоминают всякие "нужные" команды и параметры - на то и админы, чтоб помнили

tar говно, а far рулит!

> всё просто: тот, кто сделал архив в 20ГБ, пусть убьёт себя.

Пусть лучше попробывает XFCE аль примонтирует флешку.

>А ты посмотри. По-моему нет.

А если в памяти хранит?

>dump+restore работают существенно быстрее.

что меня ещё немного смущает - это то что dump/preserve - бинарный формат (так?), а про проприетарные проги я не говорю ;)
В случае зеркала даже если одни и те-же блоки посыпятся одновременно на 2 дисках в один день (вероятность почти нулевая но не 0), то как минимум остальные файлы я спасу. Я просто уже слишком много потерял старых прог из-за битых дискет, даже когда имел двойные копии их, а CD-R тож иногда портятся, но верифицировать (даже раз в много лет) вы их не будете _никогда_ - это я вам гарантирую :)

>> Кстати, а ты точно уверен, что mc не сохраняет список файлов отдельно при извлечении?

>А ты посмотри. По-моему нет.

При заходе в tar.gz, mc разжимает и готовый tar кладет в /tmp/mc-user, может с одной стороны он и прав, но с другой... во всем виноват чубайс...

наверное просто стоит проверять доступное место...

и правда отстой какой-то :(

Мдя, и когда появится что-то уровня Far %?

я что хотел здесь сказать. Нераскрытие тара - это только один шаг к масштабируемости. Пример со старым пентюком и малой памятью показывает что очень скоро (уже сейчас) я получаю проблемы даже с метадатой (имена и аттрибуты файлов - если их много).
А учитывая скорость накопления файлов (посчитайте сколько их у вас было в 89, в 99 и сколько будет уже к 09 или 19 году) - вы поймёте что надо всегда задумываться о масштабируемости - даже метаданных.
имхо

> tar говно, а far рулит!

ну и чем он рулит? тем что распаковывает tar.gz в C:\Documents and Settings\CurrentUser\Local Settings\Temp\ а не в /tmp/mc-CurrentUser ?

Обоснуй

FAR ацтой! MC тоже. Настоящие бздуны и слакварщики пользуются Total Commander

> Мдя, и когда появится что-то уровня Far %?

если исходники фара когда нибудь откроют, то появится сразу

>Сколько будет считано с харда при этом при размере архива 20 гиг?

Ви не понимеите смысла жизни, с диска данные будут считаны только один раз. После этого они застрянут в файловом кэше и будут браться оттуда. Какбы надо брать подходящее железо под задачу, ну и матчасть самособой нада учить

ерундой не майтесь, маны и хау ту почитайте и забудете про фары и про мс и про xnc и про DN и т.д. ...

Пример типичного Фофана

>>P.S. Ты в Макдональдсе вкалываешь? И там же питаешься?

>Поясните, пожалуйста, смысл сентенции.

>>Менеджеры с острыми зубами и зачесанными назад волосами, продающие эскимосам холодильники и надеющиеся "на конкуренцию с МС", не нужны. Чем больше их сдохнет с голоду, тем лучше.

Эк Вас батенька скрючило от желчи.

А кто даст Фофану не сдохнуть с голоду, даст подзаработать на продаже софта эскимосам, на бигмак хватит.

Вы же заказчику ни чего внятно объяснить не можете, мануал написать , ломает, чего хочет заказчик не понимаете.

Кто вы без менеджера? Не мытое, патлатое, не глаженое существо, одним своим видом отпугивающее заказчика.

Не понимаете смысла конкуренции - молчите в тряпочку, нервно курите в стороне, жуйте - по Вашему выбору. Но не лезте туда где ни чего не понимаете.

> каталоги - зло ;)

Натурально... Рулят архивы в 20, нет лучше в 40G :)

> chto bi faili vitashit, prosto posle probela put k direktoriju ili failu dobavte:

> tar xzvf name.tgz xxx/yyy/zzz

tar xzvf a.tar.gz a tar: z: unknown option Usage: tar {txruc}[vfbFXhiBEelmopwnq[0-7]] [-k size] [tapefile] [blocksize] [exclude-file] [-I include-file] files ...

Мальчик, ты кроме Линукса какой-нибудь Юникс видел вообще?

>Ви не понимеите смысла жизни, с диска данные будут считаны только один раз. После этого они застрянут в файловом кэше и будут браться оттуда. Какбы надо брать подходящее железо под задачу, ну и матчасть самособой нада учить

Мля, я это же объяснял тут одному человеку. Весь тред прочитать не судьба?

Дяденька, скачать и скомпилить http://ftp.belnet.be/mirror/ftp.gnu.org/gnu/tar/tar-1.15.tar.gz не судьба?

смотри выше :)

Человек шутит, а ты ведешься. Или у тебя таки есть под рукой железо, на котором двадцатигигабайтный файл не только влезает в кеш, но и надолго там задерживается?

Может я чего не понимаю, но зачем нужен архив в 20G дома. Фотки нужно сливать по 700М на CD-R, музыку по альбомам - туда же. Так что туда пихать?

> Фотки нужно сливать по 700М на CD-R, музыку по альбомам - туда же.

CD - RIP. Грядет DVD. 4Gb с лишком.

Грядет DVD

Вот будет болванка 10 руб. стоить, а резак 1500. Тогда и поставим. Но не архиваторами же на них паковать.

>Вот будет болванка 10 руб. стоить, а резак 1500. Тогда и поставим. Но не архиваторами же на них паковать.

опыт с дискетами, CD-R ничему не учит? Поведётесь на DVD, потом через 3 года - на его high-density формат, потом ещё на несколько форматов, а главное - не сможете ничего найти - одним find/grep.

Я из принципа покупать dvd-writer не буду - по религиозным, так-сказать, соображениям.

дисковое пространство в 2 раза дороже _всего_ (уже сейчас), зато имеете возможность поиска и масштабируемой обработки информации. И никогда ничего не копируете с места на места, не ждёте, не тратите своего времени на поиски. Если вдруг надо как имидж - $mount -r -t iso9660 -o loop image_file.iso /mnt/cdrom
интересно, c dvd будет подобная команда работать (убрав тип) - кто-нить пробовал?

забыл к дискетам добавить iomega zip100 (на параллельном порту), был такой, на который я в своё уйму времени угрохал (и на ожидание пока движок раскрутится и синхронизацию/проверку). 100M - казалось просто охеренным пространством. Экстраполируйте на будущее.

>дисковое пространство в 2 раза дороже _всего_ (уже сейчас), зато имеете возможность поиска и масштабируемой обработки информации.

Вот-вот, полностью согласен. И хотя ДВД резак всёже поставлю, раздумываю над поднятием на втором пеньке с памятью 256 и интеловой сетевушкой РЭЙД-массива гигов на 250, в качестве семейной файлопомойки. Выберу время, запасусь горючим и в гости на консультации.

>Сотни раз встречал людей не догадывающихся о существовании ФС.

Как я им завидую... Небось сидят, используют компьютер в чисто утилитарных целях, не делают из него культа, не собирают ведро, не флеймят на ЛОРе что лучше -- апельсины или яблоки. Приходят вовремя домой, обнимают жену, играют с детьми, вкусно кушают первое, второе и компот, смотрят по телевизору Галкина с Петросяном, ложаться спать и засыпают как младенцы. Секс у них по обоюдному согласию и с женой, а не в самое неподходящее время и с заглючившим сервером. И спят они спокойно, потому что у них Bind херакнуться в кору не может. Они вообще не знают, кто такая кора и кто такой Bind. И не хотят знать. Ох, как я завидую таким людям. По-хорошему, конечно же, без злобства.

>Вот-вот, полностью согласен. И хотя ДВД резак всёже поставлю, раздумываю над поднятием на втором пеньке с памятью 256 и интеловой сетевушкой РЭЙД-массива гигов на 250, в качестве семейной файлопомойки. Выберу время, запасусь горючим и в гости на консультации.

даже с ммх166/64M работает аж видео-он-деманд, без торможения. сетевая - 3COM за $30, правда не RAID а простой контроллер для udma133, самые медленные (меньше нагрев, износ) диски но большие.
Себестоимость добра ~$100 (без дисков). RAID меня настораживает - лучше зеркалировать на удалённый компутер имхо.
А пиво попить - это всегда буду рад ;))