быстрое cp

создать равный по размеру раздел, и туда dd-шнуть первый раздел с многими файлами

В source-каталоге в tarball закатай все файлы, перенеси tarball в target-каталог и там разверни. Может, и быстрее получится. :)

чегойта вдруг?

А вдруг? :)

Промежуточное копирование большими шмотями в tmpfs. Cpio pass mode.

Неудобно но быстро.

А вообще, не знаю, я как-то cp всё время обходился. У меня столько файлов для копирования нету, чтобы cp серьёзно тормозила. :)

man 2 sendfile

Блин, тупо удаляешь рабочую копию svn-репозитория, и она удаляется по 10 минут. Если нужно грохнуть папочку ~/svn или посчитать ее размер - можно пойти выпить чаю.

может, есть специальные ФС для работы с мелкими файлами?

может, есть специальные ФС для работы с мелкими файлами?

Когда-то где-то (не помню) читал и смотрел статистику и экспериментальные данные по различным линуксовым фс при разных условиях (много мелких файлов, много файлов разных размеров, огромные файлы и т.д.) Но источник и результаты этого исследования вспомнить не могу. :( Гуглить надо.

может, есть специальные ФС для работы с мелкими файлами?

Есть нормальные VCS.

да и так git-svn почти везде, но это жутко ненадежная штука, особенно на винде. Постоянно вылетает с ошибками в перле. И поправить ничего нельзя, ибо весь git-svn - это один огромный страшный перловый скрипт, в котором конь не валялся.

reiserfs?

Если не нужна защита от правок, а просто создать копию - сделай хардлинки. man cp. Я сегодня так 90 Гб минуты за 3 «скопировал»

tar

Симлинк не устроит? Я просто подумал раз уж все на одном диске...

Вы что все упоролись?

Даже в ШИНДОШС ЭТО ЕСТЬ!

Называется ХАРДЛИНК.

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

Еще не факт, что подходит. Может нужны две независимые копии.

fsutil hardlink create

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

может, есть специальные ФС для работы с мелкими файлами?

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

Хотя вообще можно по идее купить оперативку, а потом правильно настроить кэш.

Наверняка есть штатные средства, чтобы определенный раздел или директорию почти постоянно держать в памяти.
Т.к тогда это было бы ещё и надежнее чем tmpfs, но мне это не очень нужно.

может, есть специальные ФС для работы с мелкими файлами?

Проблемы с очень долгим удалением множества файлов я встречал в ext3/4, на рэйзерФС удаляется мгновенно. Специально даже тест проводил, создавал около полумиллиона файлов в одном каталоге и удалял их. А скорость добавления файлов, кстати, у ext4 и raiserFS оказалась одинаковой, правда я создавал последовательно файлы с именами 1, 2, 3,.. не знаю, сказалось ли это как на производительности.

Попробуй btrfs, там copy-on-write, то есть тела файлов копироваться не будут до тех пор, пока ты эти файлы не начнешь править. Теоретически.

rsync -avzP

Хардлинк между разными /dev/sd* - феерично.

ТС вроде говорил про соседние каталоги

Виноват, «на одном хдд».

Gordon01

Даже в ШИНДОШС ЭТО ЕСТЬ! Называется ХАРДЛИНК.

хардлинк не очень повысит скорость копирования множества мелких файлов. И это не копирование. И каталоги не получается. И только на одной ФС.

может, есть специальные ФС для работы с мелкими файлами?

reiserfs неплохо справляется

М. б. tune2fs -O dir_index ... ?

а оно где-то отключено? врядли у ТС ядро 2.0 и соотв. версия e2fsprogs

специальные ФС для работы с мелкими файлами?

reiser. кэп.

это будет работать только если на том же разделе.

иначе придётся делать симлинки,

У ТСа речь шла про один диск.

гм. ну вот у меня / и /var на некоторых машинках - разнеы разделы, что не мешает им лежать на1 единсвтенном диске.:-)

Ок, ок, пусть ТС уточняет, что он имел в виду )