MP3-Shredder FreeBSD/UFS?

C

cabriofahrer

Well-Known Member
FreeBSD ist ja ganz toll um mp3's zu hören, man bekommt den besten Klang, es läuft alles super, usw., aber:
Auch unter FreeBSD kann es Abstürze geben, mit der Folge, daß beim nächsten Reeboot natürlich von fsck alles überprüft, "gefixt" und "gesalvaged" wird.
Und irgendwann erlebt man eine Überraschung:
Einzelne mp3's sind schlichtweg kaputt (und ausgerechnet die, anscheinend nichts anderes), entweder in ein kleines Überbleibsel zerhackt, oder was ich jetzt noch erlebt habe, werden mit halber Geschwindigkeit gespielt??
Also unter Windows/NTFS scheint es so etwas nicht zu geben, trotz zahlreicher Abstürze scheinen alle Dateien immer sicher zu sein.

Eure Meinung dazu? Wie verhält es sich mit Linux/Ext2/3?
 
Der fsck repariert nach einen normalen Absturz nichts am Dateisystem, er sucht lediglich als belegt markierte Inodes welche in Wirklichkeit frei sind und gibt diese frei. Entsprechend wird die Anzahl der freien Blöcke korrigiert.
Was du hier erlebst, ist das berüchtigte Softupdateslag. Spielst du eine Musikdatei ab, wird die geöffnet und automatisch die atime aktualisiert. Dies verändert die Inode, die Änderung befindet sich jedoch zuerst einmal nur im Softupdatescache. Schmiert das System jetzt ab, passiert nicht. Wird die Inode aber gerade aus dem Cache auf die Platte aktualisiert und nun schmiert das System ab, ist sie auf der Platte inkonsistent. fsck würde dies erkennen und die Inode löschen. Leider hat deine Festplatte aber einen Writecache, welcher sicher eingeschaltet ist. Hierdurch werden Konsistenzannahmen zerstört, die Inode ist in Ordung, die zugehörigen Frags aber unvollständig geschrieben. Pech gehabt, sich nicht Ärgern und in Zukunft Gegenmaßnahmen ergreifen. Es kann auch helfen, dem Datesystem mal ein richtiges fcsk zu verpassen und kein Hintergrundfsck...
 
fsck_ext2fs ist ganz nett, nur leider hatte es mir nach einem Absturz von 70GB 13 versemmelt.
Schade, dass es keinen richtige UFS2 Unterstützung für Windows gibt, inkl. fsck etc. *träum* :D

@Steve, habs angepasst :D
 
Zuletzt bearbeitet:
Unter Vista ist der Write-Cache der Platte übrigens normalerweise ausgeschaltet. Wenn du ihn einschaltest wirst du mit einer entsprechenden Warnung versorgt, NTFS ist also auch nicht vor solchen Dingen gefeilt.
 
ext2 würde ich eh nicht in Maschinen nutzen, welche nicht zu 100% stabil laufen. Das Schadensrisiko wäre mir einfach zu hoch. ext3 ist deutlich sicherer als ext2, aber es hat ebenfalls das Writecache-Problem. Gleiches gilt auch JFS, XFS und ReiserFS, die allerdings alle unterschiedlich anfällig sind.
Anders ist es mit ZFS, dies kann durch "Selfhealing" Datenkorruption erkennen und beheben, wenn die Daten mindestens zweimal gespeichert sind. Geli wiederum kann Daten ebenfalls durch eine Hashfunktion sichern, du erkennst du Datenkorruption, kannst sie allerdings nicht reparieren.

Ich würde hier folgendes als erste Hilfe machen: Deaktiviere die Accesstime mit der Mountoption noatime, wenn möglich. Dies sorgt dafür, dass eine Inode wirklich nur gelesen und nicht indirekt auch geschrieben wird. Außerdem macht es das Dateisystem zwischen 5 und 15 Prozent schneller. Außerdem kannst du den Writecache deaktivieren, dies tut allerdings je nach Hardware sehr weh, da Dateizugriffe deutlich verlangsamt werden.
 
Ich würde hier folgendes als erste Hilfe machen: Deaktiviere die Accesstime mit der Mountoption noatime, wenn möglich. Dies sorgt dafür, dass eine Inode wirklich nur gelesen und nicht indirekt auch geschrieben wird. Außerdem macht es das Dateisystem zwischen 5 und 15 Prozent schneller. Außerdem kannst du den Writecache deaktivieren, dies tut allerdings je nach Hardware sehr weh, da Dateizugriffe deutlich verlangsamt werden.

Wie genau kann ich beides machen?
 
