Po uruchomieniu VirtualBox komputer stał się powolny, a następnie zawiesił się całkowicie z powodu OOM. Zwykle OOM powinien rozpocząć proces zabijania, aby zwolnić miejsce, ale tak się nie stało (po raz drugi tego doświadczyłem).
Miałem trochę niezapisanej ważnej pracy w edytorze tekstu, więc miałem nadzieję, że znajdę ją z powrotem w systemowej pamięci RAM po zabiciu wszystkich procesów w bieżącej konsoli za pomocą SysRq+ K. Wspomnianym komputerem jest laptop z 8 GiB RAM z systemem Linux x86_64 3.7.5 z dyskiem SSD jako dyskiem docelowym.
Moja pierwsza próba była dd if=/dev/mem of=memory
, ale nie powiodło się po odczytaniu 1 MB danych. Następnie próbowałem dd if=/dev/fmem of=memory bs=1M
, ale zatrzymało się to po odczytaniu 3010461696 bajtów (dokładnie 2871 MiB). Po zapoznaniu się z /proc/mtrr
(pokazanym poniżej) postanowiłem spróbować dodać skip=4096
. To ostatecznie zwolniło, czytając z prędkością zaledwie 3 MiB / s, więc przerwałem (dając plik 5,8 GiB). (przynajmniej ostatnie 100 MiB pliku zawiera FF
s)
reg01: base=0x000000000 ( 0MB), size= 2048MB, count=1: write-back
reg02: base=0x080000000 ( 2048MB), size= 1024MB, count=1: write-back
reg03: base=0x100000000 ( 4096MB), size= 4096MB, count=1: write-back
reg04: base=0x200000000 ( 8192MB), size= 1024MB, count=1: write-back
reg05: base=0x23c000000 ( 9152MB), size= 64MB, count=1: uncachable
reg06: base=0x0b4000000 ( 2880MB), size= 64MB, count=1: uncachable
reg07: base=0x0b8000000 ( 2944MB), size= 128MB, count=1: uncachable
Nie mogłem znaleźć danych, które miałem otwarte przez kilka godzin w edytorze tekstu, więc uważam, że pominąłem trochę pamięci podczas zrzutu. Biorąc pod uwagę mój cel (odzyskiwanie danych z programów przestrzeni użytkownika), jaka jest najbardziej efektywna metoda zrzucenia pamięci systemowej do pliku? Jakie punkty należy wziąć pod uwagę podczas takiego zrzutu?
źródło
CONFIG_DEVKMEM
jest wyłączony, patrząc w kodzie źródłowym wydaje się, że pozwala na nieograniczony dostęp, ale nadal nie jestem przekonany, że to najlepszy sposób, aby to zrobić (dostęp doOdpowiedzi:
Sprawdź ten projekt: foriana
Istnieje moduł jądra fmem:
Korzystam z niego, kompilacja jest dość łatwa.
źródło
/dev/fmem
.Możesz użyć
ddrescue
lub podobnego programu, który może pominąć niedostępne dane.dd conv=noerror
też może być pomocny. Sprawdź również to pytanie na superużytkowniku .Co ważniejsze, jeśli wpadłeś w sytuację OOM, powolność była najprawdopodobniej spowodowana wymianą stron przez jądro z niczego innego niż aplikacja żądająca. Dlatego jeśli chcesz swoje dane, sprawdź swap zamiast
/dev/mem
- są szanse, że tam będzie. Podobnie, jeśli zabójca OOM nie uruchomi się i zabijesz procesy ręcznie, np. Gdy twój edytor zostanie zabity jako pierwszy, proces głodowania pamięci może się jeszcze zdarzyć, aby uzyskać trochę czasu na przechwycenie tych stron.Jak wspomniano przez Gilles w komentarzu, dane mogą łatwo być w jakiejś specjalnej strukturze, dzięki czemu nie będą mogli znaleźć je tak łatwo, nawet jeśli uda się zrekonstruować przestrzeń adresowa mapowania zabity procesowego i mają wystarczająco dużo szczęścia, aby znaleźć wszystkie potrzebne strony wciąż nienaruszone.
źródło
ddrescue
nie pomoże mi, ponieważ 256 stron (1 MiB) jest ustalonym limitem. Oczekiwałbym, że dostanę się do stanu OOM, ale zabójca OOM nie uruchomił się ( pastebin.com/DvYTCcRK ). Tydzień temu miałem ten sam problem (wciąż Linux 3.7.5, nie uruchomiłem się ponownie, tylko zawiesiłem na ram). Nie ma pliku wymiany / partycji, ponieważ mam dysk SSD. (swappiness = 60 (domyślnie)).