Почему «/ dev / rdisk» примерно в 20 раз быстрее, чем «/ dev / disk» в Mac OS X


129

Согласно документации rasbery pi , вы можете загрузить свою ОС на флэш-карту с помощью / dev / disk или / dev / rdisk.

rdisk обозначает сырой диск.

/ dev / disk - это устройство блочного уровня, почему бы rdisk быть в 20 раз быстрее?

Использование Mac OSX

Примечание: В OS X каждый диск может иметь две ссылки на пути в / dev: / dev / disk # является буферизованным устройством, что означает, что любые отправляемые данные подвергаются дополнительной обработке. / dev / rdisk # - это необработанный путь, который намного быстрее и прекрасно работает при использовании программы dd. На SD-карте класса 4 разница была примерно в 20 раз быстрее при использовании пути rdisk.


3
Как примечание, я провел тест, и rdisk на самом деле занял гораздо больше времени.
— spuder

4
В качестве еще одного примечания, я чувствовал, что мне тоже пришлось тогда тестировать, и обнаружил, что копирование rdisk (через dd) было почти в 4 раза быстрее, чем использование аналога диска.
— Трэвис Григгс

Mac OSX 10.9.1 (MacBook Pro 15-дюймовый, начало 2011 г.)
— Трэвис Григгс,

2
Я думал, что «rdisk» был опечаткой в ​​некоторых инструкциях для изображения SD-карты Raspberry Pi, которое я читал. После дальнейшего расследования я погуглил разницу и нашел эту ветку. В моем случае оказалось, что в 13 раз быстрее было записать 1,7 ГБ изображение на SD-карту, используя / dev / rdisk вместо / dev / disk! Macbook Pro Retina 13 ", модель начала 2015 года.
— tobias.mcnulty

2
Как еще одно упоминание, я только что добавил образ Ubuntu ARM на мою недавно купленную карту Sandisk Extreme Pro MicroSD. Скорость записи / dev / disk1 - 2,3 МБ / с, а / dev / rdisk1 - 83,7 МБ / с, что в 36,4 раза выше.
— DanielSmedegaardBuus

Ответы:


93

От man hdiutil:

Узлы / dev / rdisk являются символьно-специальными устройствами, но являются «необработанными» в смысле BSD и принудительно выровнены по блоку ввода-вывода. Они ближе к физическому диску, чем кеш буфера. Узлы / dev / disk, с другой стороны, являются буферизованными блочно-специальными устройствами и используются главным образом кодом файловой системы ядра.

С точки зрения непрофессионала /dev/rdiskидет почти непосредственно на диск и /dev/diskидет по более длинному более дорогому маршруту


14
зачем использовать диск, если вы можете использовать rdisk?
— user391339

20
@ user391339 Потому что кэширование все еще желательно. В тех случаях, когда у вас есть съемный носитель, вы хотите получить данные на физическом устройстве как можно быстрее, потому что вы хотите, чтобы данные находились в другом физическом месте. Внутренние жесткие диски - это отдельная история. Вы обычно не носите их с собой, поэтому вам все равно, когда данные фактически записываются на устройство. Когда вы кэшируете данные, записанные на устройства / считываемые с устройств, это более дорогой способ записи на диск, но ваши программы все еще работают быстрее, поскольку им не нужно ждать, пока все данные, которые они хотят записать, будут записаны на диск.
— Kritzefitz

@Dan, Re "сила"; смысл?
— Pacerier

Не уверен, что объяснение Крита работает для меня. Мой случай может быть немного особенным, когда я хочу выполнить более быстрое однократное сканирование большого внешнего диска, и я не уверен, какой метод лучше подходит для этого, но в остальном я все еще в порядке при обычном использовании и жду, пока он извлечется, как это обычно бывает. практика. Однако в Windows я всегда предпочитал профиль «быстрого отключения», который, как мне кажется, отражает более «сырой» режим Mac, поскольку он сообщает о меньшем повреждении файловой системы при неожиданных событиях потери соединения.
— Пизис

