Tags Posts tagged with "system plików"

system plików

Sprzęt, Dysk twardy

Podczas tworzenia systemu plików Ext3 lub Ext4, system rezerwuje dla siebie 5% z rozmiaru partycji. Do czego potrzebna mu jest ta przestrzeń? Zapobiega ona fragmentacji systemu plików oraz umożliwia działanie procesów systemowych np. syslogd(8), podczas przepełnienia dysku. Jest to bardzo przydatna cecha dla systemu, natomiast, czy potrzebujemy jej na partycji, która służy nam jako magazyn plików np. zdjęć i filmów?

Przy obecnych rozmiarach dysków i partycji ten “utracony” 5% to naprawdę sporo. Dla przestrzeni 1TB możemy odzyskać 50GB, a to całkiem pokaźna ilość wolnego miejsca do wykorzystania.

Jak odzyskać to miejsce? Posłuży nam do tego program tune2fs. Spójrzmy na partycję /dev/sdb1, zamontowaną w katalogu /mnt.

[root@localhost ~]# df -h
System plików         rozm. użyte dost. %uż. zamont. na
/dev/mapper/VolGroup-lv_root
                      3,5G  698M  2,6G  21% /
tmpfs                 250M     0  250M   0% /dev/shm
/dev/sda1             485M   64M  396M  14% /boot
/dev/sdb1              99G  188M   94G   1% /mnt

Dostępne mamy 94G. Wystarczy wydać polecenie tune2fs -m 0 /dev/sdb1, aby odzyskać wydzielone miejsce dla systemu.

[root@localhost ~]# df -h
System plików         rozm. użyte dost. %uż. zamont. na
/dev/mapper/VolGroup-lv_root
                      3,5G  696M  2,6G  21% /
tmpfs                 250M     0  250M   0% /dev/shm
/dev/sda1             485M   64M  396M  14% /boot
/dev/sdb1              99G  188M   99G   1% /mnt

W ten sposób zredukowaliśmy ilość zarezerwowanej pojemności z 5% do 0%. Nic nie stoi na przeszkodzie, by ustawić tę wartość na 10% czy 0.5%. Operacje te są bezpieczne i można je wykonywać na zamontowanym systemie plików. Nic nie stoi na przeszkodzie, aby wcześniej go odmontować, a następnie wykonać operacje.

Przestrzeń rezerwowaną przez system plików, możemy również ustalić na etapie formatowania partycji. Wydajemy wtedy polecenie np. mkfs.ext4 -m 0 /dev/sdb1:

[root@localhost ~]# mkfs.ext4 -m 0 /dev/sdb1 
mke2fs 1.41.12 (17-May-2010)
Etykieta systemu plików=
Typ OS: Linux
Rozmiar bloku=4096 (log=2)
Rozmiar fragmentu=4096 (log=2)
Stride=0 bloków, szerokość Stripe=0 bloków
6553600 i-węzłów, 26214392 bloków
0 bloków (0.00%) zarezerwowanych dla superużytkownika
Pierwszy blok danych=0
Maksymalna liczba bloków systemu plików=0
800 grup bloków
32768 bloków w grupie, 32768 fragmentów w grupie
8192 i-węzłów w grupie
Kopie zapasowe superbloku zapisane w blokach: 
        32768, 98304, 163840, 229376, 294912, 819200, 884736, 1605632, 2654208, 
        4096000, 7962624, 11239424, 20480000, 23887872

Zapis tablicy i-węzłów: zakończono                      
Tworzenie kroniki (32768 bloków): wykonano
Zapis superbloków i podsumowania systemu plików: wykonano

Ten system plików będzie automatycznie sprawdzany co każde 20 montowań
lub co 180 dni, zależnie co nastąpi pierwsze. Można to zmienić poprzez
tune2fs -c lub -i.

Gigabajty piechotą nie chodzą i czasem te 5% to naprawdę dużo. Warto pomyśleć o dodatkowej przestrzeni, zwłaszcza na komputerach domowych.

przez -
3 2426

Wolne miejsce na dysku lubi bardzo często się kurczyć. Nieważne jak duży dysk posiadasz, w pewnym momencie zacznie Ci brakować miejsca na dysku. Logi serwera zaczynasz rotować, pakujesz je a w ostateczności kasujesz bardzo stare pliki. Mimo wielkiego wysiłku miejsce zaczyna ubywać coraz szybciej. Zajętość partycji z logami zaczyna zbliżać się do 100%! Pojawia się problem, gdyż sumaryczna wielkość plików jest zdecydowanie mniejsza od tego co pokazuje zajętość dysku. Czary czy jakiś poważny błąd systemowy?

Aby zobrazować problem, wykonamy symulację takiej sytuacji. W pierwszym kroku sprawdzamy wielkość partycji, na której zacznie ubywać nam miejsce:

[root@seiken ~]# df -h
Filesystem            Size  Used Avail Use% Mounted on
/dev/mapper/vg_seiken-lvol00
                      5.0G  2.0G  2.9G  41% /
tmpfs                 250M  112K  249M   1% /dev/shm
/dev/sda1              97M   39M   54M  42% /boot
/dev/mapper/vg_seiken-lvol01
                     1008M   50M  907M   6% /home
<strong>/dev/mapper/vg_seiken-lvol02
                     1008M  133M  825M  14% /var</strong>

W tym przypadku będzie to katalog /var. Ponieważ partycja jest prawie pusta, stworzymy w niej duży plik, aby ją troszkę zapchać. Do tego celu wykorzystamy następujące polecenie:

[root@seiken httpd]# dd if=/dev/zero of=/var/log/httpd/access_log bs=1024 count=802400
802400+0 records in
802400+0 records out
821657600 bytes (822 MB) copied, 4.76944 s, 172 MB/s

Stworzyliśmy plik access_log wypełniony zerami. Użycie dysku wzrosło nam do 96%. Teraz uruchamiamy serwer Apache HTTP, którego logi zaczną zapychać nam system plików. Prostym skryptem będziemy wywoływać stronę główną naszego serwera.

#!/bin/bash
while true;
do
	wget -U "Mozilla/5.0 (Windows; U; Windows NT 5.1; pl; rv:1.9.2.3) Gecko/20100401 Firefox/3.6.3 ( .NET CLR 3.5.30729)" -q -O /dev/null http://127.0.0.1/
done

W ten sposób doszliśmy do momentu, w którym log serwera zaczyna szybko puchnąć. A co się stanie jeżeli go nagle skasujemy? Czy odzyskamy utracone miejsce? Sprawdźmy.

[root@seiken httpd]# df -h /var
Filesystem            Size  Used Avail Use% Mounted on
<strong>/dev/mapper/vg_seiken-lvol02
                     1008M  918M   40M  96% /var</strong>
