Если люди знают готовое проверенное универсальное решение

знают — coreutils. свистоперделки не являются «решением»

Тебе уже несколько решений предложили, а ты продолжаешь упорствовать

Тебе показалось. Я рассматриваю все варианты чтобы потом выбрать наиболее подходящий для моих задач. Упоротыствуют здесь только замшелые юникспуристы.

надо именно в cp впихнуть этот прогрессбар

4.2

sdio, shdown, спасибо, посмотрю.

чего fail? Я именно apt-get и имел в виду.

А я в нулевом посте имел в виду расширение функционала и повышение удобства, о котором спрашивают как минимум с 2005 года, а не ненужных коров и поней.

знают — coreutils. свистоперделки не являются «решением»

Расскажи это разработчикам wget.

wget не входит в coreutils. да и до curl в этом ему далеко, кмк

wget не входит в coreutils

Обратного я и не утверждал.

да и до curl в этом ему далеко, кмк

Тем не менее со своей задачей он справляется.

А ты позавчера поставил, типа? Для понтования перед сокурсникам?

Непонятно как это прописать алиасом чтобы делать cp -r.

А-н нет, похоже только сегодня.

Я охренел, когда узнал, что в линуксовом пинге нельзя так сделать

В линуксовом пинге это не нужно. Зато если почитать man ping можно понять, что виндовый - кастрат какой-то.

Виндовый прямо пишет — пакет не пришел, и это сразу видно.

Линуксовый показывает порядок, и это, тоже, видно сразу. Если не слепой.

http://www.wagner.pp.ru/~vitus/articles/user-friendly.html

или просто: используй pv

А ты позавчера поставил, типа?

Нет.

Для понтования перед сокурсникам?

Не угадал. Перед сотрудниками разве что.

А-н нет, похоже только сегодня.

Красноглазие ненужно.

Тот «юниксвей» что тебе предлагают работает, и работает хорошо. И когда работу надо работать, а не понтоваться перед сотрудниками, он подходит внезапно лучше всего.
Но ты продолжай жить в мире, где за тебя все делают другие. И ожидай готовых решений. Работа наверное сама себя поработает, пока безрукие ждут.

tl;dr

Ведь дружба — это отношение между равными

Я пони кибернетический организм, это считается?

и работает хорошо

Смотри похожие треды. Если бы он работал так хорошо как ты расписываешь — их бы не было.

он подходит внезапно лучше всего

4.2

Но ты продолжай жить в мире, где за тебя все делают другие. И ожидай готовых решений

Ты свой процессор уже разработал? Материнку спаял? Ядро написал? Как это нет?

Работа наверное сама себя поработает

Сабж — не моя работа, мне за это не платят.

пока безрукие ждут

Это ты о пользователях coreutils? „И пускай весь мир подождёт”.

По треду заметно как у тебя успешно дела идут. Как поняша выше, не может пять минут на ман потратить и чуток подумать, но может долгое время жаловаться, пребывать в неведение и ныть. Синтетический организм, ога. Ленивое, глупое быдло.

они тебя никогда не поймут, любители «юниксвея» на локалхосте.

я тебе сейчас расскажу про свой опыт срочной работы с десятками терабайт в линухе.

чаще всего тебе поможет du, pv и tar (без сжатия) - этим ты сможешь накостылить cp -r с прогрессом. для сжатия используй p7zip с форматом 7z и методом bzip2. остальные форматы и утилиты компрессии под линукс неюзабельны в общем случае (нет многопоточности компрессии/декомпрессии, кривая поддержка архивов больше 4гб,отсутствие юникода для хранения имён). знай, что 7z считает чексуммы сам, по дефолту, значит не нужно терять время с md5sum,если нет особого желания и нужды.

для передачи с хоста на хост лучше юзать iscsi + xfs . что попроще: ssh с шифрованием arcfour + тотже tar и товарищи pv и Ко.

для вычитывания битого диска - ddrescure без вариантов.

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

средства слишком низкоуровневые, к сожалению, многие не выполняют свою задачу (в компрессорах я разочаровался). mc лучше не использовать, он на больших данных и архивах слишком задумчив и прервать его io сложно

Ленивое, глупое быдло

Пока красноглазые мартышки на своём локалхосте выполняют очередную обезьянью работу за разработчиков, я воспользуюсь тем же rsync, потратив минуту на изучение мана к нему, пропишу алиасы и пойду пить чай, сконцентрировавшись на других, более насущных задачах. Продолжай мастурбировать на свою идеальную сферическую юниксвейность 70-х годов дальше.

пойду пить чай

Пойду ныть на лоре, ты хотел сказать. А про работу сказки другим рассказывай. По просранному на тред времени видно какой ты эффективный работничек.

dd

в другом терминале

killall -USR1 dd