96

Принятый ответ правильный, но не вдаваться в подробности.

Одно из ключевых различий между /dev/diskи /dev/rdiskпри обращении к ним из пространства пользователя заключается в том, что они /dev/diskбуферизируются. Путь чтения / записи для /dev/diskразбивает ввод / вывод на куски 4 КБ, которые он считывает в буферный кеш, а затем копирует в буфер пространства пользователя (а затем выдает следующее чтение 4 КБ…). Это хорошо тем, что вы можете выполнять выравнивание чтения и записи, и это просто работает. Напротив, в /dev/rdiskосновном просто передает чтение или запись прямо на устройство, что означает, что начало и конец ввода / вывода должны быть выровнены по границам сектора.

Если вы выполняете чтение или запись в более чем один сектор /dev/rdisk, этот запрос будет передан напрямую. Нижние уровни могут разбить его (например, USB разбивает его на куски по 128 КБ из-за максимального размера полезной нагрузки в протоколе USB), но в целом вы можете получить более крупные и эффективные операции ввода-вывода. При потоковой передаче, например, через dd, от 128 КБ до 1 МБ достаточно хороших размеров, чтобы получить почти оптимальную производительность на текущем оборудовании без RAID.

Кэширование, выполняемое /dev/diskпутями чтения и записи, очень простое и почти мертвое. Он кэшируется, даже если это не строго необходимо; например, если устройство может отображать карту памяти и напрямую переноситься в буфер вашего приложения. Он выполняет небольшие операции ввода-вывода (4 КБ), что приводит к значительным накладным расходам на ввод-вывод. Это не делает никакого чтения вперед или записи позади.


6

