seletenere oder schnellere fsck's ?

Ad 1: das musst Du entscheiden. Mit tune2fs kannst Du Dir's anpassen.
Ad 2: oh, ja. Ich bin inzwischen bei xfs gelandet. (btrfs hat sich super angehoert, ist aber all' hui stehengeblieben (jedenfalls vor ca. 6-12 Monaten). Das dauert, bis ich das wieder fuer ein Produktivsystem ausprobieren werde)
Ad 3: keine Ahnung. Vermutlich nicht (es sei denn, der macht nur JBOD)
Preise steigen leider nicht linear mit der Anzahl Ports. Vermutlich ist ein zusaetzlicher Controller guenstiger - falls der Preis eine Rolle spielt.

ob 3MB oder 3GB, das ist egal. Klein gelten m.E. nach wie vor Dateien mit einer Groesse unter Blocksize.

Die Frage ist, ob nicht RAID5/RAID6 bei der Anzahl an Platten sinnvoller waere.

uwe

Zitat

Original von magicamun
2. Kann man den fsck auch beschleunigen durch z.B. ein anderes FS?
...
Welche Filesysteme empfehlt ihr (Stabil, Schnell sind die kriterien)?

Ich benutze ebenfalls XFS für meine Videopartition und bin sehr zufrieden damit. Nie wieder fsck.

Allerdings hatte ich anfangs einige Probleme mit übermäßiger Fragementierung. Das ging sogar soweit, dass es teilweise Minuten gedauert hat, eine einzige Datei zu löschen (die aus zigtausenden Fragementen bestand). Mittlerweile habe ich das aber im Griff:

• Über einen cronjob wird regelmäßig xfs_fsr ausgeführt.
• Ich habe VDR selber kompiliert und zwar mit einer Änderung: In recording.c habe ich MINDISKSPACE deutlich erhöht (bei mir auf 100GB bei 4TB insgesamt). Dadurch hat XFS mehr Spielraum und arbeitet nicht ständig an der Belastungsgrenze. (Vielleicht gibt's mittlerweile auch eine Befehlszeilenoption für diese Einstellung. Ich habe damals jedenfalls keine gefunden.)
• Beim Mounten verwende ich die folgenden Optionen: relatime,allocsize=256m,logbufs=8,logbsize=256k
• Die Größe der Videodateien habe ich auf 255MB beschränkt (1MB kleiner als allocsize).

Seitdem hatte ich nie wieder Probleme mit der Videopartition. Absolut wartungsfrei.
(Abgesehen vielleicht von einer kaputten Festplatte, aber dafür kann XFS ja nichts. ;))

interessantes Thema.

ext3 auf HomeFileServer gehört eigtl. verboten

XFS hab ich bisher für video.0x des VDR benutzt. Ich war am Überlegen für 6TB raid btrfs zu probieren, da ich mehrere Aussagen gehört hatte btrfs schon sehr stable, xfs ... Meine Erfahrung mit xfs ist 100% problemfrei in 4-5 Jahren. btrfs hat eingebaute snapshot Funktion und online fsck, das klingt schon super.

tag, deine Optionen muss ich mir mal anschauen, was sie tun.

Zitat

Wo speichert der Controller denn die Konfiguration der Raids ab?

Meines Wissens auf den Platten (so ist es bei meinen Controllern (Areca/HP): ohne Platten haben die keine Ahnung mehr ueber die Partitionierung).
Soweit ich weiss werden dazu die ersten/letzten Sektor(en) verwendet).

Diese Informationen sind aber der Punkt, bei dem jeder Hersteller sein eigenes Sueppchen kocht.

uwe

Zitat

btrfs hat eingebaute snapshot Funktion und online fsck, das klingt schon super.

