Вопросы Теги

Почему dd использует прямой медленнее запись в диск, чем в файл

После проведения небольшого количества исследования о том, как получить последний Nagios 3.4.1 загрузки для Вас, я нашел этот код, который мог бы помочь Вам:

sudo –s

mkdir downloads

cd downloads

wget http://sourceforge.net/projects/nagios/files/nagios-3.x/nagios-3.4.1/nagios-3.4.1.tar.gz/download

tar –zxvf nagios-3.4.1.tar.gz

Я понимаю, что Вы желали использовать склонный - добираются для получения его, поскольку это - вероятно, самый легкий способ получить его. Но поскольку ysangkok сказал: "К сожалению, Nagios Inc., кажется, не обновляют их PPA с новыми пакетами".

Сообщите мне мотыгу, в которую Вы входите.

Ссылка

7
21.01.2014, 18:46
2 ответа

Это различие, несомненно, сводится к одной вещи: кэширование.

Будет действительно трудно придавить, где, особенно от пространства пользователя, но все ядра Linux буферизуют (кэш) записи файловой системы, если Вы не выполняете приемы для получения синхронных записей. Таким образом, ядро сохранит данные dd отправляет в файл куда-нибудь в памяти ядра. Ядро, вероятно, использует код файловой системы, чтобы сделать это. Некоторое время в будущем, ядро запланирует дисковый блок для выхода в диск. Это произойдет "асинхронно", когда-то после того, как ядро скажет dd то, что законченная запись.

Причина этого состоит в том, что движущиеся байты по шине и в дисковод, и затем на подложках дисков намного медленнее, чем ровное копирование от пользователя к памяти ядра. Обычно, программы не заботятся слишком много, что данные, которые они просто "записали", не доберутся до диска некоторое время. Аппаратная надежность достаточно высока, что данные добираются до диска почти всегда.

Это - простой ответ, но после того как Вы имеете, читает/пишет/удаляет все буферизованные в ядре, код файловой системы может использовать в своих интересах короткое время жизни файла, никогда не выписывая данные файлов, которые удалены, прежде чем они доберутся до диска. Код файловой системы может сгруппировать записи, чтобы использовать в своих интересах дисковые блоки, больше, чем группа записей и консолидировать их в одну запись. Существуют тонны оптимизации, которая может быть сделана в большинстве файловых систем.

5
27.01.2020, 20:18
  • 1
    Это означает, что несмотря на использование oflag=direct опции с dd пишут в файл, запись все еще идет через кэш? Но oflag=direct действительно вступает в силу при записи непосредственно в блочное устройство? –  user3216949 21.01.2014, 21:12
  • 2
    @user3216949 - я думаю это правда, но у меня нет сведений из первоисточника. Блочное устройство в конце пользователя-> ядро-> файловая система-> слои дисковода. Насколько я понимаю использование блочного устройства устраняет слой (слои) файловой системы в стеке. –  Bruce Ediger 21.01.2014, 22:12
  • 3
    @Bruce является там путем (как инструмент), чтобы проверить, что записи проходят кэш или нет? –  felix 21.01.2014, 23:10
  • 4
    @user3216949, Если Вы хотите удостовериться данные, на самом деле выписан к диску, используйте один из: conv=fdatasync conv=fsync oflag=dsync oflag=sync. –  Patrick 22.01.2014, 05:49

Диск cacheing программ копии делает это более быстрым затем использование dd, я принял бы.

Если это - единственный диск интенсивное выполнение приложения, ожидайте программы, чтобы выйти и затем работать:

$ sync; sync

Это сразу сбросит кэш. Если это требует времени к возврату к подсказке, Вы знаете, что это поражало кэш.

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

2
27.01.2020, 20:18
  • 1
    Спасибо, я понял использование Вашего предложения, что даже с использованием fsync один данные заканчиваются записанные в диск, но возможно более эффективно как одна объемная запись. –  user3216949 23.01.2014, 20:03

Теги

Похожие вопросы