[root@seiken /]# <strong>rm -vf /var/log/httpd/access_log</strong>
removed `/var/log/httpd/access_log'
[root@seiken /]# df -h /var
Filesystem            Size  Used Avail Use% Mounted on
<strong>/dev/mapper/vg_seiken-lvol02
                     1008M  925M   32M  97% /var</strong>
[root@seiken /]# du -hs /var/
<strong>100M    /var/</strong>

Niestety miejsca nadal ubywa! Natomiast cały katalog /var zajmuje tylko 100M. Gdzie się zatem podziała reszta? Otóż jak już wiadomo, wykonując polecenie rm nie usunęliśmy pliku, a jedynie informacje o nim.

Kiedy korzystasz z plików (czytasz lub piszesz), system operacyjny otwiera deskryptor i przypisuje go do pliku. Jest to uchwyt, do którego system sięga podczas każdej operacji. W naszym wypadku następuje ciągły zapis logów serwera do pliku. W pewnym momencie następuje usunięcie pliku. Niestety system nie zamknął deskryptora, ponieważ nie otrzymał takiego polecenie. Mimo, że pliku nie ma na dysku – deskryptor jest nadal otwarty i można z niego korzystać. Zatem zapis na dysk jest możliwy.

W takim wypadku wystarczy odszukać proces, który trzyma deskryptor i go zatrzymać. W tym wypadku jest to serwer Apache. Ale co zrobić jeżeli nie znamy procesu? Posłuży nam do tego polecenie lsof.

[root@seiken httpd]# lsof -n | grep deleted
httpd     14700      root    7w      REG      253,3 826014904       7678 /var/log/httpd/access_log (deleted)
httpd     14703    apache    7w      REG      253,3 826014904       7678 /var/log/httpd/access_log (deleted)
httpd     14704    apache    7w      REG      253,3 826014904       7678 /var/log/httpd/access_log (deleted)
httpd     14705    apache    7w      REG      253,3 826014904       7678 /var/log/httpd/access_log (deleted)
httpd     14706    apache    7w      REG      253,3 826014904       7678 /var/log/httpd/access_log (deleted)
httpd     14707    apache    7w      REG      253,3 826015272       7678 /var/log/httpd/access_log (deleted)
httpd     14708    apache    7w      REG      253,3 826015272       7678 /var/log/httpd/access_log (deleted)
httpd     14709    apache    7w      REG      253,3 826015272       7678 /var/log/httpd/access_log (deleted)
httpd     14710    apache    7w      REG      253,3 826015272       7678 /var/log/httpd/access_log (deleted)

Teraz wystarczy zatrzymać serwer Apache, aby deskryptor został zamknięty i miejsce zostało zwolnione. W przyrodzie nic nie ginie – w systemie Linux również.

przez -
5 1420
Konsola

Pracując z różnego rodzaju aplikacjami, serwerami – bardzo często mamy do czynienia z logami. Jak to zwykle z nimi bywa, potrafią urosnąć do kolosalnych wielkości, zajmując nam cenną przestrzeń dyskową. W takim wypadku czyścimy system ze zbędnych plików logów. Najczęściej po prostu kasujemy stare pliki. A co się stanie jeżeli przypadkiem usuniemy plik, do którego aplikacja aktualnie pisze? Czy dane straciliśmy bezpowrotnie? Otóż nie! Dopóki działa daemon tej aplikacji, możemy przywrócić plik.

Dla przykładu weźmiemy serwer Apache HTTP. W domyślnej konfiguracji w systemie Fedora 13 – Goddard zapisuje on pliki logów w ścieżce /var/log/httpd.

[root@seiken httpd]# ls -l
total 2528
-rw-r--r--  1 root root  326536 Jun  3 18:52 access_log
-rw-r--r--. 1 root root  553888 Jan 16 22:46 access_log-20100124
-rw-r--r--. 1 root root 1149789 Jun  3 14:14 access_log-20100603
-rw-r--r--  1 root root     324 Jun  3 14:14 error_log
-rw-r--r--. 1 root root  234778 Jan 16 22:47 error_log-20100124
-rw-r--r--. 1 root root  293605 Jun  3 14:14 error_log-20100603

Plikiem, do którego aktualnie pisze serwer jest access_log. Skasujemy go za pomocą polecenia:

[root@seiken httpd]# rm -fv access_log
removed `access_log'

Tak naprawdę polecenie rm nie usuwa pliku. Dane nie są faktycznie niszczone. Zostaje skasowana jedynie informacja, która wskazuje, gdzie dany plik jest przechowywany. Miejsce po pliku zostaje udostępnione do ponownego wykorzystania. Jeżeli serwer nasz ma mało miejsca i jest mocno obciążony, możemy być pewni, że miejsce to zaraz zostanie nadpisane i stracimy dane.

Jeżeli nie, to możemy spróbować odzyskać plik. Istnieje kilka metod odzyskania plików pod Linuksem. W tym przypadku postaramy się odbudować deskryptor pliku i uzyskać do niego dostęp.

W pierwszej kolejności szukamy numer głównego PID serwera Apache.

[root@seiken ~]# ps -efww | grep httpd
root      1198     1  0 13:20 ?        00:00:02 /usr/sbin/httpd
apache    2804  1198  0 14:14 ?        00:00:00 /usr/sbin/httpd
apache    2805  1198  0 14:14 ?        00:00:00 /usr/sbin/httpd
apache    2806  1198  0 14:14 ?        00:00:00 /usr/sbin/httpd
apache    2807  1198  0 14:14 ?        00:00:00 /usr/sbin/httpd
apache    2808  1198  0 14:14 ?        00:00:00 /usr/sbin/httpd
apache    2809  1198  0 14:14 ?        00:00:00 /usr/sbin/httpd
apache    2810  1198  0 14:14 ?        00:00:00 /usr/sbin/httpd
apache    2811  1198  0 14:14 ?        00:00:00 /usr/sbin/httpd
root     11105 11066  0 19:27 pts/3    00:00:00 grep httpd