1) Zur Laufzeit: mount -uo noatime /usr für /usr. Generell noatime in die fstab eintragen.
2) hw.ata.wc=0 in die loader.conf
 
Sorry, aber was für einen Mist macht ihr denn mit euren FreeBSD-Systemen, dass es beim Musik-Abspielen Abstürze gibt?

Oder wenn's an der Hardware liegt würde ich es auch nicht auf das OS schieben.
 
Kein Mist beim Musikhören generell, aber wenn man z.B. versucht, AIGLX zu aktivieren, oder der Akku vom Notebook auf einmal leer ist (die Akkufunktion wird erst ab FreeBSD7 unterstützt) oder mal die Hardware verreckt (ist mir schon mal mit einem Mainboard passiert)...Es gibt viele Gründe für einen Absturz.

Aber was mir nie ganz klar war, ob die mp3's wirklich in dem Moment abgespielt wurden (ich glaube eher nicht) oder diese eher willkürlich beschädigt wurden.
Ich habe z.B. nur eine / Partition, auf der alles liegt, und eine swap.
Könnte das auch eine Rolle spielen?
 
FreeBSD läuft nicht auf jeder Hardware gleich stabil. Da kann es natürlich zu Abstürzen kommen. Das Problem ist, dass / normalerweise ohne Softupdates gemountet wird. Schau mal nach ob die überhaupt aktiviert sind.

In der Regel ist / eine kleine Partition auf der sehr wenig geschrieben wird (ich betreibe die sogar read-only). Damit wird eine Beschädigung der wichtigsten Systemkomponenten (Kernel, fsck) unwahrscheinlicher.
 
Eine Frage dazu:

Warum sind SoftUpdates per Default deaktiviert, ich hab sie an gemacht, hat man dadurch einen Nachteil ?

Mp3s schreddern:

Ist mir gestern noch passiert, sehr ärgerlich, habe von /home(UFS) --> usbmp3player(FAT) mp3s kopiert, kamen alle zerschreddert auf ihm an, auch wenn ich sie wieder auf die Festplatte gezogen habe. Ich denke der Player ist heile, denn als ich Es mit Windows gemacht hab war alles in Ordnung.
 
Der Nachteil ist, dass Änderungen an Dateien, die kurz vor einem Absturz gemacht werden, verloren gehen. Außerdem wird Speicherplatz verzögert frei gemacht. Wenn du also eine kleine Partition hast (wie / normalerweise eine ist) und du viele Dateien überschreibst (wie bei einem umfassenden Update des Basissystems), kann es sein, dass die Partition volläuft, weil der Speicherplatz noch nicht freigegeben wurde. Du hast also eigentlich genug freien Platz, aber du kannst ihn zu einem kritischen Zeitpunkt nicht verwenden.

Der Vorteil ist, dass die Konsistenz des Dateisystems nicht so gefährdet ist und die Performance besser wird.
 
Endorphine schrieb:
Das ist generell "Mist". ;)

Ich benutze den Akkubetrieb bei meinem Notebook auch, habe aber deswegen dennoch keine Abstürze.
Zum Vergrößern anklicken....

Warum ist das generell "Mist"? Die meisten Linux-Distris richten das auch so ein.
Ich habe es irgendwann so gemacht, weil mit der Standard-Partitionsvorgabe von FreeBSD

/
/var
/tmp
/usr

große komprimierte Dateien (auch unter fileroller) nicht mehr entpackt werden konnten, weil der Platz auf /tmp eben viel zu klein ist. Verzichtet man auf diese Einteilung, hängt alles an /, eben auch /tmp, und der Platz zum Entpacken ist immer groß genug.
Und wenn ich für / z.B. 1 GB einrichten würde, dann könnte es immernoch passieren, daß der Platz zum Entpacken einer riesigen Datei immer noch zu klein ist.
Oder auch zum Suchen von irgendwelchen Dateien ist es vorteilhaft, weil eben alles auf einmal abgesuncht wird.
 
Fuer einen Desktop Rechner mag es vielleicht einfach sein, dass so einzurichten. Aber es sollte dennoch nicht unbedingt gemacht werden, weil Du -wie oben auch beschrieben- das Root-Dateisystem (/) ohne Soft-Updates mountest. Ausserdem koenntest Du / und /usr auch Read-Only mounten, um die Zugriffe etwas zu beschleunigen. Ausserdem hast Du den Vorteil, wenn Dir ein Dateisystem (/home, /tmp, /var) voll laeuft, Du nicht wichtige Systemdateien beschaedigst, die u.U. Dein System unbrauchbar machen.

