Ubuntu VM „naprawia system plików tylko do odczytu”?

9

Zamierzałem zainstalować narzędzia VMWare na maszynie wirtualnej serwera Ubuntu, ale natknąłem się na problem z niemożnością utworzenia katalogu cdrom w katalogu / mnt. Następnie przetestowałem, czy to tylko kwestia uprawnień, ale nie mogłem nawet utworzyć folderu w katalogu domowym. Nadal stwierdza, że ​​jest to system plików tylko do odczytu. Wiem trochę o Linuksie i jeszcze mi się nie podoba. Wszelkie porady będą mile widziane.

Żądane informacje z komentarza:

nazwa użytkownika @ nazwa serwera : ~ $ mount
/ dev / sda1 on / type ext4 (rw, error = remount-ro)
proc on / proc type proc (rw)
none on / sys type sysfs (rw, noexec, nosuid, nodev)
none on / sys / fs / fuse / connection type fusectl (rw)
none on / sys / kernel / debug type debugfs (rw)
none on / sys / kernel / security type securityfs (rw)
udev on / dev type tmpfs (rw, mode = 0755)
none on / dev / pts type devpts (rw, noexec, nosuid, gid = 5, mode = 0620)
none on / dev / shm type tmpfs (rw, nosuid, nodev)
none on / var / run type tmpfs (rw , nosuid, mode = 0755)
none on / var / lock type tmpfs (rw, noexec, nosuid, nodev)
none on / lib / init / rw type tmpfs (rw, nosuid, mode = 0755) binfmt_misc on / proc / sys / fs / binfmt_misc type binfmt_misc (rw, noexec, nosuid, nodev)

Na pewno wyjście root.

root @ server01: ~ # mount
/ dev / sda1 on / type ext4 (rw, error = remount-ro)
proc on / proc type proc (rw)
none on / sys type sysfs (rw, noexec, nosuid, nodev)
none on / sys / fs / fuse / connection type fusectl (rw)
none on / sys / kernel / debug type debugfs (rw)
none on / sys / kernel / security type securityfs (rw)
udev on / dev type tmpfs (rw, mode = 0755)
none on / dev / pts type devpts (rw, noexec, nosuid, gid = 5, mode = 0620)
none on / dev / shm type tmpfs (rw, nosuid, nodev)
none on / var / run type tmpfs (rw , nosuid, mode = 0755)
none on / var / lock type tmpfs (rw, noexec, nosuid, nodev)
none on / lib / init / rw type tmpfs (rw, nosuid, mode = 0755) binfmt_misc on / proc / sys / fs / binfmt_misc type binfmt_misc (rw, noexec, nosuid, nodev)

alternatywny tekst

alternatywny tekst

David
źródło
1
Czy możesz wydrukować wynik polecenia „mount”? (nie wymaga parametrów)
pgruetter
Dodano do odpowiedzi. Dziękujemy za pytanie o pomocne informacje.
David
Dla pewności: „sudo mkdir / mnt / cdrom” kończy się niepowodzeniem, prawda?
Janne Pikkarainen
Mylę mnie to, że mówi, że jest to system plików tylko do odczytu. Dane wyjściowe polecenia brzmią „rw”, czyli odczytany system plików zapisu. Sam system plików powinien być w porządku. Do którego folderu próbujesz pisać? Czy możesz również podać wynik „ls -la <the_folder>”?
pgruetter
Dodałem zdjęcie na dole, które jest obrazem tego, co otrzymuję, gdy wykonam żądane polecenie. Daj mi znać, jeśli potrzebujesz mnie do zrobienia czegoś innego. :)
David

Odpowiedzi:

16

Chociaż jest to stosunkowo stare pytanie, odpowiedź jest nadal taka sama. Masz maszynę wirtualną (działającą na hoście fizycznym) i jakiś rodzaj pamięci (pamięć współdzieloną - FC SAN, pamięć iSCSI, udział NFS - lub pamięć lokalna).

Dzięki wirtualizacji wiele maszyn wirtualnych próbuje uzyskać dostęp do tych samych zasobów fizycznych w tym samym czasie. Ze względu na ograniczenia fizyczne (liczba operacji odczytu / zapisu - IOPS; przepustowość; opóźnienie) może wystąpić problem z zaspokojeniem wszystkich żądań pamięci wszystkich maszyn fizycznych w tym samym czasie. Co zwykle się dzieje: w systemach operacyjnych maszyn wirtualnych będą widoczne „Ponowne próby SCSI” i nieudane operacje SCSI. Jeśli w określonym czasie pojawi się zbyt wiele błędów / ponownych prób, jądro ustawi zamontowane systemy plików tylko do odczytu, aby zapobiec uszkodzeniu systemu plików.

Krótko mówiąc: Twoja pamięć fizyczna nie jest wystarczająco „mocna”. Jednocześnie zbyt wiele procesów (maszyn wirtualnych) uzyskuje dostęp do systemu pamięci masowej, maszyny wirtualne nie otrzymują odpowiedzi z pamięci wystarczająco szybko, a system plików przechodzi tylko do odczytu.

Niewiele rzeczy można zrobić. Oczywistym rozwiązaniem jest lepsze / dodatkowe miejsce do przechowywania. Możesz także zmodyfikować parametry limitów czasu SCSI w jądrze Linux. Szczegóły opisano np. W:

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