Korzystając z systemu plików procesów możemy obejrzeć deskryptor plików dla tego procesu. Przeglądając katalog /proc/1198/fd dowiemy się jakie otwarte pliki posiada proces.

[root@seiken ~]# ls -l /proc/1198/fd
total 0
lr-x------ 1 root root 64 Jun  3 18:56 0 -> /dev/null
l-wx------ 1 root root 64 Jun  3 18:56 1 -> /dev/null
l-wx------ 1 root root 64 Jun  3 18:56 2 -> /var/log/httpd/error_log
lrwx------ 1 root root 64 Jun  3 18:56 3 -> socket:[10043]
lrwx------ 1 root root 64 Jun  3 18:56 4 -> socket:[10044]
lr-x------ 1 root root 64 Jun  3 18:56 5 -> pipe:[16756]
l-wx------ 1 root root 64 Jun  3 18:56 6 -> pipe:[16756]
l-wx------ 1 root root 64 Jun  3 18:56 7 -> /var/log/httpd/access_log (deleted)
lr-x------ 1 root root 64 Jun  3 18:56 8 -> /dev/urandom

Jak można zobaczyć, znajdują się dam dowiązania symboliczne do plików. Teraz wystarczy przepisać plik z deskryptora do pliku loga. Można do tego celu wykorzystać polecenie:

[root@seiken ~]# cat /proc/1198/fd/7 > /var/log/httpd/access_log

Plik wrócił na swoje miejsce i można znowu odczytać z niego dane.

Sprzęt, Dysk twardy

Krótki, ale mam nadzieję, że przydatny artykuł, który pomoże odzyskać stracone dane z dysków, uszkodzone tablice partycji i inne problemy. Do ratowania plików będziemy używać prostych, ale potężnych programów, które powinny być dostępne we każdej dystrybucji Linuksa. Poznamy również takie aplikacje jak TestDisk & PhotoRec, które również pomagają w odzyskiwaniu danych.

Troszkę teorii o systemie plików w Linuksie.

Najczęściej spotykanym systemem plików w systemach Linux jest system plików z serii ext (ext2 lub ext3). System plików ext2 jest tak skonstruowany, że po uszkodzeniu systemu plików np. po załamaniu się systemu, automatycznie przy starcie systemu uruchamiany jest program e2fsck, który dokonuje naprawiania szkód a uszkodzone lub odzyskane pliki zapisuje w katalogu lost+found.

Wszystkie pliki i katalogi zapisywane są na dysku jako i-węzeł (i-node), każdy odpowiada jednemu plikowi lub katalogowi. I-węzeł jest elementem struktury systemu plików ext2 i UFS. I-węzły są strukturami opisującymi pliki w systemie – wpis katalogowy danego pliku zawiera tylko jego nazwę i właśnie numer i-węzła tego pliku. I-węzeł ma zawsze tą samą długość wynoszącą 128 bajtów. Aby zobaczyć dane na temat konkretnego pliku należy wydać polecenie:

stat nazwa_pliku

Powinniśmy zobaczyć mniej więcej taki oto efekt:

