Re: Gedankenspiel neuer Server - Filesystem
Am Freitag, 28. Juni 2013, 21:13:24 schrieb Dirk Salva:
> Hi Leute,
Hi Dirk,
> ich will mir einen neuen Heimserver aufsetzen. Gedacht ist momentan:
> SoftRAID-1 auf 3TB Toshiba mit zwei md-Devices. md0 bekommt ein
Warum Toshiba?
> Wartungssystem, falls mal ein filesystem-check notwendig ist oder ein
> sonstiges Problem auftritt, md1 wird das Produktivsystem mit System und
> Daten. So kann ein stromfressendes CD-Laufwerk eingespart werden. Eine
> weitere Partitionierungs-Unterteilung ist nicht vorgesehen, ich kann im
> praktischen Heimserver-Betrieb keine Vorteile erkennen.
Ich würde immer LVM nehmen.
In Bezug auf BTRFS dann eben kein SoftRAID, auch wenn SUSE offiziell BTRFS für /
nur mit SoftRAID unterstützt (siehe meine Erfahrungen mit BTRFS RAID 1 unten).
> Der bisherige Heimserver läuft auf XFS, damit bin ich nicht so ganz
> zufrieden, was Konsistenz bei Systemhängern betrifft.
Ich habe das /-Dateisystem auf meiner Workstation auf der Arbeit auf XFS mit
SoftRAID 1. Damit habe ich seit der Installation nicht ein einziges Problem
mit Hängern oder Inkonsistenzen gehabt.
Ich habe mit XFS seit 2.6.16 keine Probleme mehr gehabt. Ich setze es aber
auch nicht mehr so häufig sein wie früher.
> Deshalb denke ich
> über ein anderes FS nach. Gestoßen bin ich u.a. auch auf BTRFS.
> Faszinierend finde ich, dass dieses auch gleich Verwaltung und Nutzung
> eines RAID-1 anbietet, was z.B. bei einem RAID-rebuild den Vorteil hat,
> dass nur wirklich genutzte Bereiche bearbeitet werden, was heutzutage
> auch Zeit spart. Was ist davon zu halten? Ist BTRFS in Wheezy stabil
> genug für den Produktivbetrieb in der von mir beschriebenen Umgebung?
> Wird es überhaupt bei der Installation angeboten?
Ich hab auf der Workstation auf meiner Arbeit seit mehr als einem Jahr, ich
denke mehr als zwei Jahren ein BTRFS RAID 1. Das läuft. Das letzte Scrubbing
initierte ich glaube ich vor einem Monat etwa, und das lief sauber durch.
Das ist auch mit ein Grund, warum ich BTRFS mittlerweile seit Monaten / Jahren
als Wurzel- und Home-Dateisystem auf einem ThinkPad T520 mit SSD einsetze und
auf allen meinen Backup-Platten. Denn ich kann mir – auch vor einem etwaigen
Backup – bestätigen lassen: Die Daten sind okay (oder eben nicht):
merkaba:~> btrfs scrub status /
scrub status for […]
scrub started at Sat Jun 22 10:55:49 2013 and finished after 49 seconds
total bytes scrubbed: 11.02GB with 0 errors
Selbst auf dem Laptop von meinem Vater hab ich alles außer /boot als BTRFS.
Weil ich dann da auch schrubben kann. Zudem zeichnet BTRFS auch die Anzahl von
Fehlern auf:
merkaba:~> btrfs device stats /
[/dev/mapper/merkaba-debian].write_io_errs 0
[/dev/mapper/merkaba-debian].read_io_errs 0
[/dev/mapper/merkaba-debian].flush_io_errs 0
[/dev/mapper/merkaba-debian].corruption_errs 0
[/dev/mapper/merkaba-debian].generation_errs 0
ist doch eine beruhigende Aussage.
Ein weiterer Grund gerade für die Backup-Platten ist die Snapshot-Fähigkeit.
Auf dem Laptop verwende ich das nur rudimentär, es fehlt noch eine schöne
Userspace-Komponente, die das Erstellen und Löschen von Snapschüssen
automatisiert.
Auf dem T520 lief mal das Scrub vom /-Dateisystem nicht gescheit durch. Ein
Backup via rsync zeigte jedoch keine I/O-Fehler. Und fsck.btrfs war auch
zufrieden. Wahrscheinlich war das ein Kernel-Problem im Scrub-Code. Ich hab
das BTRFS nach einer Weile dann neu gemacht, weil ich wieder schrubben wollte.
Ich hab das alte Image noch da, habe aber noch nicht versucht, es mit einem
neueren Kernel zu schrubben.
Okay und jetzt zusammenfassend meine Empfehlungen:
1) Nimm vor allem für größere Datenbanken auf rotierenden Datenträgern ein
anderes Dateisystem. Ich empfehle XFS oder Ext4. Warum? BTRFS fragmentiert,
indem es neue Daten immer an einen neuen Ort schreibt (COW – Copy On Write),
die Datenbank-Dateien erheblich. Auch die Mount-Option autodefrag kann das
meines Wissens bislang nicht vollständig ausgleichen. Auf einer SSD macht das
wenig aus.
2) Sei bereit, den 3.2er-Kernel in Wheezy zu aktualisieren. Entweder durch
etwaige Backport-Pakete oder auf eigene Faust. Auch wenn SUSE für SLES 11 SP 2
mit Kernel 3.0 BTRFS als Root-Dateisystem unterstützt, bin ich weiterhin der
Meinung, dass es sinnvoll ist, den Kernel-Versionen zu folgen, da die
Entwickler immer wieder auch Bugs fixen, die einen betreffen können. Und auch
die Performance steigern. Falls ein Fehler auftritt, den Du den Kernel-
Entwickler berichtest, und Dein Kernel nicht aktuell ist, bekommst Du als
ersten Hinweis, es mit einem aktuellen Kernel zu versuchen.
Ich denke 3.2 ist ein ganz guter Stand, aber BTRFS ist immer noch als
experimentiell markiert und ich halte für sinnvoll, den Kernel-Versionen
zumindest in unregelmäßigen Abständen zu folgen.
3) Falls Du BTRFS für / einsetzen möchtest,
a) nimm ein ein /boot auf Ext4 oder so. Ich glaube zwar, dass GRUB 2 auch ein
BTRFS RAID 1 unterstützt, aber gesehen habe ich das noch nicht. Oder teste es
halt vorher, ich bin bei der Partition für /boot jedoch lieber etwas
konservativer. Und 200-500 MB dafür zu reservieren ist bei aktuellen
Datenträger-Größen auch kein Problem.
b) prüfe, ob die Initial Ramdisk von Wheezy das wirklich frisst. Auf meiner
Workstation auf der Arbeit hat das System das BTRFS RAID 1 lange Zeit nicht
automatisch eingebunden, da ein Aufruf von "btrfs device scan" fehlte. Das
geht mittlerweile. Ich habe jedoch teilweise neuere Pakete als Wheezy. Ich
vermute, es geht in Wheezy, ich würde es aber testen.
4) Informiere Dich eingehend. Vorher oder sei zumindest bereit, Dich zu
informieren. Bei BTRFS ist Einiges doch etwas anders als mit den Dir bekannten
Dateisystemen. So ist die Angabe des freien Speicherplatzes bei df bestenfalls
als Schätzwert. Und ein BTRFS RAID 1 funktioniert auch anders als ein SoftRAID
1.
5) Auch wenn sowohl SUSE teilweise, als auch Oracle für Unbreakable Linux –
ganz oder teilweise, das weiß ich nicht – BTRFS unterstützen: Im Kernel und in
mkfs.btrfs ist es immer noch als „experimentell“ gekennzeichnet. Sei also
bereit, ggf. auch mal ein Problemchen zu recherchieren, zu fixen. Das muss kein
Datenverlust sein, kann aber was sein, wie Dateisystem sagt, es ist voll,
während noch Platz drauf ist oder Dateisystem wird sehr langsam usw. usf.
Echte Datenverluste halte ich mittlerweile für ziemlich unwahrscheinlich, ein
Backup ist jedoch immer Pflicht.
Falls Du Dich entscheidest, BTRFS einzusetzen, kann ich was die Einrichtung
von Subvolumes und passende mkfs- und mount-Optionen angeht, noch weitere
Hinweise geben.
> P.S.: eine kurze Suche hat u.a. diesen Artikel aus 2009 gefunden:
> Das ist vier Jahre her, da sollte sich ja mittlerweile einiges zum
> Positiven entwickelt haben...
> http://www.admin-magazin.de/Das-Heft/2009/04/Das-neue-Linux-Dateisystem-Btrf
> s-im-Detail
Ein Artikel von 2009 gibt keine Hilfe dabei, einzuschätzen, wo BTRFS in 2013
ist. Selbst 3 Monate vor und zurück sind immer noch lang.
Ich hab den Artikel dementsprechend jetzt auch einfach mal gar nicht gelesen.
Wenn Du da eine spezielle Frage zu hast, formuliere sie bitte hier aus.
Ciao,
--
Martin 'Helios' Steigerwald - http://www.Lichtvoll.de
GPG: 03B0 0D6C 0040 0710 4AFA B82F 991B EAAC A599 84C7
Reply to: