Решение было довольно просто: Я просто должен был добавить следующие строки в виртуальной машине Debian /etc/network/interfaces
файл:
allow-hotplug eth1
iface eth1 inet dhcp
Вторая строка дает интерфейсу команду получать IP через DHCP. Первая строка загружает интерфейс во время начальной загрузки.
Для применения изменений в рабочей системе вызовите:
ifup eth1
Название eth1
интерфейс может варьироваться, использовать ifconfig -a
перечислять все доступные интерфейсы.
Править: полный /etc/network/interfaces
:
# This file describes the network interfaces available on your system
# and how to activate them. For more information, see interfaces(5).
# The loopback network interface
auto lo
iface lo inet loopback
# The primary network interface
allow-hotplug eth0
iface eth0 inet dhcp
allow-hotplug eth1
iface eth1 inet dhcp
Linux, точно так же, как большинство других операционных систем, действительно кэширует дисковые IO операции. Вы могли вынудить ядро сбросить свои буферы с sync
команда после выполнения файла модификации. Однако это ухудшает производительность целой системы, поскольку все в настоящее время 'грязные' буферы сбрасываются к дискам с этой командой. С другой стороны, Вы могли использовать fsync
C библиотечная функция для сбрасывания изменений Вы просто сделали в некоторый конкретный файл, но эта функция не гарантирует, что целая файловая система будет в согласованном состоянии на медиа.
Вы смогли находить старую версию того же файла даже после размонтирования его, как файловая система должна не обязательно хранить новый файл в том же месте. Таким образом, новый файл не обязательно перезаписывает старый, если он хранится в другом свободном месте.
Изменения, которые Вы вносите в файловой системе, сразу не записаны в диск из-за причин производительности. Почему заставляют программы ожидать, пока файл не был на самом деле физически выписан полностью, когда у Вас может точно также быть ОС, делают это в фоновом режиме? Иногда это асинхронное поведение может даже сохранить записи в целом, такой как тогда, когда файл удален или сразу перезаписан после создания это никогда не должно было физически храниться во-первых.
Можно отключить то поведение для большинства файловых систем с помощью sync
смонтируйте опцию. Существует также sync
команда, которая вынуждает данные быть записанными в диск без umounting.
Вы никогда не должны получать доступ к необработанным данным файловых систем все же. Если Вы имеете смонтированный/dev/sdb1 и затем используете другую машину для монтирования той же самой файловой системы (по сетевому блочному устройству или безотносительно), таким образом, две системных работы с теми же данными файловой системы одновременно, Вы закончите с повреждением. Только специальные (кластерные) файловые системы прокладывают себе путь; для всех других Вам нужна сетевая файловая система (где только одна машина монтирует диск и выставляет его файлы прозрачно по сети).
sync
кажется, не помогает. Причина я должен получить доступ к сырым данным/dev/sdb, состоит в том, что я тестирую игрушечного читателя файловой системы (игрушечной ОС).
– Karolis Juodelė
19.02.2013, 19:26
fsck
после неожиданного сбоя питания. То, что находится на устройстве, не должно быть завершено или применимо, пока оно все еще смонтировано.
– frostschutz
19.02.2013, 22:32
sync
не имел никакого значения. – Karolis Juodelė 19.02.2013, 19:15regular
инструменты, по крайней мере, предупреждает Вас, когда Вы пытаетесь сделать что-то со смонтированной фс. Причиной такого поведения является производительность. Однако Вы могли попробоватьsync
иdirsync
опции сmount
поскольку другой ответ предлагает – Serge 19.02.2013, 19:49