а теперь попробуй в качестве архиватора lzma или 7-zip, если первого нету

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

> Какие есть еще хаки чтобы ускорить копирование?

держать tar-архив не на том же диске, с которого его разжимать, а на третьем (можно вообще на SSD)

а у tar есть сжатие шоле?
я в tar собирал как раз 7zip'ом

еще заметил, что по «LAN->жесткий диск» работает гоарздо быстрее, чем «жесткий диск -> жесткий диск». Так что можно хранить tar-архив вообще на другом компьютере, подключенном через гигабитный лан..

так было всегда, вообщето

Такое ощущение, что у тебя DMA не работает. А диски SATA->USB или SATA->SATA?

> так было всегда, вообщето

а почему тогда это не поведение по умолчанию, если так быстрее?

> А диски SATA->USB или SATA->SATA?

IDE (адаптер Marvell) -> SATA

Или дрова и винды настолько корявые.

потому что пользователю важно показать что процесс идёт, а профессионал и через copy скопирует.

А, ну тогда LAN -> SATA точно может быть быстрее, т.к. эти адаптеры очень слоупочные (у меня такой-же).

Пайпы же.

нужно собрать файлы в tar-архив, прямо на целевом жестком диске

Пайпами не? Архивируем, получающийся tar шлём на конвейер, разархивируем на целевой диск. Так не быстрее получается?

>>>IDE (адаптер Marvell) -> SATA

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

Сам пофиксишь? Надеюсь помогать не надо?

У меня стойкое дежа-вю, что такая тема ту была много лет назад.

И да, почитай обзоры - копирование кучи файлов еще зависит от прошивки самого винта.

Где в WoW-клиенте много мелких файлов? Там пара многогиговых MPQ-архивов - и все, остальное - всякие аддоны, скриншоты и логи, кеш можно не копировать.

~/.wine/drive_c/World of Warcraft$ find ./ -type f | wc -l
1101

>> И да, почитай обзоры - копирование кучи файлов еще зависит от прошивки самого винта.

Нирикамендую такие обзоры.

Это оффтопик так тонко намекает что вов не нужен

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

> Где в WoW-клиенте много мелких файлов?

ты прав, их там нет, всё запаковано )

просто после всяких NFS в каждой массивной игрушке мерещатся миллионы файлов

но результата теста не отменяет. Копировать через tar оказалось быстрее.

везде так, много мелких файлов копируется сильно медленнее чем тот же объем в нескольких файлах

почему же ось автоматически не сливает копируемое в один файл?

> почему же ось автоматически не сливает копируемое в один файл?

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

такой вариант может работать быстрее только если задержка на передачу одного файла очень большая, как например передача через FTP

Зависит от ФС, в рейзере куча мелких файлов копируется с той же скоростью что и один большой того же объема

>а на третьем (можно вообще на SSD)

По пропускной способности SSD сильно отсасывает у современных винчестеров, единственный плюс - малое время поиска блока но при копировании больших файлов это не важно

а почему тогда это не поведение по умолчанию, если так быстрее?

а потому-что так быстрее лишь в недосистемах типа оффтопика с её NTFS. Используй EXT4, и не заморачивайся.

RTFM:

The command also works using long option forms:

$ (cd sourcedir; tar --create --file=- . ) \ | (cd targetdir; tar --extract --file=-)

or

$ tar --directory sourcedir --create --file=- . ) \ | tar --directory targetdir --extract --file=-

Да, tar поддерживает сжатие. Самое лучшее на сегодня - LZMA-2, реализованное в программе xz. Ключ -J (J - большая буква)

Если у тебя over9000 памяти, и быстрый CPU, то используй это. Можешь с ключом -9 (сжатие по макс)

потому что при сжатии tar копирование выполняется в одном потоке
пробовали с rsync?

а, ну и если tar, то через pipe ещё быстрее будет

>малое время поиска блока но при копировании больших файлов это не важно

Если у тебя диск C: на весь HDD, и на нём раскидано 100500 мелких файлов по всему диску, то SSD будет однозначно быстрее. А если у тебя Ъ система, и есть спец-раздел для файлов, то они идут почти подряд, и копировать их также быстро как один большой. Особенно если EXT4 с экстентами.

> а потому-что так быстрее лишь в недосистемах типа оффтопика с её NTFS. Используй EXT4, и не заморачивайся.

вранье 100%. е4 на мелкие файлы реагирует так же как нтфс +-0.хрен%

с райзером скорее всего тоже самое

Не скорее.

с райзером скорее всего тоже самое

На чём основано столь смелое предположение?

> На чём основано столь смелое предположение?

бесчисленные тесты файловых систем, однако

>бесчисленные тесты файловых систем, однако

пруфы будут? или ты так, потрещать зашёл?

А где там много мелких файлов? Аддоны что ли?

>> бесчисленные тесты файловых систем, однако

пруфы будут? или ты так, потрещать зашёл?

+1 тупой тест специально для тебя

копирование с райзера на райзер 1.5гб мелких файлов из /usr/share

4m36.931s

копирование с райзера на райзер 1.5гб мп3 файлов

1m51.839s


то же самое на ext4

3m45.162s
1m38.238s

