быстро передать образ по сети

А источник цитаты можно?

Я ошибся, это только для v4 2.5 ssd предупреждение. Я не знал точной модели (т.к. сервер к тому моменту завис и я не могу посмотреть) и поэтому посмотрел не ту модель. Моя ошибка.

делаю примерно так, только с nc вместо ssh и gzip. Если надо именно быстро

V4 - бюджетная какашка, она вообще чуть ли не SATA-2, в сервере она ну никак не могла оказаться :)

в сервере она ну никак не могла оказаться

Сервер собирался по принципу «слепил из того что было». m4 это мой венник из старого ноута который сдох. Я бы на hdd поставил, но внезапно выяснилось что в нашем отделе их просто нет (вернее, все мёртвые). Возможно, название «сервер» не слишком удачное, это тестовая тачка на которой я тестирую код под разными ОС.

И ты бы себе купил когда-нибудь V4? :) Не верю!

Да, по поводу образов... почему не клонзилла-то?

И ты бы себе купил когда-нибудь V4?

я даже не знаю что это такое, ssd выбирался... да всем лором он выбирался, я тему создавал :). m4 одобрили, бенчмарки удовлетворили, потребление было тогда одним из самых низких, поэтому и взял.

почему не клонзилла-то?

я не знаю что это такое :(.

скажи, зачем тебе lrzip, если ssh(scp) сама жать умеет? Правда - только в gzip, но этого достаточно. твои схемы компрессии НЕ распараллеливаются в принципе, ибо упираются в память, а память у тебя одна(там нужно МНОГО памяти, кешей недостаточно).

Попробуй нативное сжатие с -9, возможно будет не хуже.

А я так. Сжатие на гигабите не нужно :3

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

ssh(scp) сама жать умеет? Правда - только в gzip, но этого достаточно.

Это медленно, других претензий нет. Правда, я не учёл что ssd сам еле-еле выдаёт 100 метров в секунду, но для gzip это даже близко не достижимо.

твои схемы компрессии НЕ распараллеливаются в принципе, ибо упираются в память

Вполне себе распаралеливаются, и pbzip2, и pxz и прочее умеет жать в несколько потоков. На страницах проектов можно посмотреть как это реализовано и чем приходится при этом жертвовать. Про память я не понял.

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

Где-то на 15-30% сжатия я ошибаюсь ;)

Если ты ошибаешься, то не сильно.

Я так полагаю это основывается на том что на таких скоростях никакого проца не хватит? Ну так есть специально заточенные алгоритмы.

Да и 12309 никто не отменял, у меня даже курсор с экрана исчезает в таки моменты. Арчеядро, блин.

ССЗБ, УМВР.

Где-то на 15-30% сжатия я ошибаюсь ;)

Угу, 64 гига ужалось в 19, совсем немного ошибся. Более конкретные цифры можно посмотреть в бенчмаках lzo-алгоритма.

ССЗБ

это тупой флуд. Есть проблема, она воспроизводится 100% на нескольких моих машинах. То что у тебя всё работает никак проблеме не поможет.

Угу, 64 гига ужалось в 19, совсем немного ошибся. Более конкретные цифры можно посмотреть в бенчмаках lzo-алгоритма.

Конечно. А ты попробуй полностью из нулей файлик на 100 гигов пожать, тогда вапще с цифр выпадешь! :)

Что-то как я ни гонял файло через ssh, скорость всегда падала катастрофически.

на первом пне в последний раз гонял? тогда возможно. Там встроенное сжатие тормозит(если включено, а оно вроде выключено).

шифрование даже на первом пне не тормозит.

500 метров нулей сожмутся в 100 байт или типа того. ЧТО ты мерял-то?

2brBatty, tazhate, просвещайтесь:

http://ck.kolivas.org/apps/lrzip/README.benchmarks

шифрование даже на первом пне не тормозит.

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

И? Везде не выше 26%.

да всем лором он выбирался

