--
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
> Можно ли просмотреть файлы с 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
> Можно ли просмотреть файлы с 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
> -o loop
Это больше не обязательно.
--
sergio.
--
To UNSUBSCRIBE, email to debian-russ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
хм· и давно настало это «больше»?
$ 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
> хм· и давно настало это «больше»?
В сиде не обязательно, не знаю как давно.
> 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
Александр, я честно говоря не понимаю, чем вас так не устраивает
использование утилиты 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
играю роль «разрушителя мифов»·
--
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
--
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
Тогда только надо не забывать упоминать, в каких именно ОС они справляются.
Я понимаю, что рассылка тематическая, но у меня есть, гм, предубеждение, что
линукс-специфичное решение, как правило, хуже общеюниксового там, где их
сложность сравнима, а дистрибутив-специфичное решение там, где есть хотя бы
общее линукс-специфичное, обычно вообще невменяемо.
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
Вопрос же не в том 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
Ну и помимо фрюниксов, которых, собственно, одна 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
Видишь ли, 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
Я в курсе. Именно поэтому мне трудно понять какое отношение к ней имеет 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
Речь шла о кастомной программе с использованием 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
--
WBR, wRAR
Затем, что он одинаково работает и на линуксе, и на солярке. В отличие от
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
[…]
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
несмотря на некоторое предубеждение к программам, название которых
начинается на "k", я погуглил... оказывается это небольшая консольная
программка ;)
PS: и всё-таки вопрос был про образ раздела, а не диска...
хотя я иногда имею дело с образами дисков, так что программка
пригодится, спасибо.
--
To UNSUBSCRIBE, email to debian-russ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org