разница >2x в обоих случаях (чтд?) и райзер не быстрее даже на мелких файлах

оперативки 256мб, в кеш файлы не помещаются по-этому при повторах те же цифры

Очередной фороникс-стайл бенчмарк. Опции монтирования, естественно, дефолтные?

> Очередной фороникс-стайл бенчмарк. Опции монтирования, естественно, дефолтные?

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

> По пропускной способности SSD сильно

отсасывает у современных винчестеров

Сам ты ... не пробовал SSD на PCIe

>разница >2x в обоих случаях (чтд?) и райзер не быстрее даже на мелких файлах

ну и что? всё зависит от исходного и конечного положения файлов: Например, для операции чтения одного нефрагментированного файла нам нужно просто подвести головку к файлу, и его читать. Основное время тратится на начальное позиционирование. Если-же файлов 2шт, то нужно позиционировать дважды. При этом время второго позиционирования зависит от расстояния между файлами. Совсем плохо, если файлов много, и мы их копируем в случайном порядке.

Как они у тебя там лежали - мне неведомо. И тебе тоже. Однако, один файл ФС старается засунуть в одно место, а вот кучу мелочи - не старается.

И вообще не надо холиварить на эту тему - результаты измерений слишком сильно (в сотни раз!) зависят от случайных причин. Если уж проводить тесты, то на только-что созданных идентичных разделах. Причём копировать источник нужно командой dd, что-бы файлы легли одинаково. Но команда dd не может скопировать файлы на разные ФС, потому мы не можем гарантировать эквивалентность источника. Видимо надо написать специальный скрипт, который создаёт N файлов размера S, причём эти размеры делает случайными, и данные берёт из /dev/urandom. После этого можно провести тест копирования на пустой раздел.

Это надо повторить 3 раза (минимум), причём каждый раз создавать ФС заново, с нуля.

А затем ещё 3 раза, но уже создавая ФС другого типа.

А так - просто 3.1415926здабольство.

SSD бывают разные. На первых ёёёшках тоже SSD, скорость у них в ~3 раза меньше, чем на моём тихом десктопном винте.

>Сам ты ... не пробовал SSD на PCIe

В продаже не видел, те что в продаже - говно полное. Были бы они на PCIe сам бы прикупил, я уже по этому поводу отписывался что SATA-интерфейс для SSD это охрененно кривой костыль. Хотя если SSD использовать для временных файлов не лучше ли дохрена оперативки и tmpfs? ;)

> не лучше ли дохрена оперативки и tmpfs? ;)

SSD дешевле на единицу объема (читай интернет - там пруфы)

> А затем ещё 3 раза, но уже создавая ФС другого типа.

А так - просто 3.1415926здабольство.

зачем всё это если на глаз отчетливо видно что много мелких файлов копируется медленее чем мало больших. лишь бы попистеть?

В линупсе можно существенно ускорить копирование мелких файлов, смонтировав target файловую систему с опцией async.

ШОК

А разве они по умолчанию монтируются с sync? O_O

Не знаю. Возможно зависит от типа ФС или даже носителя. Была у меня одна крайне тупая флешка, если монтировал без асинка, записать на нее множество файлов было практически нереально. Пробовал там и фат, и екст3.

Ну а с асинком все было круто, как будто между двумя винтами копирую.

>зачем всё это если на глаз отчетливо видно что много мелких файлов копируется медленее чем мало больших. лишь бы попистеть?

перечитай первый пост: ТС предлагает скопировать много мелких файлов с источника в один большой поток в пайпе, а потом это поток раскидать на много мелких файлов на приёмнике. В грамотно сделанной ФС это что в лоб, что полбу, в отличие от дерьма по имени WinNT4-5-6+NTFS.

Т.е. тут 2 операции копирования: файлы -> пайп -> файлы

Мне например это совсем не очевидно, мало того, иногда получается дольше, а иногда быстрее. Зависит от того, что внутри PIPE.

>Ну а с асинком все было круто, как будто между двумя винтами копирую.

man отложенная запись.

Вытащи свою флешку сразу после «копирования», поймёшь.

man безопасное извлечение устройства

Sync после копирования занимал еще пару секунд. Вместо пары секунд на каждый файл без async.

>Sync после копирования занимал еще пару секунд. Вместо пары секунд на каждый файл без async.

ну я не знаю, почему ВАША ось не понимает, что нет смысла делать sync, если ей прямо сейчас туда ещё 100500 файлов писать надо. А может это какой-то шибко «умный» ФМ (я-бы написал об этом баге разработчикам, глядишь - исправят).

Да, у меня в моей системе всё нормально работает: можно удалить большой и сильно фрагментированный файл, и уже ПОСЛЕ завершения rm внешний жёсткий диск ещё некоторое время мигает своей лампочкой. А скорость записи около 30-60Мбайт/с.

Кстати, долгое время ЗАПИСИ для EXT это не баг, а фича - в FAT писать быстро, имена файлов тупо добавляются к директории, для EXT директорию надо сначала прочитать, а потом изменить. А том довольно сложное b-дерево, причём ещё и хешированное. За то время поиска часто на 2 порядка быстрее, что позволяет хранить в одном каталоге сотни тысяч файлов.