Archiwa kategorii: RAID / Storage

Zmiana wielkości partycji LVM

(system plików ext4, opcja -r od razu uruchamia resize2fs)
# lvresize -L +1G -r /dev/bla/waroot
fsck z pakietu util-linux-ng 2.17.2
e2fsck 1.41.12 (17-May-2010)
/dev/mapper/bla-waroot: czysty, 11/1310720 plików, 126289/5242880 bloków
Extending logical volume waroot to 21,00 GiB
Logical volume waroot successfully resized
resize2fs 1.41.12 (17-May-2010)
Proszę uruchomić najpierw ‚e2fsck -f /dev/dm-6’.
fsadm: Resize ext4 failed
fsadm failed: 1

# e2fsck -f /dev/dm-6
e2fsck 1.41.12 (17-May-2010)
Przebieg 1: Sprawdzanie i-węzłów, bloków i rozmiarów
Przebieg 2: Sprawdzanie struktury katalogów
Przebieg 3: Sprawdzanie łączności katalogów
Przebieg 4: Sprawdzanie liczników odwołań
Przebieg 5: Sprawdzanie sumarycznych informacji o grupach
/dev/dm-6: 11/1310720 plików (0.0% nieciągłych), 126289/5242880 bloków

# resize2fs /dev/bla/waroot
resize2fs 1.41.12 (17-May-2010)
Zmiana rozmiaru systemu plików /dev/bla/waroot na 5505024 (4k) bloków.
System plików na /dev/bla/waroot ma teraz 5505024 bloków.

Jak kopiować z zachowaniem uprawnień, jak przenieść cały system?