Спасибо за информацию для размышления. В данном случае у меня задача не срочная, я просто выбираю инструмент для более удобного манипулирования архивами/образами/бэкапами и т.п. файлами, думаю и для других задач такое может оказаться полезным, особенно на больших файлах. А вот насчёт форматов сжатия для архивов интересно, подумаю.

По просранному на тред времени

Нужно же хоть как-то отвлекать обезьянок от костыляния очередного велосипеда.

какой ты эффективный работничек

$ date +%H:%M
23:23

Лол.

ls -laR

# time ls -laR > /dev/null                                                                              

real    2m11.408s
user    0m25.958s
sys     1m29.064s
# du -sh .                                                                                              
391G    .

Лишние две минуты. Если тебе часто приходится столько данных копировать, ты будешь знать, сколько времени они будут литься. А вот время на подсчёт размера тратить никому не надо.

Если тебе часто приходится столько данных копировать, ты будешь знать, сколько времени они будут литься

В том и дело что размер файлов и время могут быть различными.

Лишние две минуты

По сравнению с несколькими часами на копирование — некритично вообще.

Вообще говоря, не нравится тем, что копирование ведётся через юзерспейс (read()+write()), когда можно через sendfile(). Или я не прав, и там везде sendfile?

есть бенчмарки?

ping -O

$ ping -O
ping: invalid option -- 'O'
Usage: ping [-LRUbdfnqrvVaAD] [-c count] [-i interval] [-w deadline]
            [-p pattern] [-s packetsize] [-t ttl] [-I interface]
            [-M pmtudisc-hint] [-m mark] [-S sndbuf]
            [-T tstamp-options] [-Q tos] [hop1 ...] destination

$ ping -V
ping utility, iputils-sss20100418

Видимо опция относительно свежая.

Опция 2012 года. Видимо тебе надо опять подождать.

Видимо тебе надо опять подождать.

Мне и так нормально.

Бенчмарки ничего не покажут, потому что затраты времени на копирование данных в памяти пренебрежимо малы по сравнению с затратами времени на I/O.

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

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

а совместимость тебе нравится? Хотя о чём я, ты ж системдешник :-D

совместимость чего с чем?

Действительно, совместимость чего с чем? Реализации cp с ядрами, не имеющими системного вызова sendfile()? Она меня совершенно не волнует, и не должна волновать ни одного вменяемого разработчика.

совместимость с старыми ядрами, ессно ж.

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

Узнаю ваши симптомы. Изменения ради изменений.

конвеер pv подойти должен тебе

Ты не прав.

sendfile() оптимальнее, чем read()+write(). Одного этого достаточно, чтобы использовать первое вместо второго. И на совместимость с убогими ядрами здесь абсолютно наплевать, потому что основная и единственная задача ядра ОС — предоставлять подобную функциональность юзерспейсным приложениям. А если ядро чего-то не умеет, то это исключительно проблема ядра.

А ещё — хватит цитировать кусками. В приличном обществе... ну ты понял.

даже libc работает с ядрами не старше такой-то версии. и каков юзкейс? системные компоненты обновляются целиком

Не начинай по кругу:

sendfile() оптимальнее, чем read()+write().

есть бенчмарки?

Бенчмарки ничего не покажут,

окау.

Одного этого достаточно, чтобы использовать первое вместо второго.

недостаточно. нет обоснованных причин: бенчмарков нет. Есть недостатки: теряется совместимость. обеспечиваем совместимость - необоснованно усложняется код.

Я уже сказал: несмотря на то, что на большинстве современных систем бенчмарки ничего не покажут, ноль копирований оптимальнее двух. Это должно быть очевидно.

Дело не в бенчмарках, а в нагреве процессора, в потреблении энергии, в поведении системы при запуске 9000 копирований одновременно...

и каков юзкейс? системные компоненты обновляются целиком

один бинарь, много ядер.

Дело не в бенчмарках,

а в одержимости идеей.

а в нагреве процессора, в потреблении энергии, в поведении системы при запуске 9000 копирований одновременно...

давай бенчмарки! :-D

те обоснованных юзкейсов нет. понятно

ты предлагаешь держать на каждое ядро отдельно по разделу с совместимым юзерспэйсом? зачем его ломать?

как я уже писал, libc тоже привязана к минимальной версии ядра. в любом случае тебе собирать целиком специализованный юзерспейс

как я уже писал, libc тоже привязана к минимальной версии ядра.

даже последний релиз поддерживает ядра вот уже 5 летней давности. Предлагаешь ломать почаще?

в любом случае тебе собирать целиком специализованный юзерспейс

пусть я буду это делать чаще и по причине гонки за каждой новой функцией в ядре? я ж не арчер, понимаш? Ломать нужно обоснованно, а не... :)

минимально поддерживаемый релиз задаётся при сборке.

бэхоцэ - вступай и конпелируй! :)

просто зафиксируем комментарий