У меня Samsung XE303C12, и я использую Arch Linux ARM на нем с SD-карты. Таблица разделов SD-карты такова:
- Раздел ядра Chrome OS, на котором находится ядро ALARM с оболочкой vboot.
- Раздел ext2, который я бы использовал для настройки U-Boot всякий раз, когда он устанавливается в раздел 1 вместо ядра Arch Linux.
- Корневая файловая система, в которую я установил Arch Linux.
Недавняя попытка обновить все пакеты сразу привела к повреждению корневой файловой системы. Я видел сообщение о том, что ядро перепрошено на какой-то раздел на SD-карте, а файловая система не может быть смонтирована только для чтения или чтения-записи, или что-то в этом роде. Я пытался исправить это с помощью fsck , который несколько раз подсказывал мне, что делать с inode, но как только я понял, что он, вероятно, будет запрашивать это для каждого отдельного inode в разделе, я запустил fsck -y /dev/mmcblk1p3 , Это пробежало несколько сотен инодов, пока не остановилось. Я не могу вспомнить сообщение об ошибке.
В надежде сохранить данные для последующего восстановления, я делаю резервную копию /dev/mmcblk1p3 в файловую систему FAT32 на USB-накопителе с использованием dd . Поскольку FAT32 не может содержать файлы размером более 4 ГБ, я решил разбить его на сегменты, используя некоторый шелл-код и циклы.
Пропустив несколько вещей, я понял, что dd быстрее в начале процесса (я использовал bs с большим кратным 512, чтобы ускорить его), поэтому первый сегмент размером 64 МБ будет записан в файловую систему USB. через 3 секунды, и он будет становиться все медленнее с каждой итерацией. Я узнал, что это потому, что кэш диска заполняется.
Я искал способ очистить кэш для dd и наткнулся на этот пост на сайте Unix Stack Exchange. Верхний ответ говорит о необходимости sync; echo 3 > /proc/sys/vm/drop_caches . В комментарии к этому ответу отмечается, что этот параметр не является липким, и ссылка в этом комментарии дала мне идею сделать echo 3 > /proc/sys/vm/drop_caches перед каждой итерацией dd . Я попробовал это, и dd все еще упал в скорости копирования.
Второе решение, упомянутое в ответе первого поста, состояло в том, чтобы запустить dd с iflag=direct как способ обойти кеш. Я сделал это, но также использовал oflag=direct так как полагал, что кеш будет применяться как для копирования с SD-карты, так и для записи на USB. В этом комментарии говорилось, что вместо nocache следует использовать direct , поэтому я тоже это попробовал. Оба метода испытали одинаковое падение с ~ 17 МБ / с до ~ 1-3 МБ / с.
Я предполагаю, что, возможно, я не использовал эти методы правильно, поэтому есть ли надежная очистка кеша на каждой итерации, чтобы сделать dd быстрее, или какой-то способ вообще не использовать кеш?