TrueCrypt как перенести многотерабайтний том ?

[VicoNT]

На гугле забанили?

Нет. Но реального рецепта по копированию найти пока не удалось. Приведённая Вами информация тоже ничего не даёт.
Возможно, придётся написать самому утилитку.

[Parasite]

На гугле забанили?

Нет. Но реального рецепта по копированию найти пока не удалось. Приведённая Вами информация тоже ничего не даёт.
Возможно, придётся написать самому утилитку.

Утилитку для чего? Для копирования файла XXX на носитель YYY?
Информация выше дана для понимания того, что файл в ТруКрипте делается (и форматируется) изначально ровно на тот обьем, который указан. А "разрежение" есть фича ФС NTFS для логического маппинга однородных данных (обычно - нулей), и имеет место быть только в пределах тома. То есть, читая этот файл - мы его "восстанавливаем" в уме через драйвер файловой системы. Так как копирование файла подразумевает его чтение (с диска) - то при любой примененной утилите система (драйвер FS NTFS) "растянет" файл из sparse в обычный размер, кой и будет копироваться. Что Вы и имеете в данном случае.
Чтобы файл (любой!) стал sparse при записи на новый том - опять же, смотрим гугл. Например, тут. К программе TrueCrypt задача не имеет отношения в любом случае - он всего лишь юзает общеизвестную фичу отдельно взятой ФС.

[VicoNT]

Похоже, мы друг друга не понимаем
Ладно, уже не в суть - сел было ручками написать утилиту, потом вспомнил, что в линуксе это всё прозрачнее, и можно задать агрессивный способ работы с разрежёнными файлами при копировании, скачал cygwin, в итоге, "CP --sparse=always" спасла такого ленивого гиганта мысли, как я

[Parasite]

Похоже, мы друг друга не понимаем

Прекрасно понимаем.

в линуксе это всё прозрачнее, и можно задать агрессивный способ работы с разрежёнными файлами при копировании, скачал cygwin, в итоге, "CP --sparse=always" спасла такого ленивого гиганта мысли, как я

...при этом файл переносился как обычный (по его размеру) - просто на носителе-приемнике автоматом тоже делается sparse (в общем и целом этого ключа не надо было указывать - он автоматом применяется если файл-исходник был sparse). CP в общем и целом - стандартное копирование (читай - ФС на чтение отдаст нормальный размер), а вот при записи на новый том CP автоматически разредит полный файл если в копируемом обнаружатся достаточно длинные последовательности нулей (а появятся они там, разумеется, ТОЛЬКО при "растягивании" исходного sparse при чтении).

скрытый текст: показать

By default, sparse SOURCE files are detected by a crude heuristic and the corresponding DEST file is made sparse as well. That is the behavior selected by --sparse=auto. Specify --sparse=always to create a sparse DEST file whenever the SOURCE file contains a long enough sequence of zero bytes. Use --sparse=never to inhibit creation of sparse files.
http://linux.about.com/od/commands/l/blcmdl1_cp.htm

То есть, Ваша задача решена конечно же (ее можно решить несколькими способами, как я и сказал выше), просто для уточнения того что а)трафик через CP был равен полному размеру файла - и имели место быть две последовательные операции "растягивание->сжатие", б) никакого отношения к собственно ТруКрипту вопрос не имеет.

PS: кстати, cygwin для этой цели в винде имхо весьма избыточен - можно воспользоваться штатным виндявым Backup, ну или вот.

[VicoNT]

Действительно, к ТруКрипту это не относится, тут я его упоминал лишь для того, чтобы дать понять, что целью всего этого является "не заработок на запорожец" (с) , а работа с картами посредством SasPlanet на нескольких компах
Что же касается ключа "--sparse=always", что-то мне память услужливо подсказывает, что без этого ключа как-то имел проблемки с файлом бэкапа под *nix'ом. Впрочем, уже не в суть - не впервой забивать гвозди микроскопом.
Зато как вариант - 67 гигабайт кэша SasPlanet перенеслось за 20 с копейками минут на другой винт, чего и желалось!
P.S. И вот тут уже подумалось, что если бы

а)трафик через CP был равен полному размеру файла - и имели место быть две последовательные операции "растягивание->сжатие"

