Inodes-Verbrauch anzeigen:
# df -i
| Dateisystem | maximale Dateigröße | maximale Dateisystemgröße |
|---|---|---|
| Ext4 | 16 TByte | 1024 PByte |
| Ext3 | 2 TByte | 16 TByte |
| JFS | 4 PByte | 32 PByte |
| ReiserFS 3 | 8 TByte | 16 TByte |
| XFS | 8192 PByte | 8192 PByte |
| ZFS (Solaris) | 16.384 PByte | 16.384 PByte |
Thomas Krenn: FSCK Best Practices
auf einem ext*-Dateisystem kann man einen Dateisystem-Check nach einer bestimmten Zeit bzw. nach einer bestimmten Anzahl an mounts erzwingen; in diesem Beispiel alle 20 Mounts bzw. alle 30 Tage:
> tune2fs -c 20 -i 30d /dev/sda1
in der /etc/fstab kann man das Verhalten von fsck in der 6. Spalte (letzte Spalte in der Datei) festlegen:
/automatisches reparieren vor dem Mount, wenn Fehler erkannt werden (beim nächsten Reboot):
> touch /forcefsck
für mehr Infos:
> vi /etc/default/grub ... GRUB_CMDLINE_LINUX_DEFAULT="--verbose" ...
oder
> vi /etc/init/mountall.conf ... exec mountall --daemon $force_fsck $fsck_fix $debug_arg --verbose ...
Die folgende Option bewirkt beim Auftreten von Fehlern ein Auto-Repair. (Nicht in jeder Situation ist ein automatisches Reparieren von Fehlern gewünscht und sinnvoll!):
> vi /etc/default/rcS ... FSCKFIX=yes ...
Standard-Einstellungen für neue Dateisysteme
> vi /etc/mke2fs.conf
...
[defaults]
[defaults]
base_features = sparse_super,filetype,resize_inode,dir_index,ext_attr
default_mntopts = acl,user_xattr
enable_periodic_fsck = 1 base_features = sparse_super,filetype,resize_inode,dir_index,ext_attr
default_mntopts = acl,user_xattr
enable_periodic_fsck = 1
...
Der Sinn eines Cluster-Dateisystems ist es, die Zugriffe auf ein Storage Area Network zu regeln, da es zu einem Desaster käme, wenn A und B gleichzeitig die gleiche Datei im Storage Area Network schreiben würden. Nicht mehr und nicht weniger.
Generell wird zwischen den Architekturen shared nothing und shared all unterschieden.
Typischer Vertreter des active-active-Clusters mit shared-nothing-Architektur ist DB2 mit EEE (gesprochen „triple e“). Hier beherbergt jeder Clusterknoten eine eigene Datenpartition. Ein Leistungsgewinn wird durch die Partitionierung der Daten und die damit einhergehende verteilte Verarbeitung erzielt. Ausfallsicherheit wird hiermit nicht gewährleistet.
Anders ist dies beim shared-all-Cluster. Diese Architektur gewährleistet durch einen konkurrierenden Zugriff auf Shared Storage, dass alle Clusterknoten auf den gesamten Datenbestand zugreifen können. Neben Skalierung und Leistungssteigerung wird durch diese Architektur auch eine zusätzliche Ausfallsicherheit erreicht. Fällt ein Knoten aus, übernehmen die anderen Knoten seine Aufgabe(n). Ein typischer Vertreter der shared-all-Architektur ist der Oracle Real Application Cluster (RAC).
Um die Konsistenz der Daten sicherzustellen, müssen die Verwaltungsdaten, d. h. Verzeichnisse, Attribute und Speicherplatzzuweisungen (Metadaten), koordiniert gespeichert werden. Hierzu wird üblicherweise ein Metadaten-Server eingesetzt, der all diese Daten von den verschiedenen Teilnehmern am Cluster-Dateisystem übermittelt bekommt, üblicherweise über ein Ethernet. Dieser übernimmt auch die Koordinierung der Caches und der Dateisperren (Locks). In manchen Cluster-Dateisystemen kann der Metadaten-Server auch andere Aufgaben übernehmen, bei anderen (CXFS) müssen ein oder mehrere dedizierte Metadatenserver eingesetzt werden um die Betriebssicherheit zu erhöhen.
Gelingt den Servern aufgrund einer Störung im Netzwerk die Synchronisation nicht, so besteht die Gefahr von Inkonsistenzen. Üblicherweise wird das betroffene Dateisystem sich dann auf all jenen Servern herunterfahren, die (sich selbst eingerechnet) nur noch maximal 50 % der Gesamtheit an Servern sehen können. Da es nur maximal eine Gruppe geben kann, die mehr als 50 % der Server umfasst, bleibt nur diese aktiv, es können keine Inkonsistenzen entstehen. Man sagt auch, das Quorum liegt bei über 50 %.
Aus meinen Testerfahrungen kommen folgende Clusterfilesysteme für mich in Frage:
XtreemFS weist seit der Version 1.3 eine sehr hohe Ausfallsicherheit auf, da es keinen single point of failure mehr besitzt. GlusterFS kann man direkt über das Ubuntu-Repository (mit allen Sicherheitsupdates) beziehen. Aber auch für XtreemFS gibt es Debian-Pakete auf dem XtreemFS-Server, die von Ubuntu installiert werden können.
XtreemFS besitzt in der Version 1.3 etwas mehr nützliche Funktionen und ist auch etwas flexibler als GlusterFS. Weiterhin ist GlusterFS weniger ambitioniert als XtreemFS, selbst Ceph ist stärker ambitioniert als GlusterFS.
XtreemFS auch mit dem Ziel entwickelt worden, Clusterknoten über das Internet anzubinden. GlusterFS kommt mit langsameren Verbindungen als 100Mbit zwischen den Clusterknoten nicht so gut zurecht.
Beide, GlusterFS und XtreemFS, besitzen aber auch eine Schwäche! Beide Clients laufen im FUSE-Mode, dadurch wird die Bandbreite eingeschränkt, und nur XtreemFS besitzt die Fähigkeit mehrere Verbindungen gleichzeitig zu öffnen um diese Schwäche auszugleichen!
# pkg search -o GlusterFS net/glusterfs GlusterFS distributed file system
# pkg search -o Ceph net/ceph12 Ceph delivers object, block, and file storage in a unified system net/ceph13 Ceph delivers object, block, and file storage in a unified system math/p5-Math-Cephes Perl interface to the cephes math library
# pkg search -o MooseFS sysutils/moosefs2-cgi MooseFS CGI interface sysutils/moosefs2-cgiserv MooseFS CGI webserver sysutils/moosefs2-chunkserver MooseFS data storage and synchronization component sysutils/moosefs2-cli MooseFS command line interface sysutils/moosefs2-client MooseFS client tools sysutils/moosefs2-master Fault-tolerant distributed filesystem sysutils/moosefs2-metalogger MooseFS metadata backup server sysutils/moosefs2-netdump MooseFS network packet dump utility sysutils/moosefs3-cgi MooseFS CGI interface sysutils/moosefs3-cgiserv MooseFS CGI webserver sysutils/moosefs3-chunkserver MooseFS data storage and synchronization component sysutils/moosefs3-cli MooseFS command line interface sysutils/moosefs3-client MooseFS client tools sysutils/moosefs3-master Fault-tolerant distributed filesystem sysutils/moosefs3-metalogger MooseFS metadata backup server sysutils/moosefs3-netdump MooseFS network packet dump utility
# pkg search -o LizardFS sysutils/lizardfs Open Source Distribruted Filesystem
root@testhost:~# time fsck -fy /dev/data/fscktest fsck from util-linux-ng 2.17.2 e2fsck 1.41.11 (14-Mar-2010) Durchgang 1: Prüfe Inodes, Blocks, und Größen Durchgang 2: Prüfe Verzeichnis Struktur Durchgang 3: Prüfe Verzeichnis Verknüpfungen Durchgang 4: Überprüfe die Referenzzähler Durchgang 5: Überprüfe Gruppe Zusammenfassung /dev/mapper/data-fscktest: 4505814/6553600 Dateien (0.1% nicht zusammenhängend), 8143555/26214400 Blöcke real 4m17.636s user 0m11.950s sys 0m14.080s
root@testhost:~# time fsck -fy /dev/data/fscktest fsck from util-linux-ng 2.17.2 e2fsck 1.41.11 (14-Mar-2010) Durchgang 1: Prüfe Inodes, Blocks, und Größen Durchgang 2: Prüfe Verzeichnis Struktur Durchgang 3: Prüfe Verzeichnis Verknüpfungen Durchgang 4: Überprüfe die Referenzzähler Durchgang 5: Überprüfe Gruppe Zusammenfassung /dev/mapper/data-fscktest: 4505814/6553600 Dateien (0.0% nicht zusammenhängend), 8093411/26214400 Blöcke real 0m31.204s user 0m10.980s sys 0m6.480s
root@testhost:~# time fsck -fy /dev/data/fscktest
fsck from util-linux-ng 2.17.2
fsck.jfs version 1.1.12, 24-Aug-2007
processing started: 11/9/2010 17.11.30
The current device is: /dev/mapper/data-fscktest
Block size in bytes: 4096
Filesystem size in blocks: 26214400
**Phase 0 - Replay Journal Log
**Phase 1 - Check Blocks, Files/Directories, and Directory Entries
**Phase 2 - Count links
**Phase 3 - Duplicate Block Rescan and Directory Connectedness
**Phase 4 - Report Problems
**Phase 5 - Check Connectivity
**Phase 6 - Perform Approved Corrections
**Phase 7 - Rebuild File/Directory Allocation Maps
**Phase 8 - Rebuild Disk Allocation Maps
104857600 kilobytes total disk space.
982634 kilobytes in 706044 directories.
29243900 kilobytes in 3479480 user files.
0 kilobytes in extended attributes
2186738 kilobytes reserved for system use.
74409596 kilobytes are available for use.
Filesystem is clean.
.....|...
real 3m3.351s
user 0m4.700s
sys 0m11.470s
Eigentlich sollte fsck ja reichen… aber leider erkennt es im Einzelfall nicht das richtige Dateisystem und versucht ein ext4 als ext3 anzusprechen und manchmal möchte man, das auch ein "sauberes" Dateisystem überprüft wird…
Deshalb habe ich dieses Script geschrieben, damit wird garantiert jedes Dateisystem richtig angesprochen und auch in jedem Fall überprüft.
#!/bin/bash
if [ -n "${1}" ] ; then
blkid ${1} | while read MDEV IDS;
do
FST="$(echo "${IDS}" | tr -s ' ' '\n' | egrep '^TYPE=' | awk -F'=' '{gsub("\"",""); print $2}';)";
MDEV="$(echo "${MDEV}"|tr -d ':')";
if [ "${FST}" != "swap" ] ; then
fsck -t ${FST} -f -y ${MDEV};
fi;
done
else
echo "${0} [Laufwerksdatei]"
fi
* app-forensics/magicrescue
Latest version available: 1.1.4-r1
Latest version installed: [ Not Installed ]
Size of files: 87 kB
Homepage: http://jbj.rapanden.dk/magicrescue/
Description: Find deleted files in block devices
License: GPL-2
* sys-fs/dd-rescue
Latest version available: 1.10
Latest version installed: [ Not Installed ]
Size of files: 16 kB
Homepage: http://www.garloff.de/kurt/linux/ddrescue/
Description: similar to dd but can copy from source with errors
License: GPL-2
* sys-fs/ddrescue
Latest version available: 1.8
Latest version installed: [ Not Installed ]
Size of files: 41 kB
Homepage: http://www.gnu.org/software/ddrescue/ddrescue.html
Description: Copies data from one file or block device (hard disk, cdrom, etc) to another, trying hard to rescue data in case of read errors
License: GPL-2
ein neues Volumen im Ceph erstellen:
> rbd -c /etc/ceph/ceph.conf --id bigssd --keyfile /etc/ceph/client.bigssd.key --keyring /etc/ceph/client.bigssd.keyring -p bigssd -s 50000 create mysql01
wenn die Version vom Ceph aktueller ist als die Client-Software, dann muss man ggf. Funktionen abschalten:
> rbd -c /etc/ceph/ceph.conf --id bigssd --keyfile /etc/ceph/client.bigssd.key --keyring /etc/ceph/client.bigssd.keyring -p bigssd feature disable mysql01 exclusive-lock object-map fast-diff deep-flatten
das neue Ceph-Volumen mappen, damit wir eine Gerätedatei bekommen
> rbd -c /etc/ceph/ceph.conf --id bigssd --keyfile /etc/ceph/client.bigssd.key --keyring /etc/ceph/client.bigssd.keyring -p bigssd map mysql01
wenn das Volumen nicht mehr benötigt wird, dann trennen wir das Mapping zum Ceph wieder:
> rbd -c /etc/ceph/ceph.conf --id bigssd --keyfile /etc/ceph/client.bigssd.key --keyring /etc/ceph/client.bigssd.keyring -p bigssd unmap mysql01