1.1, Аноним (-), 10:01, 04/07/2015 [ответить] [﹢﹢﹢] [ · · · ]
| +30 +/– |
>В утилиту dd добавлен отладочный уровень "status=progress", при котором раз в секунду выводится статистика о ходе передачи данных;
Оперативненько, не прошло и полвека.
| |
|
2.3, cmp (ok), 10:44, 04/07/2015 [^] [^^] [^^^] [ответить]
| –2 +/– |
ну
while killall -USR1 dd; do sleep 1; done
никто не отменял, кстате интересно на сколько долей процента проверка необходимости обновлять статус и его обновление снижает производительность, в konsole c композитом лишние букафки выдаваемые на экран тормозят проги в разы.
| |
|
3.6, Crazy Alex (ok), 12:55, 04/07/2015 [^] [^^] [^^^] [ответить]
| +9 +/– |
Если аккуратно сделано - то ни на сколько. Отдельный поток, к примеру. Да и в любом случае - раз в секунду - не значимо совершенно. Не говоря о том, что это всё же опция. В общем, давно пора было.
| |
|
4.32, cmp (ok), 05:31, 05/07/2015 [^] [^^] [^^^] [ответить]
| +/– |
Отдельный поток мб, но переносимость на встраиваемые системы пострадает, а колбэк на сигнал тривиально даже там.
| |
|
5.51, Crazy Alex (ok), 18:37, 06/07/2015 [^] [^^] [^^^] [ответить]
| +/– |
Так сигнал никто и не отбирает. Что до встраиваемых платформ - если там даже потоков нет, то надо busybox или подобное использовать, а не coreutils. впрочем, раз в секунду как строку не выводи - производительность не потеряешь.
| |
|
|
3.62, Аноним (-), 01:36, 07/07/2015 [^] [^^] [^^^] [ответить]
| +/– |
> while killall -USR1 dd; do sleep 1; done никто не отменял,
...только вот печатать все это как-то дольше получается чем 1 ключ командлайна. Вообще, для меня загадка какой инопланетянин придумал это делать так. Это самый ректальный способ вывода прогресса который я встречал.
| |
|
2.4, Аноним (-), 10:51, 04/07/2015 [^] [^^] [^^^] [ответить]
| –5 +/– |
>>В утилиту dd добавлен отладочный уровень "status=progress", при котором раз в секунду выводится статистика о ходе передачи данных;
> Оперативненько, не прошло и полвека.
Нафиг не нужно, есть же pv:
dd if=/dev/sda | pv --size $(blockdev --getsize64 /dev/sda) | dd of=/dev/sdb
| |
|
3.5, Мяут (ok), 12:13, 04/07/2015 [^] [^^] [^^^] [ответить]
| +4 +/– |
Передавать данные через два пайпа ради этого? В идеале dd if=/dev/sda of=/dev/sdb должен sendfile(2) делать.
| |
|
4.7, Аноним (-), 13:15, 04/07/2015 [^] [^^] [^^^] [ответить]
| –3 +/– |
pv /dev/sda | dd of=/dev/sdb работает .. сразу прогресс бар и время и вся лабуда отображается
| |
|
|
6.16, Gannet (ok), 17:37, 04/07/2015 [^] [^^] [^^^] [ответить]
| +/– |
и как вы его поставите, если доступа в инет нет, а он по умолчанию, в отличии от dd, не установлен, по крайней мере в дистрах и Live-CD, с которыми я сталкивался.
| |
|
7.31, Michael Shigorin (ok), 23:34, 04/07/2015 [^] [^^] [^^^] [ответить]
| –3 +/– |
>> в ddrescue уже давно всё есть)
> Тогда я за dc3dd, если что.
Если что, это всё есть в altlinux.org/rescue :)
| |
|
6.26, Аноним (-), 19:47, 04/07/2015 [^] [^^] [^^^] [ответить]
| +1 +/– |
> в ddrescue уже давно всё есть)
Только он по дефолту гадит файлом битмапов и вообще немного не для этого.
| |
|
5.18, Аноним (-), 18:20, 04/07/2015 [^] [^^] [^^^] [ответить]
| +1 +/– |
> pv /dev/sda | dd of=/dev/sdb работает .. сразу прогресс бар и время
> и вся лабуда отображается
И куда тут впихнуть conv=noerror,sync при случае?
| |
|
4.9, Аноним (-), 13:40, 04/07/2015 [^] [^^] [^^^] [ответить]
| –1 +/– |
Где ты у ssize_t sendfile(int out_fd, int in_fd, off_t *offset, size_t count);
видишь прогрессбар? Ты либо sendfile используй, либо процентики смотри.
| |
|
3.48, Poettering (?), 12:36, 06/07/2015 [^] [^^] [^^^] [ответить]
| +3 +/– |
Да ну, это примитивно, это ретроградство, это прошлый век! Надо выводить на вебморду, с танцующими понями и котиками! Переписать, встроить веб-сервер, базу данных, отправку статистики в Твиттер, Фейсбук и Гуглплюс. И конечно же, включить в системд! Как раз будет повод версию апнуть еще на одну циферку.
| |
|
2.14, Michael Shigorin (ok), 16:51, 04/07/2015 [^] [^^] [^^^] [ответить]
| +1 +/– |
>>В утилиту dd добавлен отладочный уровень "status=progress"
> Оперативненько, не прошло и полвека.
Так давно уже pv(1).
PS: ага, хорошо, что про полезную утилитку много кто знает :)
| |
|
3.24, Аноним (-), 19:43, 04/07/2015 [^] [^^] [^^^] [ответить]
| +1 +/– |
> PS: ага, хорошо, что про полезную утилитку много кто знает :)
А Михаил всегда с удовольствием расскажет нам как правильно закручивать гвозди отверткой.
| |
|
4.30, Michael Shigorin (ok), 23:32, 04/07/2015 [^] [^^] [^^^] [ответить]
| +1 +/– |
>> PS: ага, хорошо, что про полезную утилитку много кто знает :)
> А Михаил всегда с удовольствием расскажет нам как правильно
> закручивать гвозди отверткой.
Если Вам требуется именно закрутить гвоздь отвёрткой, для этого стоит выбрать подходящий по запасам экземпляр, на шляпке сделать продольный надрез пилой по металлу и нарезать резьбу с подходящим шагом -- собственно, для этого и предназначена отдельная утилита.
А dd(1) ETA не показывает и кофе не варит, сущая правда.
PS: вообще-то не понял бухтежа, вполне хорошая утилитка, регулярнейшим образом пригождается при записи исошек на флэшки.
| |
|
5.56, Аноним (-), 01:12, 07/07/2015 [^] [^^] [^^^] [ответить] | –1 +/– | Вот-вот, я именно об этом А можно вообще переплавить этот гвоздь углерода досы... большой текст свёрнут, показать | |
|
6.72, Michael Shigorin (ok), 21:57, 07/07/2015 [^] [^^] [^^^] [ответить]
| +/– |
>> Если Вам требуется именно [...]
> А нормальный человек - таки пойдет и просто возьмет шуруп.
Так и я об этом. :)
> Это я к тому что идея пайпить ...цать гигабайтов через левые тулзы
> мне что-то не прикольна в плане оверхеда по ресурсам. Оверхед от
> пары мелких плюшек типа отрисовки прогресса - зело меньше.
Вы, как порой бывает, ведёте тяжёлые позиционные бои с калиткой в чистом поле -- и мелкие плюшки хороши, и тулза, которая показывает, что осталось примерно пять минут, тоже хороша (особенно когда < > и без | работают).
>> PS: вообще-то не понял бухтежа, вполне хорошая утилитка,
> А бухтеж - по поводу того что предлагается гонять 100500 гигазов через
> всякие там пайпы и чуть не полдюжины программ.
Ну некоторые вон cat | grep предлагают -- что ж теперь, обвинять grep в этом | ?
> Остап знал over 9000 способов записать флешки. Можно даже миднайтом скопировать
> файлов в /dev/чтотамеще. Даже работает. С прогрессом в человеческом виде и прочая.
> И все это прекрасно.
Не, это как раз жутко неудобно: огромное кол-во лишнего кода под рутом (либо менять права на /dev/sdX), полноэкранная софтина вместо строчки в шелльной истории... Т.е. можно, но не для постоянного использования. Применительно к выбранной аналогии -- тот самый гвоздобойный мелкоскоп. :)
> И это называется улучшение юзабилити программы.
Вот на этом и предлагаю согласиться да закрыть вопрос :)
| |
|
|
|
|
|
1.15, t (??), 17:29, 04/07/2015 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
>В mv добавлена проверка возможности выполнения вызова reflink для эффективного >перемещения файлов между разделами Btrfs вместо обычного копирования;
офигенно! очень нужно, а то прихолось делать cp --reflink-always и потом удалять на источнике.
ну и прогресс бар у dd тоже нужная вещь.
еще б дождаться когда пакет будет, и чтоб его можно было в текущий lts ubuntu server воткнуть..
| |
1.19, chinarulezzz (ok), 18:56, 04/07/2015 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
>В утилиту dd добавлен отладочный уровень "status=progress", при котором раз в секунду выводится статистика о ходе передачи данных;
не unixway'но. есть же pv/cv.
| |
|
2.25, Аноним (-), 19:45, 04/07/2015 [^] [^^] [^^^] [ответить]
| –4 +/– |
> не unixway'но. есть же pv/cv.
Если юниксвэй означает залезание в ластах и противогазе на фонарный столб, вместо того чтобы сделать наконце программу не через зад - может, вы таки и свалите в эти ваши юниксы? Там вам будет самое место. А GNU == Gnu is Not Unix, поэтому они как-нибудь могут позволить и не копировать все бестолковости 1 в 1.
| |
|
3.27, Аноним (-), 20:38, 04/07/2015 [^] [^^] [^^^] [ответить]
| –1 +/– |
>GNU == Gnu is Not Unix, поэтому они как-нибудь могут позволить и не копировать все бестолковости
Бери выше! Они могут сами творить бестолковости - системдя тому пример! :)
| |
|
|
5.44, Аноним (-), 22:27, 05/07/2015 [^] [^^] [^^^] [ответить]
| –1 +/– |
>Ты что считаешь что systemd создавали GNU?... x_X
Я в сортиах ... в их сортах не разбираюсь :)
Могу спросить по другому - этот програмистский шЫдэвр есть ещё хоть где то кроме GNU\Linux? Ну дык и чО ты тут засуетилси?
| |
|
4.57, Аноним (-), 01:19, 07/07/2015 [^] [^^] [^^^] [ответить]
| +2 +/– |
> Бери выше! Они могут сами творить бестолковости - системдя тому пример! :)
А системд, между прочим, когда я облажался в юните - написал мне в свой journalctl'овский лог и вывод програмы и что програма завершилась с ошибкой и статус юнита вывесил в зафэйленый. Сразу понятно где лажа. А в sysv init чтобы такое случилось - надо сначала самому напиать половину логгинга и анализа кодов возврата. Вот такая вот небольшая разница...
| |
|
5.73, Michael Shigorin (ok), 21:58, 07/07/2015 [^] [^^] [^^^] [ответить]
| +/– |
> А в sysv init чтобы такое случилось -
...достаточно сделать /etc/init.d/сервис start (что вообще-то при тестировании делается) и если непонятно сразу же, так запустить при помощи sh -x...
| |
|
|
3.28, chinarulezzz (ok), 20:59, 04/07/2015 [^] [^^] [^^^] [ответить]
| +/– |
Тебе не доставало прогрессбара и ты делал все через задницу? Или твой пассаж о том что необходимо в каждой утилите дублировать функционал, вместо того, чтоб вынести в отдельную утилиту, умеющую взаимодействовать со всеми?
| |
|
4.52, Crazy Alex (ok), 18:42, 06/07/2015 [^] [^^] [^^^] [ответить]
| +/– |
Когда функционал тривиален - не грех и сдублировать для часто используемого случая. Это если бы туда начали совать, например, формартные строки, ключи для того, чтобы задать интфервал или ещё что-то подобное - я бы первый возмутился. А на один ключик, один таймер и один printf - глупо возмущаться. Возни мало, удобства много.
| |
|
5.53, chinarulezzz (ok), 19:53, 06/07/2015 [^] [^^] [^^^] [ответить]
| +/– |
>А на один ключик, один таймер и один printf
мелочи нагромождаются. По мне, так синдром плюшкина. Кому раньше это нужно было/не хватало - использовали pv/cv. А кому не надо было, или изредка мелькала мысль, или первый раз в консоли и изучают (--help'ы) -- появилось утешение.
| |
|
6.54, Crazy Alex (ok), 22:52, 06/07/2015 [^] [^^] [^^^] [ответить]
| +1 +/– |
Ну вот когда/если таких мелочей накопится столько, что от них будут какие-то реальные проблемы - кто-нибудь почистит - или в виде форка, или в самих coreutils - не важно. И оставит фичи, нужные на тот момент. Но подозреваю, что в coreutils таких проблем не будет никогда.
Что до меня - я полагаю, что принцип "простое должно быть простым, а сложное - выполнимым" здесь реализован совершенно осмысленно. И что он важнее, чем идеальная ортогональность.
| |
|
7.55, chinarulezzz (ok), 00:02, 07/07/2015 [^] [^^] [^^^] [ответить]
| +/– |
> Ну вот когда/если таких мелочей накопится столько, что от них будут какие-то
> реальные проблемы
ну да, на одни и те же грабли год за годом. Потом обнаруживают вроде такого http://www.opennet.me/opennews/art.shtml?num=40779 и воют о нормальной методологии разработки, верификации, и т.д.
> Но подозреваю, что в coreutils таких проблем не будет никогда.
такие проблемы уже есть, и не только в coreutils.
> Что до меня - я полагаю, что принцип "простое должно быть простым,
> а сложное - выполнимым" здесь реализован совершенно осмысленно.
ууууу... проехали. Гиблое дело, нам друг друга не понять.
| |
|
|
|
4.58, Аноним (-), 01:26, 07/07/2015 [^] [^^] [^^^] [ответить] | +/– | Да, ты знаешь, мне бы не помешал прогресс в dd вызываемый ключом командлайна а н... большой текст свёрнут, показать | |
|
3.42, Аноним (-), 13:00, 05/07/2015 [^] [^^] [^^^] [ответить]
| +/– |
> Если юниксвэй означает залезание
Т.е. очередной диванный эксперт, не знающий основ, но мнение имеющий?
http://www.faqs.org/docs/artu/ch01s06.html
> This is the Unix philosophy: Write programs that do one thing and do it well. Write programs to work together. Write programs to handle text streams, because that is a universal interface.
Учитывая тогдашние реалии, можно заменить "text stream" на что-то более абстрактное (прям как в оригинальном высказывании):
> (ii) Expect the output of every program to become the input to another, as yet unknown, program. Don't clutter output with extraneous information. Avoid stringently columnar or binary input formats. Don't insist on interactive input. | |
|
4.59, Аноним (-), 01:29, 07/07/2015 [^] [^^] [^^^] [ответить]
| –1 +/– |
> program. Don't clutter output with extraneous information.
И все бы ничего. Только у меня dd обычно оперирует многогигабайтными образами дисков и лишний раз это куда-то пайпить я труба шатал. Потому что пайпить 100500 гигз только ради того чтобы прогресс видеть - это крeтинизм в терминальной стадии. С точки зрения системной инженерии, иррелевантно к блеяниям сцаных скриптокидозникв про вэйность и что там еще. Пусть они таким извращением занимаются без меня. А меня не прет идея пайпить 100500 гигз данных лишний раз без серьезной на то нужды.
Да, мне нравятся оптимальные и эффективные решения. Даже если это и не всегда расово верно. Вот такой вот я нехороший.
| |
|
5.64, Аноним (-), 03:47, 07/07/2015 [^] [^^] [^^^] [ответить] | +/– | Жмем CTRL T SIGINFO всякая инфа о том, сколько, куда и откуда и все тако... большой текст свёрнут, показать | |
|
|
|
2.37, vn971 (ok), 07:55, 05/07/2015 [^] [^^] [^^^] [ответить]
| +1 +/– |
Объясните, а как тут поможет pv ? В 'dd' ведь нету пайпов, оно исполняется одной командой.
Как вы используете pv для целей слежения за 'dd' ?
P.S. или вы не применяете "of" (output file) а вместо этого добавляете лишний пайп?
dd if=... | pv > myOutput
скорость от этого по факту не понизится? А то ведь у dd есть разные опции вида "bs" (block size), я не понимаю как они выживут при pipe-овании. С виду не выживут, хотя бы от того что в дефолтном линуксе не очень большой размер пайп-буфера.
| |
|
3.39, Andrey Mitrofanov (?), 08:44, 05/07/2015 [^] [^^] [^^^] [ответить]
| +/– |
> скорость от этого по факту не понизится? А то ведь у dd
> есть разные опции вида "bs" (block size), я не понимаю как
> они выживут при pipe-овании.
bs от dd "при пайпах" выживут: в пайп он будет писать и из него читать указанными блоками.
И у pv тоже есть -B = --buffer-size. При копировании сотен мегабайт или даже если и когда нужен прогресс или ETA, пайп, как таковой совешенно неразличим на фоне дискового io[wait]. Да, конечно, _надо_ ставить буфера/блоки по 10-100Мб (и dd, и pv, если они в пайте), а не 1К.
"Замедлению при пайпах"? Вы просто не умеете их готовить?
ЗЫЖ Пока не спросили, "sed быстрее awk-а" тоже никак не относится к преподносимой нам здесь выдуманной проблеме "замедления при пайпах".
| |
|
4.40, vn971 (ok), 09:10, 05/07/2015 [^] [^^] [^^^] [ответить]
| +/– |
Я вроде не писал букв "замедление при пайпах", не надо ставить кавычки.
В остальном -- если вы проверяли, то ОК, готов поверить. Если это не так то всё равно кто-нибудь (надеюсь) возразит.
P.S. И пайп всё-таки имеет собственный размер буфера, и блокировки записи/чтения он тоже делает:
> If a process attempts to write to a full pipe (see below), then write(2) blocks until sufficient data has been read from the pipe to allow the write to complete. | |
|
|
|
1.45, Аноним (-), 04:01, 06/07/2015 [ответить] [﹢﹢﹢] [ · · · ]
| –3 +/– |
В вин7 с флешки фат32 на нтфс 17,3мбс в дебиане 15,9мбс на ext4 копирует
По факту
| |
|
2.63, Аноним (-), 01:41, 07/07/2015 [^] [^^] [^^^] [ответить]
| +/– |
> В вин7 с флешки фат32 на нтфс 17,3мбс в дебиане 15,9мбс на
> ext4 копирует По факту
Крутой замер. Ни методики, ни результатов.
| |
|
1.46, John (??), 09:52, 06/07/2015 [ответить] [﹢﹢﹢] [ · · · ]
| +1 +/– |
Нападки на konsole - ЛПП. В этом очень легко убедиться измерив скорость вывода в konsole, XTerm, etc., например, командой:
time seq -f 'teeeeeeeeeeeeeeeeeeeeeeeeeeeeeest %g' 100000
так вот, проверьте и уд{и|а}витесь
| |
|
2.49, Andrey Mitrofanov (?), 14:26, 06/07/2015 [^] [^^] [^^^] [ответить]
| +1 +/– |
> А нет ли в них какого-нибудь фатального недостатка?
Они слишком "завязаны" на шелл. Петя, переписать в 5 строчек!!
| |
2.60, Аноним (-), 01:31, 07/07/2015 [^] [^^] [^^^] [ответить]
| +2 +/– |
> А нет ли в них какого-нибудь фатального недостатка?
А что, ddd - это звучит :)
| |
|
|