vdr zerdengelt Filesystem? (xfs)

Zitat von DaKilla

Das mit dem löschen von großen Dateien kann nicht nur xfs gut, das ist eine der Stärken von ext4 (gegenüber ext3).

Albert

Gestern beim Suchen bin ich auf eine Seite gestossen, die XFS und ext4 vergleicht.
ext4 löscht demnach jetzt schneller als xfs!

Ich kenne jetzt nicht das Ergebnis, wenn man fschk auf eine 3TB Platte los lässt.
XFS wird damit in wohl weniger auf einer Minute fertig sein.

Ich schau mal ob ich den Link wiederfinde.
Das ist es nicht:
http://lwn.net/Articles/476263/

Zitat von DaKilla

Wenn ich mich nicht irre, dann macht yaVDR den fsck beim Herunterfahren. Selbst wenn es länger dauert, spielt es keine Rolle.

Albert

Gut zu hören.
Auch bei XFS?
Wo wird das gemacht?

Und was passiert dann?
Wie werden die Platten runtergefahren?
Bekommen sie nach dem fsck xfs_repair per hdparm einen "spindown" Befehl oder wie wird "abgeschaltet"?

Ich habe, seit dem ich den Write cache disablete keine defekte mehr(müsste heute mal nachsehen, aber er nimmt gerade auf).
Das könnte damit zusammenhängen, das die Platten abgeschaltet werden ohne eine faire Chance zu bekommen diesen zu flushen.
Warum das nur bei mir auffällt? Anderes Frage Mir fällt immer auf, was anderen nicht auffällt. Schon lästig, ja.

Zitat von seahawk1986

/etc/init.d/force-fsck
Nachdem sie ausgehängt wurden (und damit keine Änderungen am Dateisystem vorgenommen werden können), schaltet irgendwann jemand den Strom ab.
Das sind dann die normalen Ubuntu-Mechanismen für den Shutdown.

Thanks.

Die letzten Änderungen könnten ja die vom fsck sein...

Ich habe keine merkliche Pause zwischen "Power LED off" und "Platten LED off" bemerkt,
Das ist aber nur rein subjektiv

Zitat von seahawk1986

/etc/init.d/force-fsck

root@vdr4:~# grep -e "^[[:blank:]]*[^#].*[12][[:blank:]]*$" /etc/fstab
UUID=ec2303ad-033e-4375-aedf-e0de56e13dea /               ext4    errors=remount-ro,noatime 0       1

Und die andere Partition?

root@vdr4:~# cat /etc/fstab
proc            /proc           proc    nodev,noexec,nosuid 0       0
UUID=ec2303ad-033e-4375-aedf-e0de56e13dea /  ext4    errors=remount-ro,noatime 0       1
UUID=7f806aa8-c7a0-4f83-b475-ca590d5e75ec none   swap    sw              0       0
UUID=663d77c4-6ae1-42f3-9bd0-b54c0539bfd4     /var/lib/video.00  xfs defaults,noatime 0 0

Aber würde nicht eh gehen, da fsck nicht mit xfs umgehen kann, oder?

root@vdr4:~# fsck -C0 -y -f /dev/sda3
fsck from util-linux 2.20.1
/sbin/fsck.xfs: XFS file system.

root@vdr4:~/fsck# tune2fs -l /dev/sda3
tune2fs 1.42 (29-Nov-2011)
tune2fs: Bad magic number in super-block while trying to open /dev/sda3
Couldn't find valid filesystem superblock.

root@vdr4:~/fsck# fsck -C0 /dev/sda3
fsck from util-linux 2.20.1
If you wish to check the consistency of an XFS filesystem or
repair a damaged filesystem, see xfs_check(8) and xfs_repair(8).

<pass> 	Gibt an, ob und in welcher Reihenfolge die Partition beim Systemstart in die regelmäßigen Dateisystemprüfungen einbezogen wird. 
Meist ist hier für die Root-Partition (die Wurzel des Dateisystems, "/") 1 eingetragen, 
für alle anderen Partitionen 2 (danach prüfen) 
oder 0 (keine Überprüfung) z.B. für Windows-Dateisysteme.

Damit ist das script als ursache raus:
Es fasst die video Partition garnicht an, weil "pass" nicht "1" ist.
Und am ende wird nur die "/" partion gefscheckt; nicht die Viedo Partionen?
Und auch nur dann wenn der MountCount erreicht wurde.
XFS ist nicht yaVDR kompatibel!