Ну тут говна не посоветуют, если только на флэшмоб троллей не нарвешься :)

я не знаю что это такое :(.

http://www.clonezilla.org
я ее для миграции с железа на виртуалки часто юзаю в похожем варианте. Умеет и ssh/sftp/scp и много всякого другого.

И? Везде не выше 26%.

Не 26%, а в три-пять раз, читай внимательно.

500 метров нулей сожмутся в 100 байт или типа того.

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

я ее для миграции с железа на виртуалки часто юзаю в похожем варианте.

Зачем? :) Все это можно делать тупо по ссх. Глушишь сервисы и вперед rsync'ом на партицию, смонтированную в live-cd.

Прошивку не обновил, но переключил ssd в другой порт, пока полёт нормальный.

Потому что есть виртуалки с бсд и оффтопиком :)
Я люблю универсальные решения.

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

Я до обновления не дойду, винды под руками нет, качать и ставить мне реально влом, а загрузиться с isolinux не получается, grub уходит в ребут на «linux /boot/memdisk iso && initrd=crucial_update». Даже на экран ничего не вываливается, memdisk тупо не работает ни при загрузки iso, ни при floppy. Я грешу на мамку, у этого биоса gigabyte есть генетические проблемы с загрузкой.

А у крушиалов вроде как и нет виндового обновлятора.

Сжатие на гигабите не нужно

скорость чтения с ssd 480 метров в секунду в среднем, так что - нужно!

Это медленно, других претензий нет. Правда, я не учёл что ssd сам еле-еле выдаёт 100 метров в секунду, но для gzip это даже близко не достижимо.

вот я и думаю - зачем там сжатие? И каких метров? гигабит это 128мегабайт в сек. для SSD+gzip это быстро.

Вполне себе распаралеливаются, и pbzip2, и pxz и прочее умеет жать в несколько потоков. На страницах проектов можно посмотреть как это реализовано и чем приходится при этом жертвовать. Про память я не понял.

там два этапа: 1) контекстное моделирование, 2) энтропийное кодирование. Второй этап время мало занимает, нет смысла его ускорять. С первым - сложнее. Там математики нет. Тупой поиск и всё. Чем больше контекстов, тем больше сжатие. Т.е. код - тупо ищем в памяти байтики. Конечно - его можно распараллелить, но - нужно по одной памяти к каждому ядру (говорю-же, нет там математики). В принципе можно использовать BWT (bzip2), и сортировать в персональных кешах, в теории. На практике там сжатие получается не сильно лучше, чем gzip. А если взять больше контекстов - в кеш уже не лезет.

В отличие от lzma и bwt, древний LZ77/78 использует мелкие контексты, жмёт хуже, быстрее, и если у каждого ядра есть большой кеш - можно распараллелить.

А у крушиалов вроде как и нет виндового обновлятора.

Ааа, винду я хотел для обновления биоса. Впрочем, проще забить на всё это. Целый рабочий день убил, а в итоге не обновил ни, ни ssd. Пока оно работает в новом sata-порту, оставлю как есть.

Потому что есть виртуалки с бсд и оффтопиком :)
Я люблю универсальные решения.

Бзд так же переносится, а оффтопик - гораздо удобнее vhd.exe, оно сразу образ винды делает, потом тупо через qemu-img convert перегоняешь в raw или qcow2.

Я бы уже из принципа добил, а то окажется, что день зря прошел. :)

вот я и думаю - зачем там сжатие? И каких метров? гигабит это 128мегабайт в сек. для SSD+gzip это быстро.

Я ошибся, я написал выше что ssd считал за чуть более чем две минуты 64гига. Это 481 метр в секунду по показаниям dd: 4023257088 bytes (64 GB) copied, 133.047 s, 481 MB/s

На практике там сжатие получается не сильно лучше, чем gzip.

я же говорю, мне не нужна высокая степень сжатия. Мне нужно чтобы было всё быстро сделано. Потому что из-за этой тачки работа стоит. Скорость и высокая степень сжатия вещи несовместимые.