Ja, fand ich auch. Und habe 3 Monate die Fehler gesucht (war mit dem 2.6.33 damals). 12TB oder 300 rsnapshots eines Produktionssystems mit Hardlinks waren wohl etwas zu heftig.
Beim Loeschen/Speichern/Kopieren hat sich das Filesystem bis zu 3 Minuten weggehaengt und anschliessend ro gemountet (ich konnte die Partition dann zwar wieder korrigieren, aber es blieb nach jedem Haenger ein weiterer Core voll ausgelastet (X4 600e)).
Zuerst dachte ich an Hardwareprobleme mit dem P400. Komischerweise hatten aber beide Treiber (cciss/hpsa) das gleiche Problem.
Seit dem Umstieg auf xfs gibt's 0,garkeine Probleme mehr. Laeuft einfach.

uwe

2 Leute 3 Meinungen .. gerade die Tage ne Diskussion geführt ..

(05:55:18 PM) steffen_b: " XFS is a journaling filesystem and performs recovery at mount(8) time if necessary, so fsck.xfs simply exits with a zero exit status. "
(05:55:58 PM) XXX: heh, XFS doesn't perform recovery
(05:56:15 PM) XXX: XFS abandons your data on a remote tropical island without so much a bottle of rum
..
(06:00:51 PM) steffen_b: not sure if btrfs is mature enough allready
(06:02:21 PM) XXX: it's at least as mature as ext4
(06:02:55 PM) XXX: the only reason Ubuntu hasn't switched, at least for netbooks or desktops, is that there's still a licensing issue with the boot loader
(06:03:03 PM) XXX: the btrfs code, being kernel, is GPL 2 only
(06:03:08 PM) XXX: the boot loader (GRUB 2) is GPL 3+

Aber evtl kamen da in letzter Zeit Fixes dazu bei den neueren Kerneln (2.6.37 ??)

magicamun

Ich pflichte den positiven Meinung zu XFS uneingeschränkt bei. XFS ist das älteste "Journaling Filesystem" der IT-Geschichte und geht auf SGI in den 1980er Jahren zurück. Das zweitälteste ist JFS, welches auf IBM ebenfalls in den 1980er Jahren zurückgeht und ebenso ausgereift ist.

Ext2/3 sind auch ausgreift, aber eben in jeder Beziehung super langsam. Die Ext4-Welt ist sehr arrogant überzeugt von Ext4, aber tatsächlich ist gerade mal so gleich schnell in Benchmarks verglichen zu XFS, das gefühlte 100 Jahre älter ist ...

Die quasi eingebauten Backup/Restore Tools xfsdump/xfsrestore sind hilfreich. Damit habe ich z.B. in einem früheren Leben viele, viele SGI Maschinen geclont ...

[OT]

Ich nutze folgende Mount-Optionen für das Video-Verzeichnis:

defaults,noatime,nodiratime,logbsize=256k,logbufs=8,osyncisosync

• noatime/nodiratime - Im Normalfall benötigt niemand die letzte Zugriffszeit von Dateien und Verzeichnissen, schon gar nicht im Video-Verzeichnis. Also kann man sich die unnötigen Zugriffe bzw. I/O Cycles sparen, zumal der VDR die Aufnahmedaten in der Struktur anlegt
  => beide Optionen waren aber bis 2.6.18 fehlerhaft im Kernel implementiert
• logbsize=256k - Ist eine alte immer wiederkehrende Empfehlung, die auf SGI zurückgeht, verbessert messbar die Performance über alles, aber vorallem beim Löschen. Nur die Werte werden im Laufe der Jahre immer höher, weil die Maschinen immer mehr Speicher haben
• logbufs=8 - ditto, die Empfehlung "8" ist aber seit Jahren gleich und soweit ich mich erinnere ab Kernel 2.6.36 eben mit dem Wert "8" default
• osyncisosync - Alter Parameter zur Absicherung der Timestamps im Falle eines Absturzes, ist ebenfalls ab Kernel 2.6.36 default

Das Filesystem sollte natürlich mit "version=2" & "lazy-count=1" angelegt werden, was bei aktuellen Installationen default ist. Sollte jemand eine altes Filesystem mit xfsdump/xfsrestore übernommen habe, lassen sie diese Werte mit "xfs_admin -j -c 1 /dev/sdaX" anpassen. Abfrage mit xfs_info:

