Почему «/ 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.