Und wenn Deine Platte so gross ist, dann kannst Du doch auch /tmp groesser als 1 GB machen. ;)

HTH
 
Schlagt mich, aber aufm Desktop hab ich nur ein Dateisystem: Root :)
Das ich mich hier auf meine System verlassen kann, hab ich auch kein schlechtes Gewissen :D
Bei Servern hingegen hab ich teilweise den Schreibcache bewusst ausgeschaltet (z.b. bei OpenLDAP Datenbanken) um auf jeden Fall eine Integrietät zu wahren. Nix anderes macht im übrigen ein Windows Server auf dem Active Directory aktiviert wurde.

Was ich damit sagen will: Jeder Rechner hat seinen eigenen Reiter.
 
FreeBSDuser schrieb:
Ist mir gestern noch passiert, sehr ärgerlich, habe von /home(UFS) --> usbmp3player(FAT) mp3s kopiert, kamen alle zerschreddert auf ihm an
Zum Vergrößern anklicken....
SuFu! Das ist ein Problem im USB-Stack, der mit bestimmten Chipsätzen auftreten kann. Dazu gab es hier vor kurzen noch einen Thread.

Die Diskussion über die "richtige" Partitionierung ist mir ehrlich gesagt zu ausgelutscht. Auch hier finden sich über die Forensuche unzählige Beiträge.
 
Wie "der neue"? Falls du den neuen USB-Stack meinst, nein. Hans-Peter sucht aktuell Personen, die seine Snapshots im produktiven Einsatz testen... Infos auf freebsd-usb@.
 
Ich habe gestern ein File auf meinen Cowon D2 kopiert, den hat es ganz merkwürdig zerrissen. Im Abstand von wenigsten Sekunden wir ein kurzes Stück 5mal gelooped, bevor es dann wieder für eine Sekunde weitergeht, um dann wieder zu Loopen.

Wir wir wir wir wir euch euch euch euch euch sendung sendung sendung sendung sendung

Ich hab ja schon viel gesehen und gehört, aber das ist echt der Hammer. Das Originalfile auf dem UFS2 ist noch in Ordnung, der Bock muss irgendwo im USB-Stack liegen.
Code: 
[stell @ hurricane:~]% uname -sr
FreeBSD 7.0-STABLE
Mal gucken, ob ich den Kram von Hans-Peter ergooglen kann.
 
Ich bin nicht sicher, ist usb4bsd hier das Stichwort?

Das habe ich nämlich mal eingespielt, hilft aber wenig:
Code: 
Mar  1 11:16:02 hurricane kernel: umass1: <COWON Systems, Inc. COWON D2????1n? Pn? ?@-??] 2.51??, class 0/0, rev 2.00/2.51, addr 5> on usb0
Mar  1 11:16:02 hurricane kernel: umass1:  SCSI over Bulk-Only; quirks = 0x0000
Mar  1 11:16:03 hurricane kernel: umass1:5:1:-1: Attached to scbus5
Mar  1 11:16:03 hurricane kernel: xptioctl: pass driver is not in the kernel
Mar  1 11:16:03 hurricane kernel: xptioctl: put "device pass" in your kernel config file
Mar  1 11:16:14 hurricane kernel: da4 at umass-sim1 bus 1 target 0 lun 0
Mar  1 11:16:14 hurricane kernel: da4: <COWON D2 0100> Removable Direct Access SCSI-0 device
Mar  1 11:16:14 hurricane kernel: da4: 1.000MB/s transfers
Mar  1 11:16:14 hurricane kernel: da4: 3816MB (7815168 512 byte sectors: 255H 63S/T 486C)
Mar  1 11:16:14 hurricane kernel: da5 at umass-sim1 bus 1 target 0 lun 1
Mar  1 11:16:14 hurricane kernel: da5: <COWON D2 0100> Removable Direct Access SCSI-0 device
Mar  1 11:16:14 hurricane kernel: da5: 1.000MB/s transfers
Mar  1 11:16:14 hurricane kernel: da5: Attempt to query device size failed: NOT READY, Medium not present
Mar  1 11:16:14 hurricane kernel: GEOM_LABEL: Label for provider da4 is msdosfs/D2.
HAL wirft darüber hinaus noch
Code: 
hal-storage-fixed-mount refused uid 1000
Nach letzterem gehe ich jetzt nochmal googlen.

Woher die Meldung nach fehlendem Pass kommt ist mir übrigens völlig unklar, das ist selbstverständlich in der Kernelconfig vorhanden.
 
Du musst dich einloggen oder registrieren, um hier zu antworten.
Zurück
Oben