#/> xfs_info /var/lib/video.00


Metadaten =/dev/sda2              isize=256    agcount=4, agsize=29913728 blks
          =                       sectsz=512   attr=2
Daten     =                       bsize=4096   Blöcke=119654912, imaxpct=25
          =                       sunit=0      swidth=0 blks
Benennung =Version 2              bsize=4096   ascii-ci=0
Protokoll =Intern                 bsize=4096   Blöcke=58425, Version=2
          =                       sectsz=512   sunit=0 blks, lazy-count=1
Echtzeit  =keine                  extsz=4096   Blöcke=0, rtextents=0

Die Mountoption "async" kann die Performance ebenfalls nochmals deutlich verbessern. Bitte nur nutzen/konfigurieren, wenn die Maschine mit einer USV abgesichert ist!!!

[EDIT] Ganz vergessen, gilt auch für die "nobarrier" Mount-Option, gut, aber nur mit USV!! [/EDIT]

Zum Nachlesen einiger Optionen: Deutschsprachige Lektüre, z.B. bzgl. der quota Optionen.

Der Parameter "allocsize" verbessert das Verhalten bei Fragmentierung. Ein XFS Filesystem fragmentiert aber erst ab 85% Füllgrad und bei den riesigen Video-Dateien eines VDRs, wird man von Fragmentierung auch über 85% eher nicht soviel wahrnehmen bzw. messen können. Daher gewinnt man wenig bis nichts, verliert aber auch wenig bis nichts, außer etwas Hauptspeicher.

[/OT]

Regards
fnu

Zitat

Original von magicamun

müsste doch über quotas auch gehen oder?

Ich weiß nicht genau, wie VDR den freien Speicher berechnet. Käme auf einen Versuch an. Eleganter, als im Quelltext rumzupfuschen, wäre es allemal.

Zitat

Original von fnu
lazy-count=1

Kannte ich noch gar nicht. Danke für den Tipp.

Zitat

Original von fnu
Ein XFS Filesystem fragmentiert aber erst ab 85% Füllgrad und bei den riesigen Video-Dateien eines VDRs, wird man von Fragmentierung auch über 85% eher nicht soviel wahrnehmen bzw. messen können.

Ooooh doch. VDR lässt standardmäßig nur 1GB frei. Bei (in meinem Fall damals) 1TB Gesamtvolumen war der Füllgrad dementsprechend konstant bei 99,9%. Erschwerend kam hinzu, dass oft mehrere Sendungen gleichzeitig aufgenommen wurden. Da meine Aufnahmen in der Regel größer als 1GB sind, musste zwangsläufig fragmentiert werden. Nach einem halben Jahr war dann Schluss mit lustig:

# xfs_db -r /dev/sda1 -c frag
actual 1349956, ideal 1407, fragmentation factor 99.90%

Durchschnittlich ergibt das nur ein paar huntert Kilobytes pro Fragment. Kurzgesagt: Das Dateisystem lief in Zeitlupe. Da half nur noch eine radikale Löschkur gefolgt von ein paar Tagen xfs_fsr.

15% freizulassen, um Fragmentierung ganz zu vermeiden, wäre mir zu viel Platzverschwendung. Andererseits ist die vom VDR vorgegebene Grenze von 1GB genauso, ähm, suboptimal. Ich habe jedenfalls mit den oben genannten Werten einen Kompromiss gefunden, der für mich ganz gut funktioniert.

tag

Ok, danke für die Erläuterung.

Den Füllgrad 99% habe ich nur in seltenen Fällen und dann merke ich natürlich von Fragmentierung nichts. Wenn man natürlich ständig am Limit operiert, wird man das evtl. merken, eben wie von Dir beschrieben. Aber generell stellt sich mir die Frage, ist es der richtige Weg das FS immer bei 99% zu betreiben ... ?

Gut Du hast natürlich was von Deiner HDD ... aber eben auch kein Platz für den "Notfall" ...