имело место быть, то копирование заняло бы гораздо больше времени.
P.P.S. Хотя, чёрт его знает, просто 67 гигабайт единым архивом копируется за 14 минут, видимо, лишнее время-таки тратится. Второй разрежённый файл, который 13 гигабайт перенёс без ключа always, заняло 5 с копейками минут. Но всё равно, ИМХО, так гораздо быстрее и удобнее, чем 2 часа мучаться с tar'ом

[Parasite]

Зато как вариант - 67 гигабайт кэша SasPlanet перенеслось за 20 с копейками минут на другой винт, чего и желалось!
И вот тут уже подумалось, что если бы

а)трафик через CP был равен полному размеру файла - и имели место быть две последовательные операции "растягивание->сжатие"

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

unsparse/sparse делается не в винте, а в мозгах компьютера (в драйвере FS). Данные читаются с винта -> [драйвером ФС растягиваются -> CP -> драйвером ФС сжимаются] -> пишутся на другой винт. Так как это сугубо "виртуальная" операция в пределах кв.скобок (оно же "ось"), то опять же на совр.процессорах она практически незаметна - но трафик в пределах этих же скобок как раз ПОЛНЫЙ, тогда как за пределами оных (на шинах HDD) - уже "sparse". Отсюда получаем, что нет никакой разницы кто и каким образом осуществляет sparse, коль скоро это делается в пределах тех скобок (оси). Что я и сказал выше - "Задача имеет много решений, гугл в помощь".
Вы решили линуховым CP, кто-то в гугле решил через ранееназванную прожку, средствами оси оно делается через Backup\Restore, а я бы вообще решил через ReiserFS и не связывался бы с NTFS.

PS: по указанным скоростям - подозреваю, что копирование было на внешний УСБ2-винт (кэп скорости - 60Мб\сек, по вашим данным имеем скорость операции 56Мб\сек - что весьма и весьма близко). Угадал?

[VicoNT]

PS: по указанным скоростям - подозреваю, что копирование было на внешний УСБ2-винт (кэп скорости - 60Мб\сек, по вашим данным имеем скорость операции 56Мб\сек - что весьма и весьма близко). Угадал?

Не совсем 56 Мб/с - это для sparse-файла; обычный файл, созданный просто так, копируется на этот винт быстрее. Это старенький ноутбучный SATA-винт, подключенный через внешний SATA-слот.

[Parasite]

PS: по указанным скоростям - подозреваю, что копирование было на внешний УСБ2-винт (кэп скорости - 60Мб\сек, по вашим данным имеем скорость операции 56Мб\сек - что весьма и весьма близко). Угадал?

Не совсем 56 Мб/с - это для sparse-файла; обычный файл, созданный просто так, копируется на этот винт быстрее. Это старенький ноутбучный SATA-винт, подключенный через внешний SATA-слот.

Угу. Понятно. Вот и выросло поколение, которое ноутбучный САТА-винт называет "стареньким"....

PS: "Внешний SATA-слот" - это не eSATA случаем? Плюс еще общую задумчивость того же цыгвина и его приложений в неканонiчной среде...

[VicoNT]

Угу. Понятно. Вот и выросло поколение, которое ноутбучный САТА-винт называет "стареньким"....

Выросло поколение - славно сказано... Вспоминаю свои первые программы на перфокартах и первую персоналку в 1989 году... А как же, как не стареньким его назвать, если ему 3 года?

PS: "Внешний SATA-слот" - это не eSATA случаем? Плюс еще общую задумчивость того же цыгвина и его приложений в неканонiчной среде...

Да, он самый.

[Parasite]

Вспоминаю свои первые программы на перфокартах

Перфокарты - не тру: мы тут про винты. Старенькие, САТАовские....

А как же, как не стареньким его назвать, если ему 3 года?

(доставая и сдувая пыль со с действительно старенького ISA-MFM Seagate 20Mb): а кому софта на Асме, Форте и Коболе для ДВК-3 под еешний CP/M и какие-то стартовые версии ДОСа?? Жаль, контроллер давно втыкать некуда - а так бы слил себе в бэкапы, что-то подсказывает мне что винт прекрасно запустится и прочтется...