LINUX.ORG.RU
ФорумAdmin

Буферизованное копирование (dd или что-то другое)

 , ,


0

2

Может кто-нибудь из местных просветит. Была необходимость склонировать партиции ЖД с маленького на большой, воспользовался dd, ресайзил партиции, брат жив.

Изначально это было очень неторопливо (грешил на плохой USB адаптер), потом узнал про bs. Не знаю, как это работает, но как понял.

  1. Считывается определённый n блок в оперативную память с файла
  2. Из оперативной памяти n блок записывается в файл
  3. И так для n=n+1

Такой подход создаёт задержки, типа сначала надо что-то считать, затем записать, затем снова считать. Можно предварительно держать в памяти n+1 блок, чтобы не было ожидания считывания, тогда запись будет идти непрерывно.

Особо не вникал в процесс и не гуглил, может подскажут, есть ли там буферизация, или он в принципе не буферизируется.

Перемещено hobbit из general

Вроде бы, в данном случае block size = buffer size. Если верить man dd, bs по умолчанию равен 512 байтам. На современном жестком диске размер физического сектора равен 4 килобайтам. Подозреваю, что сектор можно записать только целиком и по итогу он у тебя пишется 8 раз. Попробуй bs=4k или кратный.

Vidrele ★★
()
Ответ на: комментарий от Vidrele

Лучше ставить блок в 1048576. Как минимум сэкономишь на сисколлах. Что же касается экономии на физическом доступе к диску, то тут всё сложнее. Если запись не кешируется то однозначно 512 хуже чем 4096 (а для ссд ещё и 8-кратный износ), но и отослать диску сразу 64к это лучше чем слать 16 раз по 4к.

firkax ★★★★★
()
Последнее исправление: firkax (всего исправлений: 1)

Такой подход создаёт задержки, типа сначала надо что-то считать, затем записать, затем снова считать.

В портах фряхи есть buffer, который как раз решает эту проблему. Есть ли он в линуксе и под каким названием — хз. Дом. страницы этой программулины я не нашел.

iron ★★★★★
()
Ответ на: комментарий от Vidrele

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

Честно признаться, не понимаю, почему так. Там же идёт очередь запросов на запись. Неужели IO Scheduler такой тупой, что не видит последовательных запросов на запись в очереди и не догадывается их объединить в один?

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

То, что по факту эта разница есть - меня удивляет.

vbr ★★★
()
Ответ на: комментарий от vbr

А зачем планировщику анализировать и объединять запросы? Софт-то не тупой и не будет писать куски по 512 килобайт, прибавляя по 512 килобайт к смещению, если можно записать всё сразу. И dd не тупой: он просто дает пользователю сделать любую глупость.

На самом деле это мы отупели. Живем в высокоуровневых абстрациях. Какой-нибудь оператор ЭВМ, таскающий перфокарты и магнитные бобины, прекрасно представлял, куда и как движется каждый байт. А мы тут открываем для себя bs и удивляемся.

Vidrele ★★
()
Ответ на: комментарий от Gennadevich

Это же не со стороны dd. Я может не понимаю, как работает dd, но подумал, что замедление из-за необходимости стопориться на чтение и запись. То есть, максимальная скорость будет, когда и чтение и запись идёт непрерывно, а там есть затраты на ожидание считывания.

Хотя может и дело в размере блока, типа при дефолтном 512-байтовом блоке и размере сектора в 4к перезапись одного и того же происходит 8 раз, никаких проблем с ожиданием считывания нет, просто скорость падает в 8 раз.

DanilaZabiakaa
() автор топика
Ответ на: комментарий от vbr

У устройств хранения такое свойство, как iops, это число операций в/в в секунду, которое можно выжать из устройства в данных условиях. Каждая такая операция идёт с некоторым оверхедом на всех уровнях. При прям малом размере блока значимость оверхеда растет до неприличных значений. Ну и да, устройства с большим физическим сектором нужно записывать блоками, не меньшими, чем этот самый сектор, иначе вместо записи мы каждый раз имеем чтение-модификацию-запись внутри устройства.

olegkrutov ★★
()