Regards
fnu

hi, nur als beipflichtung: klar XFS. seit ca.10Jahren Erfolgreich im Einsatz.
Grüsse mentox

Warum ist ein fsck bei xfs schneller als bei ext3?

Ich hab dazu vor ein paar Jahren mal was zur Quota Lösung entwickelt.

http://www.mail-archive.com/vdr@linuxtv.org/msg06209.html

Klaus war das dann nicht "kis" genug. Er machte den Vorschlag hier eine Plugin Schnittstelle zu schaffen. Hab das dann nicht mehr weiter verfolgt. Aber vielleicht kann ja jemand mit mehr Zeit diese Lösung mal wieder "aufwärmen" und an neuere VDR Versionen anpassen. Ich bin noch auf 1.6x und bin mit der Quotalösung sehr zufrieden.

Gruß
msv

Hallo

Mal ne Frage an die xfs Spezies.
Bis vor Kurzem hatte ich fuer die VideoPartition unter Gen2VDR aper default auch xfs genommen.
Es traten aber insgesamt zuviele Faelle auf, in welchen beim Booten die xfs Platte nicht gemountet wurde und erst ein xfs-repair noetig war um wieder an die Platte ranzukommen.
Dies passierte unter kernel 2.6.23 mit den default xfs Parametern (beim erstellen und mounten).
Woran koennte dies liegen ?
Wird die Gefahr dieses Problems durch die von Euch vorgeschlagenen Parameter verringert ?

Überprüfe mal die SMART-Werte der Platte. Vielleicht kündigt sich da ein Hardware-Problem an.

Das Problem trat bei einigen Usern mit unterschiedlichen Platten auf, z.T. auch mit neuen Platten.

Zitat

Original von henfri
Warum ist ein fsck bei xfs schneller als bei ext3?

Hendrik, es gibt bei xfs, wie eigentlich bei allen Filesystemen mit Journal bzw. Transaktions-Log, keinen fsck. Diese Dateisystem sind so ausgelegt, das Änderungen mitprotokolliert werden. Sollte die Maschine abstürzen, wird beim Start geprüft, ob alle Änderungen aus dem Journal durchgeführt wurden, wenn nicht, werden die ausstehenden Änderung nachgepflegt. Da dies normalerweise wenig Daten sind und der Rest vom Filesystem sauber ist, wird das bei jedem Start gemacht und damit ist nie ein fsck nötig, soweit die Theorie.

In der Praxis kann es wie bei allen Datenbanken natürlich auch zu Inkonsistenzen kommen, also der Stand des Journals (Transaktionslog) passt hinten und vorne nicht zum Stand im Filesystem. Dann sind auch hier Werkzeuge zur Reparatur nötig (z.B. xfs_repair), welche dann ebenso lang dauern kann wie der fsck bei ext2/ext3.

===

helau

Ich vermute da eher ein Problem beim runterfahren der VDRs. Evtl. werden die Dateisysteme dabei zu oft nicht sauber geschlossen, oder das Schließen nicht richtig abgewartet, was nach einer Weile zu Inkonsistenzen im Journal führt und den "xfs_repair" notwendig macht.

Der Parameter "osyncisosync" ist der einzige Sicherheitsparameter bei mir, der in diese Richtung geht. Der Rest der Mount-Optionen ist eher der Verbesserung der Performance geschuldet.

Regards
fnu

Zitat

Original von fnu
Ich vermute da eher ein Problem beim runterfahren der VDRs. Evtl. werden die Dateisysteme dabei zu oft nicht sauber geschlossen, oder das Schließen nicht richtig abgewartet, was nach einer Weile zu Inkonsistenzen im Journal führt und den "xfs_repair" notwendig macht.

Das denke ich auch, aber meiner Meinung nach muss der HTPC auch wieder hochfahren wenn er einfach so ausgeschaltet wurde. Ein xfs_repair kann Otto Normalverbraucher nicht ausfuehren
Verhindert osyncisosync dieses Problem ?