[root@marta paszczak000]# stat notes
  File: `notes'
  Size: 1775            Blocks: 8          IO Block: 4096   zwykły plik
Device: 346h/838d       Inode: 81648       Links: 1
Access: (0664/-rw-rw-r--)  Uid: (  500/paszczak000)   Gid: (  500/ UNKNOWN)
Access: 2005-12-21 19:52:44.000000000 +0100
Modify: 2005-12-10 13:58:49.000000000 +0100
Change: 2005-12-10 13:58:49.000000000 +0100

Po wydaniu tego polecenia możemy zobaczyć nazwę pliku, rozmiar, i-węzeł (i-node), prawa dostępu, właściciela, oraz ostatnią datę i godzinę dostępu oraz modyfikacji pliku.

Proces kasowania plików w systemie polega na usunięciu zależności łączącej i-node z nazwą i określonym miejscem w strukturze katalogów. Plik nie zostaje fizycznie skasowany, dzięki czemu możliwe jest jego odzyskanie. Tak naprawdę pliki zostają usunięte a raczej nadpisane przy zapisie nowego pliku na jego miejsce.

Skasowało się! Co robić?

Przede wszystkim nie panikuj. Panika i emocje mogą popsuć więcej niż pomóc. Zostawmy instynkt w spokoju i nie bawmy łażeniu po dysku czy ściąganiu jakiegoś oprogramowania. Jeżeli awarii uległa znaczna część plików zalecam natychmiastowe odcięcie zasilania od komputera lub odmontowanie partycji. Nie zamykamy systemu w konwencjonalny sposób ponieważ możemy nadpisać w ten sposób stracone pliki. Wtedy nie będzie je tak łatwo odzyskać. Jeżeli skusimy się na wyłączenie komputera to dobrze by było mieć pod ręką jakąś wersję systemu Linux w formie LiveCD. Z niej uruchomimy komputer i przeprowadzimy odzyskiwanie plików. Jeżeli nie chcemy robić gwałtownego pozbawienia zasilania komputera to odmontujmy partycję, z której został skasowany plik. Najprościej odmontowywujemy partycję jako użytkownik root poleceniem: (zakładam, że pliki skasowałeś z partycji /usr)

[root@marta paszczak000]# umount /usr

W przypadku, gdy chcesz mieć nadal możliwość odczytu z tej partycji należy wydać polecenie:

[root@marta paszczak000]# mount -o ro,remount /usr

Zamontujesz w ten sposób partycję w trybie tylko do odczytu. Jeżeli chcesz odmontować partycję główną / to musisz wydać polecenie, aby mount nie próbował nic zapisywać do /etc/mtab

[root@marta paszczak000]# mount -n -o ro,remount /

Czasem się tak zdarza, że przy próbie odmontowania partycji dostajemy komunikat Resource busy. Dzieje się tak dlatego, że jakiś proces korzysta z danej partycji. Za pomocą polecenia:

[root@marta paszczak000]# fuser -v -m /home

zobaczymy jakie procesy korzystają aktualnie z /home. Jeżeli uznasz, że te procesy są zbędne to wydaj polecenie:

[root@marta paszczak000]# fuser -k -v -m /home

by wysłać do procesów sygnał SIGKILL aby w zabić ich działanie lub

[root@marta paszczak000]# fuser -k -TERM -v -m /home

by wysłać do procesów sygnał SIGTERM co spowoduje to normalne zakonczenie pracy procesów.

Zaczynamy ratować nasze dane

Jeżeli mamy odmontowaną już partycję, z której skasowaliśmy lub straciliśmy dane mamy do wyboru kilka metod odzyskiwania plików. Najprostszą metodą jest użycie programu R-Linux
Niestety do skorzystania z niego jest potrzebny nam system z serii Windows (Windows 9x/ME/NT4.0/2000/XP/2003). Program jest prosty w użyciu, zajmuje mało miejsca i bardzo dobrze odzyskuje dane. Musimy mieć inną partycję, na której będziemy zapisywać odzyskane pliki.

Kolejną prostą metodą odzyskiwania danych jest skorzystanie z dobrze każdemu znanego programu Midnight Commander. Uruchamiamy program, wciskamy [F9] by dostać się do menu. Następnie przechodzimy do menu Polecenia (Command) a potem na Odtwórz pliki (tylko ext2fs) (Undelete file (ext2fs only)).

Midnight Commander
Pojawi nam się okienko z wyborem partycji. Wpisujemy np hdb6. Podajemy samą nazwę partycji a nie jej ścieżkę. Czekamy aż program skończy ładowanie informacji o skasowanych plikach po czym w normalny sposób kopiujemy pliki w inne bezpieczne miejsce. Jeżeli nazwa pliku jest niepoprawna to zawsze możemy ją zmienić. Niestety czasami Midnight Commander nie potrafi utworzyć listy straconych plików, więc musimy posłużyć się bardziej wyszukanymi metodami.

Możemy spróbować wydać polecenie:

[root@marta paszczak000]# undelete -d /dev/hdb6

Jeżeli partycja jest odmontowana to powinny nam się zacząć pokazywać węzły i pliki jakie można odzyskać. Jeżeli nie to musimy skorzystać z innej metody.

Na początku musimy zrobić wykaz plików jakie zostały skasowane. Posłuży nam do tego polecenie:

[root@marta paszczak000]# echo lsdel | /sbin/debugfs /dev/hda5 &gt; skasowane

Jeżeli nie znamy lokalizacji naszej partycji możemy spojrzeć zawsze do /etc/fstab. Czekamy aż system przeszuka skasowane pliki a wynik zapisze do pliku skasowane. Podglądamy plik poleceniem:

[root@marta paszczak000]# less skasowane

Zobaczymy wiele cyferek i literek. Pierwsze cyferki oznaczają inode (i-węzeł) usuniętego pliku i są bardzo dla nas ważne. Następna kolumna to UID użytkownika, potem są prawa dostępu do pliku, wielkość pliku, ilość zajmowanych bloków, a na samym końcu mamy datę skasowania pliku. Czasami data przydaje się, jeżeli pamiętamy kiedy coś skasowaliśmy. Na podstawie tych danych postarajmy się odszukać interesujący nas plik po czym uruchommy program debugfs. Następnie znając inode skasowanego pliku wpisujemy:

[root@marta paszczak000]# dump <numer_inde> /home/odzyskany_plik

i możemy się cieszyć odzyskanym plikiem. Jeśli powyższe metody nadal zawodzą można spróbować skorzystać z aplikacji Recover. Program został napisany w wersji konsolowej oraz graficznej. Aplikacja automatyzuje wiele różnych procesów, które pomagają w odzyskiwaniu plików.

TestDisk & PhotoRec

TestDisk jest bardzo dobrym, całkowicie darmowym programem przeznaczonym do odzyskiwania danych na dyskach twardych. Głównym zadaniem aplikacji jest poszukiwanie zagonionych partycji. Aplikacja działa pod systemami DOS, Windows 9x, NT, 2000, XP, 2003, Linux, FreeBSD, NetBSD, OpenBSD, SunOS i Mac OS. Aplikacja potrafi odszukać zaginione partycje na następujących systemach plików:

  • BeFS ( BeOS )
  • BSD disklabel ( FreeBSD/OpenBSD/NetBSD )
  • CramFS, Compressed File System
  • DOS/Windows FAT12, FAT16 and FAT32
  • HFS, HFS+ and HFSX, Hierarchical File System
  • JFS, IBM’s Journaled File System
  • Linux Ext2 and Ext3
  • Linux LUKS encrypted partition
  • Linux Raid md 0.9/1.0/1.1/1.2
    • RAID 1: mirroring
    • RAID 4: striped array with parity device
    • RAID 5: striped array with distributed parity information
    • RAID 6: striped array with distributed dual redundancy information
  • Linux Swap (versions 1 and 2)
  • LVM and LVM2, Linux Logical Volume Manager
  • Mac partition map
  • Novell Storage Services NSS
  • NTFS ( Windows NT/2K/XP/2003/Vista )
  • ReiserFS 3.5, 3.6 and 4
  • Sun Solaris i386 disklabel
  • Unix File System UFS and UFS2 (Sun/BSD/…)
  • XFS, SGI’s Journaled File System

Do programu dołączone jest dodatkowe narzędzie PhotoRec, służące do odzyskiwania plików. Aplikacja potrafi odzyskać różnego rodzaju pliki z systemów plików takich jak FAT, EXT2, EXT3 czy NTFS.

Polecane

Jesień Linuksowa

1 1175
Polska Grupa Użytkowników Linuksa ma zaszczyt zaprosić na konferencję Jesień Linuksowa 2017, która odbędzie się w dniach 22 – 24 września 2017 roku. Jako...