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

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

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

Скорость копирования (комментарий)

/etc/sysctl.conf
vm.dirty_bytes = 2097152
vm.dirty_background_bytes = 2097152

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

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

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

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

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

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

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

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

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

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

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