В Ubuntu VM исправлена проблема с файловой системой только для чтения?

Question

Я собирался установить инструменты VMWare на виртуальную машину сервера Ubuntu, но столкнулся с проблемой невозможности создать каталог cdrom в каталоге /mnt. Затем я проверил, была ли это просто проблема с разрешениями, но я даже не смог создать папку в домашнем каталоге. Он продолжает утверждать, что это файловая система только для чтения. Я немного знаю о Linux, и мне это пока не удобно. Любые советы будут высоко ценится.

Запрашиваемая информация из комментария:

имя пользователя @ имя_сервера:~ $ mount
/dev /sda1 on / введите ext4 (rw, errors = Remount-ro)
proc on / proc тип proc (rw)
нет в / sys тип sysfs (rw, noexec, nosuid, nodev)
нет на / sys / fs / fuse / подключения тип fusectl (rw)
нет в / sys / kernel / debug тип debugfs (rw)
нет в / sys / kernel / security тип securityfs (rw)
udev on /dev type tmpfs (rw, mode = 0755)
нет в /dev / pts, введите devpts (rw, noexec, nosuid, gid = 5, mode = 0620)
нет в /dev / shm типа tmpfs (rw, nosuid, nodev)
нет в / var / run типа tmpfs (rw, nosuid, mode = 0755)
нет в / var / lock типа tmpfs (rw, noexec, nosuid, nodev)
нет в / lib / init / rw тип tmpfs (rw, nosuid, mode = 0755) binfmt_misc в / proc / sys / fs / binfmt_misc тип binfmt_misc (rw, noexec, nosuid, nodev)

Наверняка корневой вывод.

root @ server01:~ # mount
/dev/sda1 on / введите ext4 (rw, errors = Remount-ro)
proc on / proc тип proc (rw)
нет в / sys тип sysfs (rw, noexec, nosuid, nodev)
нет на / sys / fs / fuse / подключения тип fusectl (rw)
нет в / sys / kernel / debug тип debugfs (rw)
нет в / sys / kernel / security тип securityfs (rw)
udev on /dev type tmpfs (rw, mode = 0755)
нет в /dev/ pts, введите devpts (rw, noexec, nosuid, gid = 5, mode = 0620)
нет в /dev/ shm типа tmpfs (rw, nosuid, nodev)
нет в / var / run типа tmpfs (rw, nosuid, mode = 0755)
нет в / var / lock типа tmpfs (rw, noexec, nosuid, nodev)
нет в / lib / init / rw тип tmpfs (rw, nosuid, mode = 0755) binfmt_misc в / proc / sys / fs / binfmt_misc тип binfmt_misc (rw, noexec, nosuid, nodev)

Answer 1

Хотя это довольно старый вопрос, ответ остается прежним. У вас есть виртуальная машина (работающая на физическом хосте) и какое-то хранилище (либо общее хранилище - FC SAN, хранилище iSCSI, общий ресурс NFS - или локальное хранилище).

При виртуализации многие виртуальные машины пытаются получить доступ к одним и тем же физическим ресурсам одновременно. Из-за физических ограничений (количество операций чтения / записи - IOPS; пропускная способность; задержка) может возникнуть проблема с одновременным удовлетворением всех запросов на хранение всех физических машин. Что обычно происходит: вы сможете увидеть "повторы SCSI" и неудачные операции SCSI в операционных системах ваших виртуальных машин. Если вы получаете слишком много ошибок / повторных попыток в течение определенного периода времени, ядро установит подключенные файловые системы только для чтения, чтобы предотвратить повреждение файловой системы.

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

Есть не так уж много вещей, которые вы можете сделать. Очевидное решение - лучше / дополнительная память. Вы также можете изменить параметры времени ожидания SCSI в ядре Linux. Подробности описаны, например, в:

http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=1009465

http://www.cyberciti.biz/tips/vmware-esx-server-scsi-timeout-for-linux-guest.html

Однако это только "отложит" ваши проблемы, потому что ядро получает больше времени, прежде чем файловая система будет доступна только для чтения. (То есть вы не решаете причину проблемы.)

Мой опыт (несколько лет с VMware) заключается в том, что эта проблема существует только с ядрами Linux (мы используем RHEL и SLES), а не с серверами Windows. Также эта проблема возникает на всех типах хранилищ - FC, iSCSI, локальное хранилище. Для нас наиболее важным (и дорогим) компонентом нашей виртуальной инфраструктуры является хранилище. (Сейчас мы используем HP LeftHand с iSCSI-соединениями 1 Гбит / с, и с тех пор у нас не было проблем с хранением данных. Мы выбрали LeftHand (вместо традиционных FC-решений) за его масштабируемость.

Answer 2

Вероятное объяснение состоит в том, что существует аппаратная проблема (частичный сбой диска), и что ядро перемонтировало корневую файловую систему как доступную только для чтения, как только она обнаружила проблему, чтобы минимизировать проблему. Более надежным способом проверки текущих параметров монтирования является cat /proc/mounts (grep ' / ' /proc/mounts для корневой файловой системы, игнорируйте строку rootfs / … которая является артефактом процесса загрузки). Вероятно, вы обнаружите, что rw,errors=remount-ro изменилось на ro (другие опции могут отображаться дополнительно).

Журналы ядра, вероятно, содержат сообщение « Remounting filesystem read-only , которому предшествуют ошибки доступа к диску. Журналы обычно хранятся в /var/log/kern.log , однако, если он находится в файловой системе, доступной только для чтения, сообщение там не будет отображаться, хотя предыдущие ошибки должны появиться. Вы также можете увидеть последние ошибки в ядре с помощью команды dmesg .

Кроме того, в Ubuntu обычное место для точек монтирования (используется интерфейсом рабочего стола) находится в /media (например, /media/cdrom0), хотя вы можете использовать /mnt или /mnt/cdrom если хотите.

¹ _{mount отчеты из /etc/mtab .Если корневая файловая система доступна только для чтения, /etc/mtab не может обновляться .}

Answer 3

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

Answer 4

Может быть, это очевидно, но вы "root" пользователь, пытаясь это сделать? /mnt принадлежит пользователю root и доступен для записи только пользователю root. Вы также можете проверить наличие ошибок при загрузке. Ваш вывод выше говорит о том, что / (и, следовательно, /mnt) следует перемонтировать только для чтения, если процесс загрузки видит ошибки. Вы можете изменить это (т.е. перемонтировать как r / w) с помощью команды mount, но я бы не стал этого делать, если вы не уверены, что причиной ошибки не было.