Вопросы Теги

Изменения в файлах не показывают вплоть до раздела, размонтирован

Решение было довольно просто: Я просто должен был добавить следующие строки в виртуальной машине 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
0
19.02.2013, 18:55
2 ответа

Linux, точно так же, как большинство других операционных систем, действительно кэширует дисковые IO операции. Вы могли вынудить ядро сбросить свои буферы с sync команда после выполнения файла модификации. Однако это ухудшает производительность целой системы, поскольку все в настоящее время 'грязные' буферы сбрасываются к дискам с этой командой. С другой стороны, Вы могли использовать fsync C библиотечная функция для сбрасывания изменений Вы просто сделали в некоторый конкретный файл, но эта функция не гарантирует, что целая файловая система будет в согласованном состоянии на медиа.

1
28.01.2020, 02:37
  • 1
    К сожалению, sync не имел никакого значения. –  Karolis Juodelė 19.02.2013, 19:15
  • 2
    Обычно это не хорошая идея вообще, чтобы сделать модификации в файлы на фс и считать ее необработанный раздел одновременно. Единственный метод для создания изображения фс или раздела абсолютно последовательными должен размонтировать его. –  Serge 19.02.2013, 19:30
  • 3
    Хорошо, я предполагаю, что привыкну к монтированию затем. Почему это то, хотя? Предотвратить повреждение? номер –  Karolis Juodelė 19.02.2013, 19:43
  • 4
    , как только у Вас есть корневой доступ, ничто не может препятствовать тому, чтобы Вы повредили свою систему. Однако большинство regular инструменты, по крайней мере, предупреждает Вас, когда Вы пытаетесь сделать что-то со смонтированной фс. Причиной такого поведения является производительность. Однако Вы могли попробовать sync и dirsync опции с mount поскольку другой ответ предлагает –  Serge 19.02.2013, 19:49

Вы смогли находить старую версию того же файла даже после размонтирования его, как файловая система должна не обязательно хранить новый файл в том же месте. Таким образом, новый файл не обязательно перезаписывает старый, если он хранится в другом свободном месте.

Изменения, которые Вы вносите в файловой системе, сразу не записаны в диск из-за причин производительности. Почему заставляют программы ожидать, пока файл не был на самом деле физически выписан полностью, когда у Вас может точно также быть ОС, делают это в фоновом режиме? Иногда это асинхронное поведение может даже сохранить записи в целом, такой как тогда, когда файл удален или сразу перезаписан после создания это никогда не должно было физически храниться во-первых.

Можно отключить то поведение для большинства файловых систем с помощью sync смонтируйте опцию. Существует также sync команда, которая вынуждает данные быть записанными в диск без umounting.

Вы никогда не должны получать доступ к необработанным данным файловых систем все же. Если Вы имеете смонтированный/dev/sdb1 и затем используете другую машину для монтирования той же самой файловой системы (по сетевому блочному устройству или безотносительно), таким образом, две системных работы с теми же данными файловой системы одновременно, Вы закончите с повреждением. Только специальные (кластерные) файловые системы прокладывают себе путь; для всех других Вам нужна сетевая файловая система (где только одна машина монтирует диск и выставляет его файлы прозрачно по сети).

1
28.01.2020, 02:37
  • 1
    sync кажется, не помогает. Причина я должен получить доступ к сырым данным/dev/sdb, состоит в том, что я тестирую игрушечного читателя файловой системы (игрушечной ОС). –  Karolis Juodelė 19.02.2013, 19:26
  • 2
    С LVM Вы могли сделать снимки. Идеально снимок синхронизируется правильно и замораживается на месте, таким образом, он должен высказать Вам последовательное мнение. Доступ к чтению-записи смонтировал, что устройство просто приведет к повреждению, поскольку его состояние не определено / изменение, следовательно потребность к fsck после неожиданного сбоя питания. То, что находится на устройстве, не должно быть завершено или применимо, пока оно все еще смонтировано. –  frostschutz 19.02.2013, 22:32

Теги

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