Кажется /dev/diskи /dev/rdiskработает по-разному для HDD и SSD. Хочу проверить это на карту MicroSD. Только что записал образ диска 2 ГБ в Sandisk Ultra MicroSD 64 ГБ ( https://www.amazon.com/gp/product/B073JYVKNX ).

Повторные тесты несколько раз, но результаты были стабильными: 17MB / s для /dev/diskпротив 20MB / s для /dev/rdisk. Переключение bs=1mна bs=16mдает абсолютно никакой разницы в скорости записи.

  1. Запись в /dev/disk2

    sudo dd if=~/Downloads/ubuntu-18.04-4.14-minimal-odroid-xu4-20180531.img of=/dev/disk2 bs=1m
    2094006272 bytes transferred in 121.860007 secs (17183704 bytes/sec)
    
  2. Запись в /dev/rdisk2

    $ sudo dd if=~/Downloads/ubuntu-18.04-4.14-minimal-odroid-xu4-20180531.img of=/dev/rdisk2 bs=1m
    2094006272 bytes transferred in 102.743870 secs (20380839 bytes/sec)
    

Тогда я решил проверить скорость чтения: 26MB / s для /dev/diskпротив 87MB / s для /dev/rdisk. Переключение bs=1mна bs=16mдает абсолютно никакой разницы в скорости чтения.

  1. Чтение из /dev/disk2

    sudo dd if=/dev/disk2 of=~/Downloads/ubuntu-18.04-4.14-minimal-odroid-xu4-20180531-2.img bs=1m
    257949696 bytes transferred in 9.895572 secs (26067184 bytes/sec)
    
  2. Чтение из /dev/rdisk2

    $ sudo dd if=/dev/rdisk2 of=~/Downloads/ubuntu-18.04-4.14-minimal-odroid-xu4-20180531.img bs=1m
    877658112 bytes transferred in 10.021974 secs (87573377 bytes/sec)
    

2

Я знаю, что это старая тема, но другие люди могут быть заинтересованы в том, что я попробовал. Я хочу сделать резервную копию моего внутреннего SSD в Macina Pro 13 "Retina (с твердотельным накопителем Silicon Power 1 ТБ) на внешний жесткий диск USB 3.0 2.5", чтобы захватить разделы macOS и BOOTCAMP. Моя начальная командная строка была:

sudo dd if=/dev/disk0 of=/dev/disk2 bs=1m

Результатом была скорость копирования ~ 31,3 МБ / с. Это было слишком долго, чтобы заставить меня ждать. Итак, со второй попытки командная строка была:

sudo dd if=/dev/rdisk0 of=/dev/rdisk2 bs=1m

Использование /dev/rdiskвместо того, чтобы /dev/diskзначительно ускорить, до 98,4 МБ / с! Тем не менее, это становится еще лучше. Итак, для третьей попытки я использовал эту командную строку:

sudo dd if=/dev/rdisk0 of=/dev/rdisk2 bs=1m conv=sparse

Опция sparse указывает DD не беспокоить запись в выходные блоки, которые имеют все 0 на входе. Круто то, что это происходит намного быстрее, чем вы думаете, даже находясь в середине «полных» областей диска. На любом диске, который не заполнен, у вас будут огромные куски 0, что еще больше ускорит DD. Пока, по крайней мере, DD почти работает на теоретической скорости передачи моего жесткого диска: ~ 116,4 МБ / с, и он еще не достиг этих больших пустых областей.

Попробуйте эти варианты - они работают! Пожалуйста, обратите внимание: ВНИМАТЕЛЬНО измените if=и  of=правильно укажите правильные диски, перечисленные (для Mac):

diskutil list

1
conv=sparseотлично, когда вы копируете файлы.    Я бы обеспокоен тем , что это могло бы ввести коррупцию при копировании диска целиком, раздела или в  файловой системе , если вы не знаете , с 100% уверенностью , что целевой диск не содержит ничего , кроме нулей.
— G-Man

1

Для записи, по крайней мере в macOS High Sierra, / dev / disk оказывается намного быстрее, чем / dev / rdisk. Запустив dd или ddrescue, мое копирование для сравнения пропускной способности с магнитного HD на SSD было 3,7 МБ / с при использовании / dev / rdisk, и 45 МБ / с при использовании / dev / disk. Таким образом, в более поздних версиях macOS может быть лучше использовать / dev / disk вместо / dev / rdisk для лучшей производительности.


2
При записи растягиваемого изображения размером 4,6 ГБ из внутреннего хранилища SSD на SD-карту с dd и bs в 1 МБ / dev / rdisk по-прежнему работает намного быстрее, чем / dev / disk, в конце 2013 года MacBook Pro с MacOS 10.13.2. Использование / dev / disk заняло 27,16 минут, а использование / dev / rdisk - всего 5,18 минут.
— digitaladdictions

@digitaladdictions только что провела несколько тестов на последних
— версиях

0

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

как спецификация карты Micro SD, класс 4/10 / HC I ... sd чип и интерфейс устройства чтения карт памяти, USB 1.1 / 2.0 / 3.0 / 3.1 для общей памяти / свободной памяти, загрузка под ОС, тип жесткого диска, HDD / SSD, HDD скорость вращения и размер кэша, размер SSD / кэш / свободное пространство / интерфейс жесткого диска os, ata / sata / esata,

если какой-то фактор стал узким местом, то мы получим ложное заключение.

Вот мой результат: OSX 10.12.6, SSD,

чтение microSD 16G с карты памяти USB 2.0 чтение и запись на внешний 3,5-дюймовый жесткий диск USB 3.0

15193+1 records in
15193+1 records out
15931539456 bytes transferred in 1423.067033 secs (11195214 bytes/sec)

запись microSD 32G через внутреннюю карту для чтения, а источником данных является внешний 3,5-дюймовый жесткий диск USB 3.0,

0+253945 records in
0+253945 records out
15931539456 bytes transferred in 440.093686 secs (36200336 bytes/sec)

Вы можете видеть, скорость записи> скорость чтения !!

Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.