dd
Ivan Petrov
нужный?
--
With regards,
Ivan Petrov ip2010petrov wow-wow yandex...
--
To UNSUBSCRIBE, email to debian-russ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Archive: http://lists.debian.org/j3j7ga$qv4$1...@dough.gmane.org
Sergey Korobitsin
> Можно ли просмотреть файлы с dd образа линуксового раздела и
> извелечь нужный?
kpartx -av disk.img
mount /dev/mapper/loopXXX /mnt/partition1
Как-то так.
--
Bright regards, Sergey Korobitsin,
Chief Research Officer
Arta Software, http://arta.kz/
xmpp:under...@jabber.arta.kz
--
Шрифты в грызлись в нежные глазные яблоки и со смаком захрустели зрачками.
-- wfrr @ linux.org.ru
--
To UNSUBSCRIBE, email to debian-russ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Archive: http://lists.debian.org/20110830175...@undertaker.dev.lan.arta.kz
Yuri Kozlov
Ivan Petrov <ip2010...@yandex.ru> пишет:
> Можно ли просмотреть файлы с dd образа линуксового раздела и извелечь
> нужный?
mount -o loop ... , видимо.
http://wiki.edseek.com/guide:mount_loopback
--
Best Regards,
Yuri Kozlov
--
To UNSUBSCRIBE, email to debian-russ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Archive: http://lists.debian.org/20110830215...@keeper.home.local
Anton Kovalenko
> Можно ли просмотреть файлы с dd образа линуксового раздела и извелечь
> нужный?
man mount /-o loop
--
Regards, Anton Kovalenko
+7(916)345-34-02 | Elektrostal' MO, Russia
Sergej Kochnev
>Можно ли просмотреть файлы с dd образа линуксового раздела и извелечь
>нужный?
sergio
> -o loop
Это больше не обязательно.
--
sergio.
--
To UNSUBSCRIBE, email to debian-russ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Anton Kovalenko
сделали :).
(Я писал лишь о том, куда смотреть и где читать</отмазка>. Хотя читать
man mount тоже "больше не обязательно", наверное)
P.S. Мне мои «устаревшие» привычки очень пригождаются, когда приходится
поднимать что-нибудь из initrd, к примеру: после пары попыток,
заканчивающихся мыслью «какое же оно тут всё глупое», применение
«~дважды устаревшего» подхода помогает (в случае текущих
klibc-недоутилит для текущего примера будет нужен losetup, если не
ошибаюсь).
alexander barakin
> On 08/30/2011 09:54 PM, Anton Kovalenko wrote:
>
> > -o loop
> Это больше не обязательно.
хм· и давно настало это «больше»?
$ sudo mount test.image /media
mount: test.image is not a block device (maybe try `-o loop'?)
$ lsb_release -rdc
Description: Debian GNU/Linux 6.0.2 (squeeze)
Release: 6.0.2
Codename: squeeze
p.s. а вот использовать dd — действительно, необходимости нет·
/bin/cp прекрасно справляется·
--
wbr, alexander barakin aka sash-kan.
--
To UNSUBSCRIBE, email to debian-russ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Archive: http://lists.debian.org/20110830193...@teta.mezon.local
sergio
> хм· и давно настало это «больше»?
В сиде не обязательно, не знаю как давно.
> p.s. а вот использовать dd — действительно, необходимости нет·
> /bin/cp прекрасно справляется·
Всё время cat использовал.
--
sergio.
--
To UNSUBSCRIBE, email to debian-russ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Murat D. Kadirov
> On Tue, Aug 30, 2011 at 09:57:02PM +0400, sergio wrote:
> > On 08/30/2011 09:54 PM, Anton Kovalenko wrote:
> >
> > > -o loop
> > Это больше не обязательно.
>
> хм· и давно настало это «больше»?
> $ sudo mount test.image /media
> mount: test.image is not a block device (maybe try `-o loop'?)
> $ lsb_release -rdc
> Description: Debian GNU/Linux 6.0.2 (squeeze)
> Release: 6.0.2
> Codename: squeeze
>
> p.s. а вот использовать dd — действительно, необходимости нет·
> /bin/cp прекрасно справляется·
Александр, я честно говоря не понимаю, чем вас так не устраивает
использование утилиты dd. Всякое упоминание dd в рассылке обязательно
вызывает у вас подобный комментарий о неуместности использования dd,
когда есть cp.
--
Murat D. Kadirov
PGP fingerprint: 3081 EBFA 5CB9 BD24 4DB6 76EE 1B97 0A0E CEC0 6AA0
--
To UNSUBSCRIBE, email to debian-russ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Archive: http://lists.debian.org/20110830212951.GA31699@darkstar
Sergej Kochnev
"Murat D. Kadirov" <band...@gmail.com> wrote:
>On Tue, Aug 30, 2011 at 11:32:30PM +0400, alexander barakin wrote:
>> On Tue, Aug 30, 2011 at 09:57:02PM +0400, sergio wrote:
>> > On 08/30/2011 09:54 PM, Anton Kovalenko wrote:
>> >
>> > > -o loop
>> > Это больше не обязательно.
>>
>> хм· и давно настало это «больше»?
>> $ sudo mount test.image /media
>> mount: test.image is not a block device (maybe try `-o loop'?)
>> $ lsb_release -rdc
>> Description: Debian GNU/Linux 6.0.2 (squeeze)
>> Release: 6.0.2
>> Codename: squeeze
>>
>> p.s. а вот использовать dd — действительно, необходимости нет·
>> /bin/cp прекрасно справляется·
>
>Александр, я честно говоря не понимаю, чем вас так не устраивает
>использование утилиты dd. Всякое упоминание dd в рассылке обязательно
>вызывает у вас подобный комментарий о неуместности использования dd,
>когда есть cp.
>
>
>
быстродействия, чем не страдают cat/pv.
alexander barakin
> On Tue, Aug 30, 2011 at 11:32:30PM +0400, alexander barakin wrote:
> > On Tue, Aug 30, 2011 at 09:57:02PM +0400, sergio wrote:
> > > On 08/30/2011 09:54 PM, Anton Kovalenko wrote:
> > >
> > > > -o loop
> > > Это больше не обязательно.
> >
> > хм· и давно настало это «больше»?
> > $ sudo mount test.image /media
> > mount: test.image is not a block device (maybe try `-o loop'?)
> > $ lsb_release -rdc
> > Description: Debian GNU/Linux 6.0.2 (squeeze)
> > Release: 6.0.2
> > Codename: squeeze
> >
> > p.s. а вот использовать dd — действительно, необходимости нет·
> > /bin/cp прекрасно справляется·
>
> Александр, я честно говоря не понимаю, чем вас так не устраивает
> использование утилиты dd. Всякое упоминание dd в рассылке обязательно
> вызывает у вас подобный комментарий о неуместности использования dd,
> когда есть cp.
играю роль «разрушителя мифов»·
--
wbr, alexander barakin aka sash-kan.
--
To UNSUBSCRIBE, email to debian-russ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Archive: http://lists.debian.org/20110831073...@teta.mezon.local
Stanislav Maslovski
... в которых размер буфера наверняка забит руками раз и навсегда,
что тоже не есть хорошо.
--
Stanislav
--
To UNSUBSCRIBE, email to debian-russ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Archive: http://lists.debian.org/2011083119...@kaiba.homelan
Anton Kovalenko
>> dd практически всегда нуждается в указании bs для оптимального
>> быстродействия, чем не страдают cat/pv.
>
> ... в которых размер буфера наверняка забит руками раз и навсегда,
> что тоже не есть хорошо.
умолчательного bs=512.
По-моему, никому не помешает периодическое напоминание о том, что cp и
cat тоже справляются (особенно если оно не утверждает великую кошерность
cp и халяльность cat на фоне скоромности dd).
Кстати, я вспомнил ещё один подход: писал когда-то простенькую хреновину
на си, содержательная часть которой состояла в вызове sendfile(2) (оно
тогда умело между файлами копировать; сейчас это splice(2), если не
ошибаюсь). Использовал её для разделов и для больших файлов (типа
образов CD), где копирование тормозило; разница по времени с cp
иногда была раза в полтора (ну, точно не помню, но десятки процентов).
Artem Chuprina
> >> быстродействия, чем не страдают cat/pv.
> >
> > ... в которых размер буфера наверняка забит руками раз и навсегда,
> > что тоже не есть хорошо.
>
> ... но там запросто может быть забито руками что-то поумнее
> умолчательного bs=512.
>
> По-моему, никому не помешает периодическое напоминание о том, что cp и
> cat тоже справляются (особенно если оно не утверждает великую кошерность
> cp и халяльность cat на фоне скоромности dd).
Тогда только надо не забывать упоминать, в каких именно ОС они справляются.
Я понимаю, что рассылка тематическая, но у меня есть, гм, предубеждение, что
линукс-специфичное решение, как правило, хуже общеюниксового там, где их
сложность сравнима, а дистрибутив-специфичное решение там, где есть хотя бы
общее линукс-специфичное, обычно вообще невменяемо.
cp -a - очень приятная фри-юникс-специфичная штука, но она крайне редко
оказывается лучше, чем rsync -a. И в половине случаев при этом на самом деле
нужно еще более гну-читай-линукс-специфичное cp -al. Это к вопросу о
нижепроцитированном sendfile(2), которая в этом последнем случае немедленно
начинает проигрывать cp в разы по скорости и квадратично по месту на диске.
> Кстати, я вспомнил ещё один подход: писал когда-то простенькую хреновину
> на си, содержательная часть которой состояла в вызове sendfile(2) (оно
> тогда умело между файлами копировать; сейчас это splice(2), если не
> ошибаюсь).
Вот, кстати, да. Яркий пример. Выигрыш в производительности в полтора раза
ценой того, что в какой-то момент хреновина ВНЕЗАПНО перестает работать
вообще. Потому что нигде больше не применяемый и оттого не стандартизованный
sendfile(2) вдруг взял и разучился копировать между файлами.
> Использовал её для разделов и для больших файлов (типа
> образов CD), где копирование тормозило; разница по времени с cp
> иногда была раза в полтора (ну, точно не помню, но десятки процентов).
--
Весь юникс для того и был придуман, чтобы PS в принтер выплевывать.
Alex Korchmar в <a63nn3$ef7$1...@alx.private>
--
To UNSUBSCRIBE, email to debian-russ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Archive: http://lists.debian.org/87k49sq089.wl%r...@ran.pp.ru
Anton Kovalenko
> Я понимаю, что рассылка тематическая, но у меня есть, гм,
> предубеждение, что линукс-специфичное решение, как правило, хуже
> общеюниксового там, где их сложность сравнима, а
> дистрибутив-специфичное решение там, где есть хотя бы общее
> линукс-специфичное, обычно вообще невменяемо.
некая линуксовая бранзулетка так уж хороша, почему её не стырили хотя бы
окружающие фрюниксы? Впрочем, этот аргумент работает только на длинных
интервалах времени, или на фичах с простой реализацией (когда самое
трудное было додуматься до идеи). Да и то есть исключение, имхо: futexes
не расхватали просто потому, что тупыыыые.
[...]
>> Кстати, я вспомнил ещё один подход: писал когда-то простенькую
>> хреновину на си, содержательная часть которой состояла в вызове
>> sendfile(2) (оно тогда умело между файлами копировать; сейчас это
>> splice(2), если не ошибаюсь).
>
> Вот, кстати, да. Яркий пример. Выигрыш в производительности в
> полтора раза ценой того, что в какой-то момент хреновина ВНЕЗАПНО
> перестает работать вообще. Потому что нигде больше не применяемый и
> оттого не стандартизованный sendfile(2) вдруг взял и разучился
> копировать между файлами.
том, что так будет, сильно раньше чем ядром 2.6 стало можно
пользоваться (к тому же, когда с переходом 2.4->2.6 что-то перестаёт
работать, это /по построению/ ни хрена не ВНЕЗАПНО).
Насчёт «больше нигде не применяемый»: ну да, накрылась именно та /часть/
функциональности, которая была линукс-специфична. А для сокетов sendfile
есть чуть ли не вообще везде; способ с ним обращаться отличается, но
смысл тот же (и на винде есть, только TransmitFile называется).
Если вспомнить, как модно было пузомерствовать в области раздачи статики
через http -- оно и неудивительно.
Иван Лох
> cp -a - очень приятная фри-юникс-специфичная штука, но она крайне редко
> оказывается лучше, чем rsync -a. И в половине случаев при этом на самом деле
> нужно еще более гну-читай-линукс-специфичное cp -al. Это к вопросу о
> нижепроцитированном sendfile(2), которая в этом последнем случае немедленно
> начинает проигрывать cp в разы по скорости и квадратично по месту на диске.
Вопрос же не в том cp или rsync, а в том open/write или специальным ядерным вызовом.
Понятно, что чем изощреннее становятся оба планировщика, чем сложнее дисковые драйверы
и сами диски, тем больше будет разрыв в производительности между двумя подходами.
Ну и потом linux не добился бы никакого успеха без "Stable API Nonsense", и широкого
прорастания этого Non Stable API в userspace. Его козырем всегда был и будет +1% к
производительности. А он и есть IMHO за счет Non Stable API.
> вообще. Потому что нигде больше не применяемый и оттого не стандартизованный
> sendfile(2) вдруг взял и разучился копировать между файлами.
Fall back to read/write все делают.
--
To UNSUBSCRIBE, email to debian-russ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Archive: http://lists.debian.org/20110901111...@nano.ioffe.rssi.ru
Artem Chuprina
> > предубеждение, что линукс-специфичное решение, как правило, хуже
> > общеюниксового там, где их сложность сравнима, а
> > дистрибутив-специфичное решение там, где есть хотя бы общее
> > линукс-специфичное, обычно вообще невменяемо.
>
> У меня тоже есть такое предубеждение, но я его ещё и обосновываю :) Если
> некая линуксовая бранзулетка так уж хороша, почему её не стырили хотя бы
> окружающие фрюниксы? Впрочем, этот аргумент работает только на длинных
> интервалах времени, или на фичах с простой реализацией (когда самое
> трудное было додуматься до идеи). Да и то есть исключение, имхо: futexes
> не расхватали просто потому, что тупыыыые.
Ну и помимо фрюниксов, которых, собственно, одна FreeBSD, есть еще и другие
юниксы. В части из которых этого не сделали, потому что они не фрюниксы, а в
части - по другим соображениям, например, безопасности (меньше кода - легче
аудит).
> >> Кстати, я вспомнил ещё один подход: писал когда-то простенькую
> >> хреновину на си, содержательная часть которой состояла в вызове
> >> sendfile(2) (оно тогда умело между файлами копировать; сейчас это
> >> splice(2), если не ошибаюсь).
> >
> > Вот, кстати, да. Яркий пример. Выигрыш в производительности в
> > полтора раза ценой того, что в какой-то момент хреновина ВНЕЗАПНО
> > перестает работать вообще. Потому что нигде больше не применяемый и
> > оттого не стандартизованный sendfile(2) вдруг взял и разучился
> > копировать между файлами.
>
> Ну какое там внезапно -- даже специально не отслеживая, я прочитал о
> том, что так будет, сильно раньше чем ядром 2.6 стало можно
> пользоваться (к тому же, когда с переходом 2.4->2.6 что-то перестаёт
> работать, это /по построению/ ни хрена не ВНЕЗАПНО).
Это для программиста, который следит за ядром (и знает, что у него в программе
есть сисколлы, по-разному работающие в разных юниксах), оно не внезапно. А
для сисадмина, который сапгрейдил дистрибутив на сервере и у него отвалилась
софтина, написанная тем программистом - внезапно. А мы тут обсуждаем скорее
сисадминскую, чем программистскую деятельность - пользование системой, а не
написание под нее программ.
> Насчёт «больше нигде не применяемый»: ну да, накрылась именно та /часть/
> функциональности, которая была линукс-специфична. А для сокетов sendfile
> есть чуть ли не вообще везде; способ с ним обращаться отличается, но
> смысл тот же (и на винде есть, только TransmitFile называется).
> Если вспомнить, как модно было пузомерствовать в области раздачи статики
> через http -- оно и неудивительно.
Поправка насчет больше нигде не применяемой /части функциональности/
sendfile(2) принята :-)
--
Юзер обожает терпеть мелкие неудобства
Victor Wagner
--
To UNSUBSCRIBE, email to debian-russ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Archive: http://lists.debian.org/87ippcpedf.wl%r...@ran.pp.ru
Artem Chuprina
> > оказывается лучше, чем rsync -a. И в половине случаев при этом на самом
> > деле нужно еще более гну-читай-линукс-специфичное cp -al. Это к вопросу о
> > нижепроцитированном sendfile(2), которая в этом последнем случае
> > немедленно начинает проигрывать cp в разы по скорости и квадратично по
> > месту на диске.
>
> Вопрос же не в том cp или rsync, а в том open/write или специальным ядерным
> вызовом. Понятно, что чем изощреннее становятся оба планировщика, чем
> сложнее дисковые драйверы и сами диски, тем больше будет разрыв в
> производительности между двумя подходами.
Видишь ли, cp -al - это не open/write и не sendfile(2). Это link(2).
> Ну и потом linux не добился бы никакого успеха без "Stable API Nonsense", и
> широкого прорастания этого Non Stable API в userspace. Его козырем всегда
> был и будет +1% к производительности. А он и есть IMHO за счет Non Stable
> API.
Я же не говорю, что линукс-специфичное решение _всегда_ хуже. Там, где тебе
действительно нужен +1% - не вопрос, оптимизируй.
Когда у тебя прорва файлов и ты точно знаешь, что тебе их надо скопировать из
одной директории в другую не глядя, надо сделать это один раз и на линуксе, cp
-a в норме будет быстрее, чем rsync -a, не вопрос. Потому что не будет читать
даже целевое дерево, не говоря уже о файлах (интересно, у rsync есть
противоестественный интеллект на тему "если копирование локальное, не считать
контрольные суммы и дельты, а гнать файл не глядя"? и если он есть, то хорошо
ли это для копирования на флешки?)
> > вообще. Потому что нигде больше не применяемый и оттого не
> > стандартизованный sendfile(2) вдруг взял и разучился копировать между
> > файлами.
>
> Fall back to read/write все делают.
Если нет жестких требований к производительности, то дешевле сразу написать
read/write, чем писать sendfile и fallback на тот же самый read/write. А если
есть, то какой нафиг fallback?
Нет, я понимаю, есть узкий класс задач, где это имеет смысл.
--
Unix-like -- для кинестетиков, Emacs -- для аудиалов, Mac -- для визуалов,
Windows -- для чайников
-- RockMover in <RM279891167...@golovolomka.net>
--
To UNSUBSCRIBE, email to debian-russ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Archive: http://lists.debian.org/87hb4wpdwk.wl%r...@ran.pp.ru
Иван Лох
> > > немедленно начинает проигрывать cp в разы по скорости и квадратично по
> > > месту на диске.
> >
Я в курсе. Именно поэтому мне трудно понять какое отношение к ней имеет sendfile.
> > Ну и потом linux не добился бы никакого успеха без "Stable API Nonsense", и
> >
> > Fall back to read/write все делают.
>
> Если нет жестких требований к производительности, то дешевле сразу написать
> read/write, чем писать sendfile и fallback на тот же самый read/write. А если
> есть, то какой нафиг fallback?
>
> Нет, я понимаю, есть узкий класс задач, где это имеет смысл.
IMHO жесткие требования на высокую производительность при копировании файлов,
есть почти всегда. read/write имеет смысл сразу делать только для небольших файлов.
--
To UNSUBSCRIBE, email to debian-russ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Archive: http://lists.debian.org/20110901140...@nano.ioffe.rssi.ru
Anton Kovalenko
> (интересно, у rsync есть противоестественный интеллект на тему "если
> копирование локальное, не считать контрольные суммы и дельты, а гнать
> файл не глядя"?
него даже идея сделать всё в рамках одного процесса не возникает. На том
месте, где обычно происходит запуск удаленной копии rsync, он форкается
-- вот и весь интеллект (да и тот при указании --rsync-path пропадает).
> и если он есть, то хорошо ли это для копирования на флешки?)
нехорошо. Единственная детерминированная софтина осталась -- пожалели бы
редкую зверушку.
Artem Chuprina
> > > > месту на диске.
> > >
> > Видишь ли, cp -al - это не open/write и не sendfile(2). Это link(2).
>
> Я в курсе. Именно поэтому мне трудно понять какое отношение к ней имеет
> sendfile.
Речь шла о кастомной программе с использованием sendfile, которая выигрывала
десятки процентов у cp. Я говорю о том, что да, у cp -a она выиграет десятки
процентов. А cp -al, если оная вдруг применима, проиграет в разы. К вопросу
об использовании более или менее стандартных решений.
> > > Ну и потом linux не добился бы никакого успеха без "Stable API
> > > Nonsense", и
> > >
> > > Fall back to read/write все делают.
> >
> > Если нет жестких требований к производительности, то дешевле сразу
> > написать read/write, чем писать sendfile и fallback на тот же самый
> > read/write. А если есть, то какой нафиг fallback?
> >
> > Нет, я понимаю, есть узкий класс задач, где это имеет смысл.
>
> IMHO жесткие требования на высокую производительность при копировании файлов,
> есть почти всегда. read/write имеет смысл сразу делать только для небольших файлов.
Повторюсь: а если требования жесткие, то какой нафиг fallback? Жесткие - это
значит, что read/write не тянут. Если они не тянут, то делать на них fallback
нельзя.
--
The effort of using machines to mimic the human mind has always struck
me as rather silly. I would rather use them to mimic something better
-- Edsger Dijkstra
--
To UNSUBSCRIBE, email to debian-russ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Archive: http://lists.debian.org/87ei00pa3m.wl%r...@ran.pp.ru
Andrey Rahmatullin
> копирование локальное, не считать контрольные суммы и дельты, а гнать
> файл не глядя"? и если он есть, то хорошо ли это для копирования на
> флешки?)
Я ещё понимаю, если посчитать чексумму N байт дешевле, чем эти N байт
переписать ими же самими, тут rsync со стандартным алгоритмом полезен даже
локально.
--
WBR, wRAR
Anton Kovalenko
> (интересно, у rsync есть противоестественный интеллект на тему "если
> копирование локальное, не считать контрольные суммы и дельты, а гнать
> файл не глядя"? и если он есть, то хорошо ли это для копирования на
> флешки?)
которая снаружи видна как нечто хардообразное (usd-storage, ide, cf...),
наверняка много размышляет о том, как бы блоки раскидать, и контрольные
суммы тоже считает; на этом фоне было бы очень странно, если перезапись
блока его же содержимым приводила бы к реальному стиранию.
"Голая" флешка (без usb-storage и прочего интеллекта) имеет ещё одно
полезное свойство: хотя стирается она только блоками, никто не
заставляет на неё блоками записывать (для программиста это выглядит
примерно так: по команде стирания в блоке все биты "объединичиваются", а
вот "обнулять" их обратно можно в каком угодно порядке -- не то что
блоков никаких нет, даже и байты значения не имеют). Если "обвязка",
предоставляющая usb-storage, будет по-умному это свойство использовать,
можно ожидать, что и запись блока данных поверх блока нулей не приведёт
к лишнему циклу стирания по сравнению с записью данных /сразу/.
(Впрочем, если недодумать, журналированная ФС может подключить /свой/
интеллект, и тогда есть вероятность, что стирание всё-таки произойдёт, и
не одно).
Artem Chuprina
> > копирование локальное, не считать контрольные суммы и дельты, а гнать
> > файл не глядя"? и если он есть, то хорошо ли это для копирования на
> > флешки?)
> А зачем тогда rsync?
Затем, что он одинаково работает и на линуксе, и на солярке. В отличие от
cp. И одинаково успешно работает локально и удаленно. Опять же в отличие от
cp.
--
Все гениальное просто.
Но со вкусом.
Кнышев.
--
To UNSUBSCRIBE, email to debian-russ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Archive: http://lists.debian.org/87bov4owu6.wl%r...@ran.pp.ru
Ivan Shmakov
[…]
AC> Когда у тебя прорва файлов и ты точно знаешь, что тебе их надо
AC> скопировать из одной директории в другую не глядя, надо сделать это
AC> один раз и на линуксе, cp -a в норме будет быстрее, чем rsync -a,
AC> не вопрос. Потому что не будет читать даже целевое дерево, не
AC> говоря уже о файлах (интересно, у rsync есть противоестественный
AC> интеллект на тему "если копирование локальное, не считать
AC> контрольные суммы и дельты, а гнать файл не глядя"?
Похоже, что есть.
--cut: rsync(1) --
-W, --whole-file
With this option rsync’s delta-transfer algorithm is not used
and the whole file is sent as-is instead. The transfer may be
faster if this option is used when the bandwidth between the
source and destination machines is higher than the bandwidth to
disk (especially when the "disk" is actually a networked
filesystem). This is the default when both the source and des‐
tination are specified as local paths, but only if no batch-
writing option is in effect.
--cut: rsync(1) --
AC> и если он есть, то хорошо ли это для копирования на флешки?)
Перед копированием, rsync(1), в отличие от cp(1), может сравнить
m-time и длину файлов, и не копировать в случае совпадения. Для
cp(1), IIRC, есть только --update.
[…]
--
FSF associate member #7257 Coming soon: Software Freedom Day
http://mail.sf-day.org/lists/listinfo/ planning-ru (ru), sfd-discuss (en)
--
To UNSUBSCRIBE, email to debian-russ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Archive: http://lists.debian.org/868vq7bm...@gray.siamics.net
Ed
> Ivan Petrov ☫ → To debian-...@lists.debian.org @ Wed, Aug 31,
2011 00:43 +0700
>
>> Можно ли просмотреть файлы с dd образа линуксового раздела и
>> извелечь нужный?
>
> kpartx -av disk.img
> mount /dev/mapper/loopXXX /mnt/partition1
>
> Как-то так.
несмотря на некоторое предубеждение к программам, название которых
начинается на "k", я погуглил... оказывается это небольшая консольная
программка ;)
PS: и всё-таки вопрос был про образ раздела, а не диска...
хотя я иногда имею дело с образами дисков, так что программка
пригодится, спасибо.
--
To UNSUBSCRIBE, email to debian-russ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org