Wieso benutzt man den Fehler eines Menschen immer nur dazu, den Betreffenden bloßzustellen und (verbal) vernichten zu wollen? Ein kurzer, nüchterner Hinweis hätte genügt. Viele Publikationen arbeiten nicht umsonst mit Lektorat, da sich viele solcher Fehler eher zwangsläufig einschleichen. Der Autor ist wohl kein ZFS-Geschichtsxperte. Ja und? Der Fehler wurde übrigens inzwischen korrigiert.
Nach 15 Jahren "Hobby" nimmt man solche "Verbesserungen" gelassen Und sollte ich in ein Alter kommen, in dem mich solche Kommentare wirklich aufregen, so ist die Lösung ziemlich einfach:
Habe auf einem neuen sehr schnellen Thinkpad Ubuntu mit root als btrfs installiert, und sowohl Lese- als auch vor allem Schreibgeschwindigkeit ist fast nicht auszuhalten. Hatte eigentlich auf Geschwindigkeitszuwachs gehofft. Bugreports dazu gibt es auch, nur noch keine Lösungen.
einen hatte ich grad noch offen https://bugs.launchpad.net/ubuntu/+source/linux/+bug/601299 der beschäftigt sich nur mit dpkg was wirklich grausam langsam ist
Bei dpkg ist ja bekannt, dass es sehr viele fsync()-Aufrufe macht. Scheint (schien?) also so zu sein, dass btrfs bei vielen fsync() aufrufen etwa sins stocken gerät. Fairerweise muss man aber auch erwähnen, dass in sehr vielen Programmen das fsync() völlig falsch oder unnütz eingesetzt wird. Linus Torvalds hat sich darüber auh schonmal irgendwo drüber ausgelassen...
Der bug ist 1,5 Jahre alt, sicher dass das keine alte Klamotte ist?
Also das dpkg problem ist definitv noch vorhanden da. Auch auf ubuntu precise alpha mit kernel 3.2.5. Das habe ich da es stabiler ist als die final von 11.10 auf verschiedenen Rechnern im einsatz. Bei einigen habe ich btrfs root getestet. Start dauert gefühlt doppelt so lang. Update von 20 Packages (ohne download) ext4 unter einer minute btrfs etwa 20 minuten
Die Hauptursache des Problems ist aber apt und seine unzähligen fsync()-Aufrufe. Bevor debian aber das apt dahingehend anpasst, forken sie eher btrfs und bauen einen Workaround ein
Sicher dass das an btrfs liegt? Ich habe hier ein ZFS auf einem root-Server und dort ist genau das auch unglaublich miserabel langsam. Kopieren geht flott, löschen geht flott, starten geht meistens auch flott. Aber dpkg geht in keinster Weise flott. Ich glaube dass es nicht wirklich an btrfs liegt. Früher ging das übrigens viel schneller.
Reiser? Gibts echt noch Leute die das benutzen? Also ich würde dass nur für Daten benutzen, die man auch genausogut in /dev/null parken kann
Bei Reiser mus sman nur oft genug in das FS schreiben, dann zerlegt es sich irgendwann von selbst. Und ie fsck-Tools machen alles nur schlimmer anstatt besser.
Wem das noch nie passiert ist, der schreibt einfach nicht genug in seine Dateisysteme.
Ich hab schon Kunden-Systeme gesehen, wo sich Reiser nachvollziehbar und regelmäßig die Karten gelegt hat. Ca. alle vier Wochen. Waren aber auch extrem viele Create/Unlink-Vorgänge. Jedenfalls war das Problem mit XFS erledigt.
Ich hatte nie Probleme mit Reiser auf meinem Desktop-PC. und das seit Suse das zum erstenmal anbot. Allerdings gibt es genügend die Probleme hatten, weil die Hardware einfach fehlerhaft war.
Ich will allerdings zu BTRFS wechseln, sobald fsck fertig ist und Ubuntu es in der Distri mit drin hat.
Allein schon aus moralischen Gründen kann Reiser kaum in Frage kommen. Ich setze kein FS ein, das von jemandem enwickelt wurde, der seine Frau erschossen und vergraben hat und dafür im Knast sitzt. Sorry.
Auf diese Weise einen auf Moralisch zu machen finde ich etwas scheinheilig, sorry.
Wenn du allerdings *konsequent* nichts von irgendwelchen Leuten einsetzt, die irgendwie Dreck am Stecken haben, dann: Hut hab!
Dann hast du z.B. nicht ein Produkt, welches seltene Erden aus China enthält. Denn um diese zu gewinnen sterben in China wöchentlich Kinder in Minen. Das bedeutet: Kein Smartphone, kein Flachbild-TV, keinen Computer... äh wie schreibst du hier eigntlich ins Forum?
Je mehr ich über solche Dinge erfahre, desto schlechter wird mein Gewisen, bzw desto mehr verachte ich unsere westliche Gesellschaft.. aber da sgehört hier nicht her.
Ja, was Reiser getan hat - wenn ers denn getan hat - ist verachtenswert. Das hat aber nichts damit zu tun wie gut er als Programmierer ist oder war.
Hab doch ein wenig Verständnis für den Mann. Er hat in einer Scheidung gesteckt. Ich mag seine Tat nicht rechtfertigen. Trotzdem kann ich mir vorstellen wie viel persönliches Elend er erlebt haben kann um zu dieser Tat zu kommen.
Verständnis? Nö, von mir nicht. Ich wäre allerdings in der Lage ein FS objektiv anhand seiner Leistung usw. zu bewerten, und nicht anhand der Personen dahinter. Leider hat Reiser seine Person und seinen Namen mit dem Projekt eng verbunden, so dass mit seiner Festnahme reiserfs praktisch vom Fenster ist, auch wenn es die Firma namesys und andere Entwickler noch gibt. Schade, ich hab von reiser4 vieles erwartet, was sicher auch gekommen wäre bzw. zu großen Teilen schon vorhanden ist.
Ich denke BTRFS ist ein Nachbau von ZFS. Wozu braucht es da einen Filesystemcheck? Das Design von ZFS ist doch so, das der Zustand des Filesystems immer sauber ist. Selbst im Worst Case eines Stromausfalls.
das stimmt, weiß ich nicht...aber "sooo" super ist btrfs auch nicht. habe viele tests gemacht...geschwindigkeitsmässig hält es mit ext4 gut mit - mal flotter, mal etwas langsamer - ...was mich persönlich etwas genervt hat, war der fehlende filesystemcheck nach einem stromausfall ...das hat mich einige zeit gekostet, dass (ansich intakte) FS wieder beim normalen bootvorgang automatisch mounten zu lassen ...
voll krass
...Killer!
Weiss jemand, ob diese erste stabile Version der Tools dann auch eine Online-Defragmentierung beinhaltet?
Was ist mit einem Online-FSCK?
(Bitte keine lmgtfy-Links ;-))
Defragmentierung gibt's seit 3.0 (autodefrag mount-Option).
So ein an den Haaren herbeigezogener Dummfug. Der hat vorher für Suse an Reiser3 gearbeitet.
Woher habt ihr den Scheiss?
Das Pro steht auch nicht für Profi.
Aber wie kommt man nur auf diesen Dünnschiss, Mason und ZFS?
wikipedia meint: "ZFS was designed and implemented by a team at Sun led by Jeff Bonwick."
Wieso benutzt man den Fehler eines Menschen immer nur dazu, den Betreffenden bloßzustellen und (verbal) vernichten zu wollen?
Ein kurzer, nüchterner Hinweis hätte genügt.
Viele Publikationen arbeiten nicht umsonst mit Lektorat, da sich viele solcher Fehler eher zwangsläufig einschleichen.
Der Autor ist wohl kein ZFS-Geschichtsxperte.
Ja und?
Der Fehler wurde übrigens inzwischen korrigiert.
Nach 15 Jahren "Hobby" nimmt man solche "Verbesserungen" gelassen
Und sollte ich in ein Alter kommen, in dem mich solche Kommentare wirklich aufregen, so ist die Lösung ziemlich einfach:
# ssh pro-linux.de
# poweroff
Cheers,
demon
Habe auf einem neuen sehr schnellen Thinkpad Ubuntu mit root als btrfs installiert, und sowohl Lese- als auch vor allem Schreibgeschwindigkeit ist fast nicht auszuhalten.
Hatte eigentlich auf Geschwindigkeitszuwachs gehofft.
Bugreports dazu gibt es auch, nur noch keine Lösungen.
Hast du mal nen URL zu so einem Bugreport?
einen hatte ich grad noch offen
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/601299
der beschäftigt sich nur mit dpkg was wirklich grausam langsam ist
Bei dpkg ist ja bekannt, dass es sehr viele fsync()-Aufrufe macht. Scheint (schien?) also so zu sein, dass btrfs bei vielen fsync() aufrufen etwa sins stocken gerät. Fairerweise muss man aber auch erwähnen, dass in sehr vielen Programmen das fsync() völlig falsch oder unnütz eingesetzt wird. Linus Torvalds hat sich darüber auh schonmal irgendwo drüber ausgelassen...
Der bug ist 1,5 Jahre alt, sicher dass das keine alte Klamotte ist?
Also das dpkg problem ist definitv noch vorhanden da. Auch auf ubuntu precise alpha mit kernel 3.2.5.
Das habe ich da es stabiler ist als die final von 11.10 auf verschiedenen Rechnern im einsatz.
Bei einigen habe ich btrfs root getestet.
Start dauert gefühlt doppelt so lang.
Update von 20 Packages (ohne download)
ext4 unter einer minute
btrfs etwa 20 minuten
Die Hauptursache des Problems ist aber apt und seine unzähligen fsync()-Aufrufe. Bevor debian aber das apt dahingehend anpasst, forken sie eher btrfs und bauen einen Workaround ein
Sicher dass das an btrfs liegt? Ich habe hier ein ZFS auf einem root-Server und dort ist genau das auch unglaublich miserabel langsam. Kopieren geht flott, löschen geht flott, starten geht meistens auch flott. Aber dpkg geht in keinster Weise flott. Ich glaube dass es nicht wirklich an btrfs liegt. Früher ging das übrigens viel schneller.
Zum Glück braucht man es nicht so oft.
Ich wäre mal neugierig, wie sich BTRFS gegen Raiser schlägt, wenn es um das Lesen und Schreiben von kleinen Dateien geht.
Reiser? Gibts echt noch Leute die das benutzen? Also ich würde dass nur für Daten benutzen, die man auch genausogut in /dev/null parken kann
Bei Reiser mus sman nur oft genug in das FS schreiben, dann zerlegt es sich irgendwann von selbst. Und ie fsck-Tools machen alles nur schlimmer anstatt besser.
Wem das noch nie passiert ist, der schreibt einfach nicht genug in seine Dateisysteme.
Ich hab schon Kunden-Systeme gesehen, wo sich Reiser nachvollziehbar und regelmäßig die Karten gelegt hat. Ca. alle vier Wochen. Waren aber auch extrem viele Create/Unlink-Vorgänge. Jedenfalls war das Problem mit XFS erledigt.
Ich hatte nie Probleme mit Reiser auf meinem Desktop-PC. und das seit Suse das zum erstenmal anbot. Allerdings gibt es genügend die Probleme hatten, weil die Hardware einfach fehlerhaft war.
Ich will allerdings zu BTRFS wechseln, sobald fsck fertig ist und Ubuntu es in der Distri mit drin hat.
Allein schon aus moralischen Gründen kann Reiser kaum in Frage kommen.
Ich setze kein FS ein, das von jemandem enwickelt wurde, der seine Frau erschossen und vergraben hat und dafür im Knast sitzt. Sorry.
Auf diese Weise einen auf Moralisch zu machen finde ich etwas scheinheilig, sorry.
Wenn du allerdings *konsequent* nichts von irgendwelchen Leuten einsetzt, die irgendwie Dreck am Stecken haben, dann: Hut hab!
Dann hast du z.B. nicht ein Produkt, welches seltene Erden aus China enthält. Denn um diese zu gewinnen sterben in China wöchentlich Kinder in Minen.
Das bedeutet: Kein Smartphone, kein Flachbild-TV, keinen Computer... äh wie schreibst du hier eigntlich ins Forum?
Je mehr ich über solche Dinge erfahre, desto schlechter wird mein Gewisen, bzw desto mehr verachte ich unsere westliche Gesellschaft.. aber da sgehört hier nicht her.
Ja, was Reiser getan hat - wenn ers denn getan hat - ist verachtenswert. Das hat aber nichts damit zu tun wie gut er als Programmierer ist oder war.
Hab doch ein wenig Verständnis für den Mann. Er hat in einer Scheidung gesteckt. Ich mag seine Tat nicht rechtfertigen. Trotzdem kann ich mir vorstellen wie viel persönliches Elend er erlebt haben kann um zu dieser Tat zu kommen.
Verständnis? Nö, von mir nicht. Ich wäre allerdings in der Lage ein FS objektiv anhand seiner Leistung usw. zu bewerten, und nicht anhand der Personen dahinter. Leider hat Reiser seine Person und seinen Namen mit dem Projekt eng verbunden, so dass mit seiner Festnahme reiserfs praktisch vom Fenster ist, auch wenn es die Firma namesys und andere Entwickler noch gibt. Schade, ich hab von reiser4 vieles erwartet, was sicher auch gekommen wäre bzw. zu großen Teilen schon vorhanden ist.
Namesys gibt es seit Jahren nicht mehr.
Stimmt offenbar, dann waren die mit der Festnahme von Reiser soweit weg vom Fenster, dass ich nichtmal bemerkt hab dass es sie nicht mehr gibt.
Herzlichen Glückwunsch zum dämlichsten Posting des Monats. Wahrscheinlich fährst Du auch nicht auf unter Hitler gebauten Autobahnen...
Hitler hat die Autobahnen selbst gebaut? Der Mann muss sehr beschäftigt gewesen sein.
Ansonsten: Viele Autobahnen wurden schon vor Hitler begonnen.
er sagte UNTER hitler gebaut, wie auch immer das dann geht (sänfte mit bautrupp drunter?)
Ich denke BTRFS ist ein Nachbau von ZFS. Wozu braucht es da einen Filesystemcheck? Das Design von ZFS ist doch so, das der Zustand des Filesystems immer sauber ist. Selbst im Worst Case eines Stromausfalls.
das stimmt, weiß ich nicht...aber "sooo" super ist btrfs auch nicht. habe viele tests gemacht...geschwindigkeitsmässig hält es mit ext4 gut mit - mal flotter, mal etwas langsamer - ...was mich persönlich etwas genervt hat, war der fehlende filesystemcheck nach einem stromausfall ...das hat mich einige zeit gekostet, dass (ansich intakte) FS wieder beim normalen bootvorgang automatisch mounten zu lassen ...
Bei ZFS gibt es auch scrub um das FS zu überprüfen/reparieren.