Я тебе уже говорил, что qcow2 считаю неприемлемым с точки зрения производительности, надежности и удобства ресайза :)
Потому у меня везде lvm.

Я так полагаю это основывается на том что на таких скоростях никакого проца не хватит?

у тебя другой случай, если тебе надо сжатое принять. Но вообще, на гигабите скорость примерно сравнима со скоростью винта. Хоть так читай, хоть эдак. Если сжимать и разжимать, то нужна запись, а она намного медленнее на SSD. Короче - не знаю, что может получится IRL, пиши…

это тупой флуд. Есть проблема, она воспроизводится 100% на нескольких моих машинах. То что у тебя всё работает никак проблеме не поможет.

ядро-то ванильное? Нет? ССЗБ. На ванильном не наблюдается.

Но вообще, на гигабите скорость примерно сравнима со скоростью винта.

ssd почти в четыре раза быстрее гигабита.

В данном случае упирается всё в гигабит (в идеале) и в запись на том винте. Поэтому сжатие имеет смысл для обоих вариантов.

Смог ли я добиться большого прироста скорости? Нет, об этом я и создал тред. Зато запихнул 64гига в 19гиг. Поиски быстрого архиватора продолжаются...

Я хоть смог убедить тебя что есть смысл в сжатии?

ядро-то ванильное?

Да. И я вижу ещё что в момент тормозов скорость на ssd падает до 0.5 метра в секунду на запись (сам в шоке). Диск sandisk i100 распаяный на мамке. Да, это полное Г, но это не значит что приложения должны вешаться минут на пять при обновлении системы. Я создам тред на эту тему. Пока мучает вот эта проблема:

$ dd if=/dev/zero of=/tmp/testfile oflag=direct
dd: failed to open ‘/tmp/testfile’: Invalid argument

просвещайтесь

остынь. Поиграй ключами xz, и получишь более лучший результат. Там дефолт в максиуме(в xz), а сжатие теоретически минимальное. Т.е. дальше яйца не пускают. А уж как быстро ты задвинул - то другой вопрос ☺ Можно и побыстрее. Короче - результат неправильный. Впрочем - это всегда так.

А что касается bzip2, дык почти тоже самое по сжатию, за то - ощутимо быстрее. Сжатие gzip тоже не намного хуже, но рвёт в клочья по скорости.

Я бы уже из принципа добил

Обновил биос из линуха через flashrom. Ляпота! Всю жизнь об этом мечтал.

Вот за что я люблю асус, так это за EZ Flash. Никаких плясок с бубном с загрузочными флэшками, все искаропки.

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

просто узнай свой IQ ☺ Результатов: примерно 198 000 000

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

на SSD - возможно. Хотя зависит от логики TRIM контроллера. Я ещё немного погоняю свой SSD, и проверю, что там IRL. А вот на HDD нулей нет, только если руки у админа кривые(или его только-что почистили, и бекап развернули).

EZ Flash

ё-маё, моя мамка, оказывается, это тоже умеет :(

просто узнай свой IQ

ты для чего это написал?

я же говорю, мне не нужна высокая степень сжатия. Мне нужно чтобы было всё быстро сделано.

дык в том и фишка - протащить сквозь узкий канал МНОГО данных. Их надо сначала сжать, ибо полетят они на 128МБс(гигабит). Вопрос в том, успеешь-ли ты их так БЫСТРО И ХОРОШО жать? Проблема ещё и в том, что очень хорошо жать получается только нули, многие данные в принципе НЕ жмутся, ибо сжатые(любая мультимедиа). Сырцы ядра тоже никто не гоняет разжатыми, даже маны лежат в сжатом виде. И да, нули самая обычная cp на самой обычной EXT4 ужимает, пруф в man cp.

Ну а я гоняю обычно tar'ом. Сжатием или без. Без обычно медленнее.