Spowoduje to jednak jedynie „odłożenie” problemów, ponieważ jądro ma więcej czasu, zanim system plików zostanie ustawiony jako tylko do odczytu. (Tj. Nie rozwiązujesz przyczyny problemu).

Moje doświadczenie (kilka lat z VMware) polega na tym, że ten problem występuje tylko w jądrach Linuksa (używamy RHEL i SLES), a nie w serwerach Windows. Ponadto ten problem występuje na wszystkich rodzajach pamięci - FC, iSCSI, pamięć lokalna. Dla nas najważniejszym (i najdroższym) elementem naszej infrastruktury wirtualnej jest pamięć masowa. (Używamy teraz HP LeftHand z połączeniami iSCSI 1 Gb / s i od tego czasu nie mieliśmy żadnych problemów z pamięcią. Wybraliśmy LeftHand (w porównaniu z tradycyjnymi rozwiązaniami FC) ze względu na jego skalowalność.

Josef
źródło
Łał! Świetna odpowiedź. Zupełnie zapomniałem o tym pytaniu. Oznacziłem twoją odpowiedź jako zaakceptowaną. Centrum danych, z którym obecnie pracuję (który jest dużym partnerem VMWare), niedawno zaktualizowało swoją pamięć do Hitachi Pod. W rzeczywistości dodajemy kolejną kapsułę do środowiska, aby pomóc w obciążeniu procesorów IOP, ponieważ zaczęliśmy napotykać dodatkowe problemy z procesorami IOP (podkreślając, że musimy zaktualizować lub rozszerzyć zasoby SAN). Tak więc w przeszłości, ponownie zwiększyliśmy nasze zasoby SAN.
David
4

Prawdopodobnym wyjaśnieniem jest problem sprzętowy (częściowa awaria dysku) oraz że jądro ponownie zamontowało główny system plików jako tylko do odczytu, gdy tylko wykryje problem, aby zminimalizować problem. Bardziej niezawodnym¹ sposobem sprawdzenia bieżących opcji montowania jest cat /proc/mounts( grep ' / ' /proc/mountsw przypadku głównego systemu plików zignoruj rootfs / …wiersz będący artefaktem procesu rozruchu). Prawdopodobnie okaże się, że rw,errors=remount-rozmieniło się na ro(inne opcje mogą być wyświetlane dodatkowo).

Dzienniki jądra prawdopodobnie zawierają komunikat Remounting filesystem read-onlypoprzedzony błędami dostępu do dysku. Dzienniki zwykle znajdują się w /var/log/kern.logsystemie, jednak jeśli jest to system plików tylko do odczytu, komunikat się tam nie pojawi, chociaż poprzednie błędy powinny. Za pomocą polecenia można również zobaczyć kilka ostatnich błędów jądra dmesg.

Nawiasem mówiąc, w Ubuntu, zwykłe miejsce dla punktów montowania (używane przez interfejs pulpitu) znajduje się pod /media(np. /media/cdrom0), Chociaż możesz użyć /mntlub /mnt/cdromjeśli chcesz.

¹ raporty z . Jeśli główny system plików jest tylko do odczytu, nie można go aktualizować. mount/etc/mtab/etc/mtab

Gilles „SO- przestań być zły”
źródło
Jedynym złym sprzętem jest to, że jest to maszyna wirtualna, dlatego nie może to być problem sprzętowy, ponieważ na fizycznych hostach znajdują się setki maszyn wirtualnych, a moja jest jedyna z problemem. Sprawdzę dzienniki jądra i spróbuję zamieścić zrzut ekranu w pytaniu.
David
Jeśli masz limit rozmiaru na wirtualnym dysku twardym i jest on pełny, Ubuntu nie powiedzie się, jak pokazano powyżej. Możesz sprawdzić.
CarlF
@David: Dzienniki pokazują, że Linux napotkał problem sprzętowy, tylko sprzęt jest wirtualny. Uważam hipotezę CarlF za bardzo wiarygodną.
Gilles „SO- przestań być zły”
3

Stało się tak, że ostatnio doszło do awarii zasilania w centrum danych. Od tego czasu nie dotknąłem mojego serwera. Kiedy nasze centrum danych traci moc, VSphere sprawia, że ​​system plików Ubuntu jest odczytywany tylko do momentu ponownego uruchomienia. Spróbowałbym zrestartować komputer, ale nie chciałem, żeby cały monitoring zwariował. Uciszyłem Nagios (usługa monitorowania) i po ponownym uruchomieniu systemu wszystko działa dobrze. Dzięki za cały wkład. To jest bardzo cenione.

David
źródło
1

Może to być oczywiste, ale czy jesteś użytkownikiem „root”, gdy próbujesz to zrobić? / mnt jest własnością root i może być zapisywany tylko przez root. Możesz także sprawdzić, czy podczas uruchamiania wystąpiły błędy. Powyższe dane wyjściowe mówią, że / (a ​​tym samym / mnt) należy ponownie zamontować tylko do odczytu, jeśli proces rozruchu wykryje błędy. Możesz to zmienić (tj. Ponownie zamontować jako r / w) za pomocą polecenia mount, ale nie zrobiłbym tego, chyba że jesteś pewien, że to, co spowodowało błąd, nie jest poważne.

hotei
źródło
Gdybym to zrobił, mógłbym nie znajdować się w katalogu głównym, ale myślę, że wynik jest taki sam. Z pewnością dane wyjściowe z katalogu głównego znajdują się poniżej pierwszego wyniku.
David