Kopiowanie z podkatalogami:
cp -a /src/* /dst
(-a zastępuje -pRd czyli z zachowaniem uprawnień, podkatalogami, i zostawia linki symboliczne).

Można też używając rsync:
rsync -a /src/ /dst
slash po src ma znaczenie, bez niego
rsync -a /src /dst
skopiowałoby zawartość /src do /dst/src

Używając rsync można też kopiować pomiędzy zdalnymi maszynami, np.:
rsync -ave ‚ssh -p22’ –del –exclude ‚/proc’ –exclude ‚/dev’ root@host:/ /dsthost

Zatrzymuje się ładowanie systemu na Starting syslogd

Ładowanie systemu zatrzymuje się na:
Starting system log daemon: syslogd
może to oznaczać, że system plików zamontowany jest jako read-only, wtedy należy sprawdzić dlaczego tak się dzieje, co jest w pliku /etc/fstab, być może tam jest błąd? np. po zmianie systemu plików z reiserfs na ext3 należy pamiętać aby wyrzucić notail, czyli linię:
/dev/sda2 / reiserfs notail 0 1
zmienić na
/dev/sda2 / ext3 defaults 0 1

Przygotowanie płyty startowej z bootloaderem GRUB

Czasem zdarza się, że po podpięciu dysku okazuje się, że bootloader nie chce z niego wstać, np. pokazuje się:
GRUB loading, please wait...
Error 17

Można wtedy zbootować system z innego nośnika, podmontować partycję root i zainstalować na nowo gruba:
mount /dev/sda2 /mnt
chroot /mnt
grub-install /dev/sda

Bezpiecznie mieć przygotowany mośnik startowy z samym GRUBem, np. płytę CD. Przygotować możemy ją tak:
pobieramy specjalnie przygotowany plik stage2_eltorito np. stąd
Przygotowujemy iso płyty startowej.
mkdir -p iso/boot/grub
kopiujemy plik stage2_eltorit to podkatalogu grub
genisoimage -R -b boot/grub/stage2_eltorito -no-emul-boot -boot-load-size 4 -boot-info-table -o grub.iso iso
(w starszych dystrybucjach zamiast genisoimage używamy mkisofs).
Otrzymujemy wynikowy plik grub.iso (stąd możemy pobrać gotowy plik iso do nagrania na płytę

Startujemy z płyty, pojawia się znany shell gruba.

Jak sprawdzić UUID ?

UUID partycji/urządzenia można sprawdzić komendą:
ro8:~# blkid
/dev/sda1: TYPE="swap"
/dev/sda2: UUID="68ce1536-1041-4460-a9bf-0c30850ac4fe" TYPE="reiserfs"

lub

# ls -l /dev/disk/by-uuid
razem 0
lrwxrwxrwx 1 root root 10 sty 14 2011 68ce1536-1041-4460-a9bf-0c30850ac4fe -> ../../sda2

Brak wolnych inodów

Gdy na partycji znajduje się za dużo małych plików może okazać się, że brakuje wolnych inodów.

df -i
/dev/mapper/hos-news 1310720 1310518 202 100% /var/spool/news

tune2fs -l /dev/hos/news |grep Inode
Inode count: 1310720
Inodes per group: 8192
Inode blocks per group: 512
Inode size: 256

Można zmienić na system plików, który dynamicznie przydziela inody (np. raiserfs, xfs), lub ręcznie zmienić ich liczbę.
Tworząc nowy system plików można ustawić na ile bajtów partycji ma być jeden inode, np.
mkfs.ext3 -i 4096 /dev/hos/news2
powoduje stworzenie systemu plików, gdzie dla każdych 4kB jest jeden inode, czyli:
# df
/dev/mapper/hos-news2 24G 3,6G 19G 16% /var/spool/news
# df -i
/dev/mapper/hos-news2 6553600 761241 5792359 12% /var/spool/news

Odzyskiwanie usuniętych plików vfat/FAT16/FAT32 pod linuksem

W pakiecie testdisk (pod Debianem) znajduje się aplikacja odzyskująca pliki z systemu plików.
Wywołuje się podając urządzenie, które ma zostać przeszukane:
photorec /dev/sdc1
Po wywołaniu pyta gdzie ma zapisywać znalezione pliki.

Potrafi znajdować pliki na partycjach VFAT/FAT16/32, także na ext2/ext3, choć nie zawsze robi to poprawnie.

Odzyskiwanie danych

Z uszkodzonego dysku/partycji.
Nie należy pracować, montować itp. uszkodzonego dysku, pierwsze co należy zrobić, to pełną kopię uszkodzonych partycji lub dysków, np.:
dd noerror
ddrescue zrodlo cel (bez in= out=)
(próbuje kilka razy odczytać błędne sektory)

albo:
dd in=plik1 out=plik2 conv=noerror,sync

Program, który potrafi odzyskać dane z urządzenia, nawet jeśli na nim jest już inny system plików, ale nie są nadpisane wszystkie sektory:
http://foremost.sourceforge.net/

Stan dysków w macierzy sprzętowej RAID

Jak sprawdzać, czy dyski pracują w macierzy poprawnie, czy może któryś jest uszkodzony?
Jeśli to macierz Serveraid*, to ładujemy moduł mptctl i używamy programu mptstatus
# mpt-status -i 1
ioc0 vol_id 1 type IM, 2 phy, 68 GB, state OPTIMAL, flags ENABLED
ioc0 phy 0 scsi_id 1 IBM-ESXS DTN073C3UCDY10FN S27P, 68 GB, state ONLINE, flags NONE
ioc0 phy 1 scsi_id 5 IBM-ESXS DTN073C3UCDY10FN S29C, 68 GB, state ONLINE, flags NONE

Status „OPTIMAL” mówi nam, że wszystko jest ok.

Jeśli mamy macierz niekompletną i włożymy czysty dysk widzimy, że zaczyna się odbudowywać:
Sep 29 12:48:37 c1 kernel: [50303.570505] mptbase: ioc0: RAID STATUS CHANGE for PhysDisk 1 id=1
Sep 29 12:48:37 c1 kernel: [50303.570515] mptbase: ioc0: PhysDisk is now online, out of sync
Sep 29 12:48:37 c1 kernel: [50303.573240] mptbase: ioc0: RAID STATUS CHANGE for PhysDisk 1 id=1
Sep 29 12:48:37 c1 kernel: [50303.573248] mptbase: ioc0: PhysDisk is now initializing, out of sync
Sep 29 12:48:37 c1 kernel: [50303.852611] mptbase: ioc0: RAID STATUS CHANGE for PhysDisk 1 id=1
Sep 29 12:48:37 c1 kernel: [50303.852619] mptbase: ioc0: PhysDisk is now online, out of sync
Sep 29 12:48:37 c1 kernel: [50303.866114] scsi host2: mptspi: ioc0: Integrated RAID detects new device 1
Sep 29 12:48:37 c1 kernel: [50304.261578] mptbase: ioc0: RAID STATUS CHANGE for VolumeID 1
Sep 29 12:48:37 c1 kernel: [50304.261588] mptbase: ioc0: volume is now degraded, enabled, resync in progress

Odbudowa trwa jakiś czas i po nim widzimy, że:
Sep 29 23:26:34 c1 kernel: [88580.917523] mptbase: ioc0: RAID STATUS CHANGE for PhysDisk 1 id=1
Sep 29 23:26:34 c1 kernel: [88580.917533] mptbase: ioc0: PhysDisk is now online
Sep 29 23:26:34 c1 kernel: [88580.918436] mptbase: ioc0: RAID STATUS CHANGE for VolumeID 1
Sep 29 23:26:34 c1 kernel: [88580.918444] mptbase: ioc0: volume is now optimal, enabled, resync in progress
Sep 29 23:26:34 c1 kernel: [88580.921791] mptbase: ioc0: RAID STATUS CHANGE for VolumeID 1
Sep 29 23:26:34 c1 kernel: [88580.921804] mptbase: ioc0: volume is now optimal, enabled

Macierz się odbudowała. Odbudowa RAID1 2*73GB w IBM x345 trwała 10.5 godziny.

Jeśli korzystamy z cciss, korzystając z smatrctl możemy sprawdzić stan poszczególnych dysków:
smartctl -d cciss,0 -a /dev/cciss/c0d0
smartctl -d cciss,1 -a /dev/cciss/c0d0
Device: IBM-ESXS BBD073C3ESTT0ZFN Version: JP86
Serial number: K407DKQK
Device type: disk
Transport protocol: Parallel SCSI (SPI-4)
Local Time is: Thu Sep 30 00:24:47 2010 CEST
Device supports SMART and is Enabled
Temperature Warning Enabled
SMART Health Status: OK

Current Drive Temperature: 34 C
Current start stop count: 44 times
Elements in grown defect list: 0

Error counter log:
Errors Corrected by Total Correction Gigabytes Total
ECC rereads/ errors algorithm processed uncorrected
fast | delayed rewrites corrected invocations [10^9 bytes] errors
read: 590731 17 0 0 0 4913.778 0
write: 0 0 0 0 0 3478.495 0
Non-medium error count: 187
Last n error events log page
No self-tests have been logged
Long (extended) Self Test duration: 1440 seconds [24.0 minutes]