Zitat von tag

Es spielt keine Rolle, ob oder wann fsck läuft. Bei XFS macht fsck sowieso nichts (man 8 fsck.xfs).

Der Write-Cache der Festplatte könnte aber tatsächlich das Problem sein. Stehen im syslog irgendwelche Meldungen bzgl. write barriers? Wenn die nicht funktionieren, musst du den Write-Cache wohl dauerhaft abschalten. Nur erklärt das leider auch nicht, warum das Dateisystem im laufenden Betrieb beschädigt wurde.

Also: Ich habe bisher einmal beobachtet, das nach einem löschen XFS_repair arbeiten musste.
Ich will nicht ausschliessen, das ich, als die Kiste neu war, öfters mal so ausgeschaltet habe und das dabei defekte entstanden sind,
die erst jetzt aufgefallen sind.

Zitat

Vermutlich ist es unwichtig, aber ... Warum liegt sda2 hinter sda3?

Da verstehe ich nicht auf was Du dich beziehst.
sda2 müsste der swap sein. Den legt man heut zutagen ja danz nach hinten, weil man den eh nie brauchen(darf)

sda3 habe ich nachträglich mit parted eingerichtet, da ich naiverweise erwartet hatte, das mich das Installatiosprogramm fragt, welche Quota oder Partions grösse für die Videos vorgesehen werden soll. Das die einfach unter "/" liegen, würden konnte ich mir einfach nicht vorstellen. Also musste ich das nachträglich machen.

Zitat von utiltiy

Welche UUID was ist findest Du mit einem simplen:

Code

blkid

auf der Console

root@vdr4:~# blkid -U ec2303ad-033e-4375-aedf-e0de56e13dea
/dev/sda1
root@vdr4:~# blkid -U 7f806aa8-c7a0-4f83-b475-ca590d5e75ec
/dev/sda5
root@vdr4:~# blkid -U 663d77c4-6ae1-42f3-9bd0-b54c0539bfd4
/dev/sda3

Was ist sda2?

Zitat von utiltiy

Hi,

gib nur

Code

blkid

ein und ENTER drücken

Da kam garnix.
Hab wohl nicht lange genug gewartet.
Achso, ja, der will auch auf sdb...und die Platte schläft und muss sich erst mal aufrappel.
Daher die für diesen Vorgang ja ungewöhnliche Wartezeit.

root@vdr4:~# blkid
/dev/sda1: LABEL="BOOTROOT" UUID="ec2303ad-033e-4375-aedf-e0de56e13dea" TYPE="ext4"
/dev/sda3: UUID="663d77c4-6ae1-42f3-9bd0-b54c0539bfd4" TYPE="xfs"
/dev/sda5: UUID="7f806aa8-c7a0-4f83-b475-ca590d5e75ec" TYPE="swap"
/dev/sdb1: UUID="2d78214d-e858-484f-bb43-6699df715036" TYPE="ext4"
/dev/sdc1: LABEL="MYLINUXLIVE" UUID="C4AB-77CC" TYPE="vfat"

Achso, ja seltsam. Das ist wohl dem nachträglichen partionieren zu verdanken.

Zitat von utiltiy

Na siehste, jetzt kennst Du die Zuordnungen

Aber /dev/sda2 ist nicht dabei wie weiter oben angefragt von tag. Ist auch nicht weiter wichtig die Nummerierung, wird eh mit UUID gearbeitet bei vielen Linux Distri's

sda2 ist "extended".

root@vdr4:~# sfdisk -s -l /dev/sda
1953514584


Disk /dev/sda: 243201 cylinders, 255 heads, 63 sectors/track
Warning: extended partition does not start at a cylinder boundary.
DOS and Linux will interpret the contents differently.
Units = cylinders of 8225280 bytes, blocks of 1024 bytes, counting from 0


   Device Boot Start     End   #cyls    #blocks   Id  System
/dev/sda1   *      0+   7394-   7394-  59392000   83  Linux
/dev/sda2     242679+ 243201-    522-   4191233    5  Extended
/dev/sda3       7394+ 242679- 235286- 1889930239   83  Linux
/dev/sda4          0       -       0          0    0  Empty
/dev/sda5     242679+ 243201-    522-   4191232   82  Linux swap / Solaris