staging.inyokaproject.org

Hi, da hab ich mich Monatelang mit Dateisystemen beschäftigt, gelesen, gefragt etc. Und irgendwann stand fest.... ext3 stabil und sicher, reiserfs bei kleinen dateien schnell, xfs bei grossen schnell, ext2 veraltet, reiser4 fast tot, jfs resourcensparend. und heute kauf ich mir die linuxuser mit dem bericht über dateisysteme. und ... siehe da. ext3 langsam. ok. überrascht mich nicht. ext2 wird noch getestet und schneidet ziemlich gut ab. schnell, resourcenschonend. reiser4 in allen bereichen führend. hä. das wird getestet? und gewinnt. warum wird es dann nicht eingesetzt. und btrfs und ext4 wurden getestet. und da beschleicht mich das gefühl... warum wird so viel aufwand in die entwicklung gesteckt??? reiser4 ist da. für ein junges system vergleichsweise ausgereift und läuft. und dann wird auf einmal ext4 entwickelt, was im prinzip ähnliche ziele hat wie reiser4. verschenkte manpower. und an anderer ecke wird dann btrfs entwickelt. was.... ja wie ext4 auch wieder ähnliche ziele hat. ist es nicht ziemlich unsinnig 3 high-end dateisysteme zu haben, wovon keines 100% mainstream ist??? der quellcode von reiser4 ist frei, die performance überragend, die funktionen üppig. währe es nicht sinnvoller das komplett stable zu machen und in den kernel aufzunehmen? dann könnte man auch endlich anfangen wieder gute tools für die dateisysteme zu schreiben und ein entwickler von partimage müsste sihc nicht bald mit einem dutzend dateisysteme rumplagen...

frindly schrieb:

Hi, da hab ich mich Monatelang mit Dateisystemen beschäftigt, gelesen, gefragt etc. Und irgendwann stand fest.... ext3 stabil und sicher, reiserfs bei kleinen dateien schnell, xfs bei grossen schnell, ext2 veraltet, reiser4 fast tot, jfs resourcensparend.

Die Zeit wirst du wahrscheinlich in deinem restlichen Leben durch kein Dateisystem mehr einsparen 😉

und heute kauf ich mir die linuxuser mit dem bericht über dateisysteme. und ... siehe da. ext3 langsam. ok. überrascht mich nicht.

Langsam ist etwas anderes, es ist nicht auf Geschwindigkeit optimiert, aber auch ein Lieferwagen russischer Bauweise kann sinnvoll sein.

ext2 wird noch getestet und schneidet ziemlich gut ab. schnell, resourcenschonend.

Aber ohne Journaling und langsamer beim Konsistenzcheck.

reiser4 in allen bereichen führend.

Kann Dateien maximal bis 8TiB Größe Verwalten. Ext4 bis 16TiB. Dürfte die nächsten zwei Tage zwar keine große Rolle spielen, aber allein deswegen ist Reiser4 eben nicht in allen Bereichen führend.

hä. das wird getestet? und gewinnt. warum wird es dann nicht eingesetzt.

Weil es noch relativ neu ist, weil es nicht jeden Bedarf bedient.

und btrfs und ext4 wurden getestet. und da beschleicht mich das gefühl... warum wird so viel aufwand in die entwicklung gesteckt??? reiser4 ist da. für ein junges system vergleichsweise ausgereift und läuft. und dann wird auf einmal ext4 entwickelt, was im prinzip ähnliche ziele hat wie reiser4. verschenkte manpower. und an anderer ecke wird dann btrfs entwickelt. was.... ja wie ext4 auch wieder ähnliche ziele hat.

Ein Golf ist im Prinzip auch etwas ähnliches wie ein Polo. Letztendlich gibt es unterschiedliche Interessensgruppen, was die Feinabstimmung angeht. Ext4 kann zB. ohne Änderungen des vorherigen Ext3 Dateisystems Ext3 ersetzen. Dürfte bei Reiser schwer fallen.

ist es nicht ziemlich unsinnig 3 high-end dateisysteme zu haben, wovon keines 100% mainstream ist???

Es ist vielfältig. Wenn man es platt runterreissen könnte auf. "Bringen wir doch alle Entwickler in ein Projekt", könntest du Recht haben. Allerdings sind Entwickler (außer für Projektmanager) Individuen die verschiedene Fähigkeiten und Interessen haben. Wer schon immer an Ext entwickelt hat, entwickelt bei dessem Nachfolger sicher eine bessere Performance, als bei einem vollkommen neuen Projekt. Fragwürdige Entscheidungen einzelner Projektleitungen bedeuten bei mehreren nebenläufigen Projekten auch nicht den totalen Gau (Zersplitterung der Entwicklergruppe, Spontanforks etc.) und last but not least gibt es wie geschrieben unterschiedliche Zielsetzungen. In Kleinstcomputern werkelt bei mir Ext2, weil es einen ziemlich geringen Speicher/Rechenaufwand hat. Das es dafür etwas langsamer ist, ist dabei eher weniger entscheidend.

der quellcode von reiser4 ist frei, die performance überragend, die funktionen üppig.

Kann ich nicht beurteilen, könnte ich nichteinmal, wenn ich den Testbericht gelesen hätte. Nach 4-5 Jahren Praxiserfahrung damit, würde ich mich vielleicht dazu äußern.

währe es nicht sinnvoller das komplett stable zu machen und in den kernel aufzunehmen? dann könnte man auch endlich anfangen wieder gute tools für die dateisysteme zu schreiben und ein entwickler von partimage müsste sihc nicht bald mit einem dutzend dateisysteme rumplagen...

Die Plage ist garnicht so groß, dafür gibt es gute Specs und Modularisierten Programmaufbau 😉

Ums mal andersrum aufzuziehen. Warum glaubst du gibt es soviele verschiedene Dateisysteme? Ich würde sagen, weil ein Entwickler unter den bereits vorhandenen keins gefunden hat, dass seinen Bedürfnissen exakt gerecht wurde, und genug Mitstreiter gefunden hat, denen es ähnlich geht. Warum existiert ein Dateisystem weiter? Weil es noch Anwender gibt, für die ein Umstieg entweder viel zu aufwändig wäre (Was bei Ext wie schon geschrieben recht elegant geht), oder die anderen Dateisysteme weiter nicht so gut passen, wie das aktuell eingesetzte.

ext4 ist zu ext3 kompatibel. brtfs ist vollkommen neu und reiser4 tot. jeder programmiert eben da weiter, wo er sich am besten auskennt. ein plötzliches umschwenken zu reiser4 wär wahrscheinlich nicht so optimal, weil man sich da erstmal verdammt lange einlesen müsste. denk ich mir.

EDIT: interessant... gleiche zeit, gleicher inhalt^^

frindly schrieb:

ext3 langsam. ok. überrascht mich nicht. ext2 wird noch getestet und schneidet ziemlich gut ab. schnell, resourcenschonend. reiser4 in allen bereichen führend. hä. das wird getestet? und gewinnt. warum wird es dann nicht eingesetzt.

Schaue dir 10 Tests an und du wirst 8 verschiedene Meinungen finden.

und btrfs und ext4 wurden getestet. und da beschleicht mich das gefühl... warum wird so viel aufwand in die entwicklung gesteckt???

Weil das jemand tun wollte.

reiser4 ist da. für ein junges system vergleichsweise ausgereift und läuft. und dann wird auf einmal ext4 entwickelt, was im prinzip ähnliche ziele hat wie reiser4. verschenkte manpower. und an anderer ecke wird dann btrfs entwickelt. was.... ja wie ext4 auch wieder ähnliche ziele hat. ist es nicht ziemlich unsinnig 3 high-end dateisysteme zu haben, wovon keines 100% mainstream ist???

Nein, einer der gößten Vorteile in der Linux Welt ist das du wählen kannst. Du musst nicht NTFS oder HFS+ verwenden weil eine Konzernzentrale das beschlossen hat.

der quellcode von reiser4 ist frei, die performance überragend, die funktionen üppig. währe es nicht sinnvoller das komplett stable zu machen und in den kernel aufzunehmen?

Ohne mich da genau eingelesen zu haben, es wird Gründe geben warum das KillerFS nicht im Kernel ist.

dann könnte man auch endlich anfangen wieder gute tools für die dateisysteme zu schreiben und ein entwickler von partimage müsste sihc nicht bald mit einem dutzend dateisysteme rumplagen...

Es gibt halt nicht die von oben gelenkte Linux Entwicklungsabteilung. Das hat natürlich vor und Nachteile.

Hi, wie sieht es eigentlich mit jfs aus? Der Bericht beschäftigte sich ja deshalb mit Dateisystemen, weil ja ext3 bald Berührung mit der maximalen Grösse haben soll (gerade im Raid und LVM Umfeld). Laut Wikipedia kann jfs 8 PetaByte verwalten, was ja doch ziemlich viel ist, es ist Journaling, hat B-Tree zur organisation der Verzeichnisse und nutzt extents zur Dateispeicherung. Gparted kann es sogar vergrössern. Hat es nicht alles, was man sich von einem Dateisystem wünscht??? Warum ist es so wenig verbreitet?

Warum Reiser4 nicht im Kernel ist: http://kernelnewbies.org/WhyReiser4IsNotIn

Warum alle immer so auf Performance abfahren ist mir eh fraglich.

Ein Dateisystem muss in erster Linie zuverlässig arbeiten, dann kann man auf die Performance schauen. Jedes Dateisystem ohne Journal dürfte langsamer sein als eins mit (FAT32 ist auch schneller als NTFS beispielsweise).

Was ich noch schön fände, wenn ein Dateisystem herauskommt, dessen Größe (sowohl vergrößern wie verkleinern) man im gemounteten Zustand ändern kann. Bis jetzt geht das nur, wenn man die Dateisysteme vorher aufhängt, was bei / mit etwas Aufwand verbunden ist (von CD booten usw.). Bei NTFS geht das problemlos 😉.

Aber dass es oft viele OpenSource Projekte gibt, die das gleiche machen ist schon teilweise schlimm.

Bestes Beispiel gnash und swfdec. Beide wollen das selbe, aber keines der Plugins funktioniert wirklich toll und könnte adobe flash plugin ersetzen. Oder gibt es mittlerweile ein Brennprogramm, dass alles kann (auch DVDs mastern, transkodieren, evtl. blueray support)

barristan schrieb:

Warum Reiser4 nicht im Kernel ist: http://kernelnewbies.org/WhyReiser4IsNotIn

Warum alle immer so auf Performance abfahren ist mir eh fraglich.

Ein Dateisystem muss in erster Linie zuverlässig arbeiten, dann kann man auf die Performance schauen.

Jep

Jedes Dateisystem ohne Journal dürfte langsamer sein als eins mit (FAT32 ist auch schneller als NTFS beispielsweise).

Du meintest effektiv Jedes Dateisystem mit Journal dürfte langsamer sein 😉. Natürlich bedeutet ein Journal einen gewissen Zusatzaufwand, wobei es da auch auf den Verwendungszweck ankommt. Bei ner Platte die wenige aber riesige Dateien aufnehmen muss, wie zB. bei Überwachungssystemen dürfte das Journaling kaum noch eine Rolle spielen.

Was ich noch schön fände, wenn ein Dateisystem herauskommt, dessen Größe (sowohl vergrößern wie verkleinern) man im gemounteten Zustand ändern kann. Bis jetzt geht das nur, wenn man die Dateisysteme vorher aufhängt, was bei / mit etwas Aufwand verbunden ist (von CD booten usw.). Bei NTFS geht das problemlos 😉.

Bei NTFS gehts auch gerne mal im offline Modus in die Hose. Wir sprechen da noch immer von einem Closed-Source Dateisystem, bei dem Hersteller von Partitionierungsprogrammen raten müssen, wie das Ding wirklich funktioniert. Ansonsten kann man seit Ext2 immerhin online vergrößern. Verkleinern ist problematisch, weil dazu die Daten in einem möglichst zusammenhängenden Block geschrieben sein müssten, was jedes Dateisystem extrem unperformant und auch nicht unbedingt datensicherer macht.

Aber dass es oft viele OpenSource Projekte gibt, die das gleiche machen ist schon teilweise schlimm.

Bestes Beispiel gnash und swfdec. Beide wollen das selbe, aber keines der Plugins funktioniert wirklich toll und könnte adobe flash plugin ersetzen. Oder gibt es mittlerweile ein Brennprogramm, dass alles kann (auch DVDs mastern, transkodieren, evtl. blueray support)

Hmmm ich weiß jetzt nicht wie du den Gedankensprung machst, aber es ist ganz okey dass viele Projekte das gleiche machen, denn eigentlich ist es nicht das gleiche, sondern ähnliches. Die Projekte folgen unterschiedlichen Methologien, bieten unterschiedliche Teilfunktionen und erreichen so unterschiedliche Teilziele, von denen andere Projekte wieder lernen können. Wenn jedes Gebiet nur durch ein Projekt beackert würde, und man damit dessen Resultate als State-Of-The-Art betrachten müsste, gäbe es weder Innovation noch Motivation. Auch OpenSource Projekte befinden sich in einem gewissen Wettkampf, auch wenn meist nur der eigene Ehrgeiz belohnt wird 😉. Was gnash uns swfdec angeht, verweise ich wieder auf Closed-Source. Die einzelnen Flashformate sind nur teilweise und noch nicht besonders lang offengelegt. Ich zolle den Entwicklern Respekt unter diesen Bedingungen überhaupt soweit gekommen zu sein. Das sie weiter wären, wenn sie zusammen dasselbe gemacht hätten bezweifel ich stark. Was das Brennprogramm angeht, wer braucht sowas? Und wieso bist du der Meinung, dass DVDs mastern Teil eines Brennprogrammes sein sollte? Ich mach ja auch nicht meinen Videoschnitt mit Office, bloß weil man Filme einbetten kann. Aber na ja, dank der Vielfältigkeit wird es sicher ein Team geben, das auch das umsetzt, und ein anderes, dass eher mein Geschmack trifft. Wunderbare Welt 😉

Greebo schrieb:

Bei NTFS gehts auch gerne mal im offline Modus in die Hose. Wir sprechen da noch immer von einem Closed-Source Dateisystem, bei dem Hersteller von Partitionierungsprogrammen raten müssen, wie das Ding wirklich funktioniert. Ansonsten kann man seit Ext2 immerhin online vergrößern. Verkleinern ist problematisch, weil dazu die Daten in einem möglichst zusammenhängenden Block geschrieben sein müssten, was jedes Dateisystem extrem unperformant und auch nicht unbedingt datensicherer macht.

150 GB meiner NTFS partition abzwacken dauert hier 2 Min auf meiner Vista Maschiene und wenn es unsicher wäre, würde es nicht unterstützt werden. Im übrigen kannst du die winapi dazu verwenden, somit müssen Programme von Drittherstellern nichts raten oder ausprobieren. Man muss einfach anerkennen, dass manche Dinge an NTFS eben nicht schlecht sind und dass das mount System von Linux durchaus eine Überarbeitung gebrauchen könnte. Vor allem sieht man das bei entfernbaren Medien wie CDs oder USB Stick. Kein Program bekommt mit, wenn ich den Stick einfach rausziehe (unter win kommt sofort eine Fehlermeldung), sondern es wird weiterhin fleißig vorsichhin kopiert oder gerippt (Rhythmbox rippt auch weiter, wenn ich die CD auswerfe, hängt sich einfach auf...)

Hmmm ich weiß jetzt nicht wie du den Gedankensprung machst, aber es ist ganz okey dass viele Projekte das gleiche machen, denn eigentlich ist es nicht das gleiche, sondern ähnliches. Die Projekte folgen unterschiedlichen Methologien, bieten unterschiedliche Teilfunktionen und erreichen so unterschiedliche Teilziele, von denen andere Projekte wieder lernen können. Wenn jedes Gebiet nur durch ein Projekt beackert würde, und man damit dessen Resultate als State-Of-The-Art betrachten müsste, gäbe es weder Innovation noch Motivation. Auch OpenSource Projekte befinden sich in einem gewissen Wettkampf, auch wenn meist nur der eigene Ehrgeiz belohnt wird 😉. Was gnash uns swfdec angeht, verweise ich wieder auf Closed-Source. Die einzelnen Flashformate sind nur teilweise und noch nicht besonders lang offengelegt. Ich zolle den Entwicklern Respekt unter diesen Bedingungen überhaupt soweit gekommen zu sein. Das sie weiter wären, wenn sie zusammen dasselbe gemacht hätten bezweifel ich stark. Was das Brennprogramm angeht, wer braucht sowas?

Natürlich ist flash nicht offengelegt, darum geht es doch nicht, es geht darum, dass es zwei Projekte gibt, die exakt das gleiche wollen: Das proprietäre flash plugin ersetzen. Und statt, dass Manpower zusammengelegt wird, wird sie aufgeteilt.

Warum ich da darauf komme, naja der Threadstarter hat ja das ganze ebenfalls kritisiert.

Und wieso bist du der Meinung, dass DVDs mastern Teil eines Brennprogrammes sein sollte? Ich mach ja auch nicht meinen Videoschnitt mit Office, bloß weil man Filme einbetten kann. Aber na ja, dank der Vielfältigkeit wird es sicher ein Team geben, das auch das umsetzt, und ein anderes, dass eher mein Geschmack trifft. Wunderbare Welt 😉

Videos Dateien auswählen und als VideoDVD Brennen ist genauso ein Arbeitsschritt wie mp3s auswählen und als Audio CD brennen, oder machst du das noch getrennt? Oder hast du auch ein extra Program, dass dir erst deine Dateien zu einer .iso zusammenfasst und die du dann mit einem anderem Programm brennst. Wie lange gibt es jetzt DVDs und immernoch gibt es keine ordenltiche Brennsoftware für Linux. Ich rede auch nicht davon Videos zu schneiden oder diese zu bearbeiten, so wie du es ja machst, das macht man vorher mit einem anderen Programm, aber das transkodieren usw. sollte das Brennprogramm übernehmen.

Die Linuxcommunity redet sich mal wieder alles schön, aber kenne ich ja, schließlich bin ich ja lange genug dabei (seit 94)

barristan schrieb:

Greebo schrieb:

Bei NTFS gehts auch gerne mal im offline Modus in die Hose. Wir sprechen da noch immer von einem Closed-Source Dateisystem, bei dem Hersteller von Partitionierungsprogrammen raten müssen, wie das Ding wirklich funktioniert. Ansonsten kann man seit Ext2 immerhin online vergrößern. Verkleinern ist problematisch, weil dazu die Daten in einem möglichst zusammenhängenden Block geschrieben sein müssten, was jedes Dateisystem extrem unperformant und auch nicht unbedingt datensicherer macht.

150 GB meiner NTFS partition abzwacken dauert hier 2 Min auf meiner Vista Maschiene und wenn es unsicher wäre, würde es nicht unterstützt werden. Im übrigen kannst du die winapi dazu verwenden, somit müssen Programme von Drittherstellern nichts raten oder ausprobieren.

Hast du zufällig nen Link zur entsprechenden Methode? Ich bin nur mit den Windows-APIs bis zu XP Zeiten halbwegs vertraut, und da wäre mir keine entsprechende Funktion bekannt. Ist das Ändern der Größe für alle NTFS Versionen möglich, oder nur für die 5er Serie? Der Schluß, dass etwas rein durch seine Unterstützung schon sicher ist, ist übrigens recht gefährlich. Es gibt genug Beispiele bei denen dieser Schluß schlicht und ergreifend falsch war, durch die meisten Systeme und Anwendungen hindurch.

Man muss einfach anerkennen, dass manche Dinge an NTFS eben nicht schlecht sind und dass das mount System von Linux durchaus eine Überarbeitung gebrauchen könnte. Vor allem sieht man das bei entfernbaren Medien wie CDs oder USB Stick. Kein Program bekommt mit, wenn ich den Stick einfach rausziehe (unter win kommt sofort eine Fehlermeldung), sondern es wird weiterhin fleißig vorsichhin kopiert oder gerippt (Rhythmbox rippt auch weiter, wenn ich die CD auswerfe, hängt sich einfach auf...)

Das ist weniger ein Problem des Mountverfahrens, sondern der eingesetzten Software, es steht jeder Software frei entsprechend auf ein unsicheres Entfernen zu reagieren, inklusive des verwendeten Desktopmanagers. Wenn ich per Console auf unsicher entfernten Medien arbeite bekomme ich genug Fehlermeldungen.

Hmmm ich weiß jetzt nicht wie du den Gedankensprung machst, aber es ist ganz okey dass viele Projekte das gleiche machen, denn eigentlich ist es nicht das gleiche, sondern ähnliches. Die Projekte folgen unterschiedlichen Methologien, bieten unterschiedliche Teilfunktionen und erreichen so unterschiedliche Teilziele, von denen andere Projekte wieder lernen können. Wenn jedes Gebiet nur durch ein Projekt beackert würde, und man damit dessen Resultate als State-Of-The-Art betrachten müsste, gäbe es weder Innovation noch Motivation. Auch OpenSource Projekte befinden sich in einem gewissen Wettkampf, auch wenn meist nur der eigene Ehrgeiz belohnt wird 😉. Was gnash uns swfdec angeht, verweise ich wieder auf Closed-Source. Die einzelnen Flashformate sind nur teilweise und noch nicht besonders lang offengelegt. Ich zolle den Entwicklern Respekt unter diesen Bedingungen überhaupt soweit gekommen zu sein. Das sie weiter wären, wenn sie zusammen dasselbe gemacht hätten bezweifel ich stark. Was das Brennprogramm angeht, wer braucht sowas?

Natürlich ist flash nicht offengelegt, darum geht es doch nicht, es geht darum, dass es zwei Projekte gibt, die exakt das gleiche wollen: Das proprietäre flash plugin ersetzen. Und statt, dass Manpower zusammengelegt wird, wird sie aufgeteilt.

Es gibt Synergieeffekte, keine Frage, es gibt aber auch Vorteile alternative Lösungsmöglichkeiten zu verfolgen, wie schon oben geschrieben. Letztendlich ist das aber so oder so müßig. Die Entwickler hinter den verschiedenen Projekten sind halt großteils unbezahlte Freiwillige, und machen ihr eigenes Ding oder nicht. Und wenn ein Entwickler den Ansatz eines anderen Projekts für fundamental falsch hält, sei es weil die API schlecht konstruiert ist, sei es weil die eingesetzten Techniken ihm nicht liegen, oder schlicht die Lizenz keine Zustimmung findet, gibt es einfach keinen schönen Kompromiss um die verschiedenen Parteien zusammenzufassen.

Warum ich da darauf komme, naja der Threadstarter hat ja das ganze ebenfalls kritisiert.

Das hatte ich nicht mehr in Erinnerung, dann ist es klar.

Und wieso bist du der Meinung, dass DVDs mastern Teil eines Brennprogrammes sein sollte? Ich mach ja auch nicht meinen Videoschnitt mit Office, bloß weil man Filme einbetten kann. Aber na ja, dank der Vielfältigkeit wird es sicher ein Team geben, das auch das umsetzt, und ein anderes, dass eher mein Geschmack trifft. Wunderbare Welt 😉

Videos Dateien auswählen und als VideoDVD Brennen ist genauso ein Arbeitsschritt wie mp3s auswählen und als Audio CD brennen, oder machst du das noch getrennt? Oder hast du auch ein extra Program, dass dir erst deine Dateien zu einer .iso zusammenfasst und die du dann mit einem anderem Programm brennst.

Ehrlich gesagt? Ja, ich mache das per Command-Line. Das gibt mir einfach mehr Kontrolle über die entstehende Audio-CD (CD-Text ja/nein, welche Abspielpausen etc.) das kann man natürlich auch mit einer All-In-Wonder Lösung machen, aber wozu soll ich die ganze Zeit Programmfeatures mit mir rumschleifen, die Speicher kosten und die Menüs zuballern, wenn ich alle paar Monate mal ne Audio-CD brenne.

Wie lange gibt es jetzt DVDs und immernoch gibt es keine ordenltiche Brennsoftware für Linux. Ich rede auch nicht davon Videos zu schneiden oder diese zu bearbeiten, so wie du es ja machst, das macht man vorher mit einem anderen Programm, aber das transkodieren usw. sollte das Brennprogramm übernehmen.

Siehe oben. Wenn ich soetwas brauche, verwende ich es lieber getrennt, und da gibt es genug Optionen DVD-Authoring. Zusätzlich ist man nicht künstlich an eine CD/DVD-Brenn Bibliothek gebunden. Das macht mir zumindest in der Praxis selbst keinen Ärger, aber es ist durchaus denkbar, dass Dinge wie Burn-Proof nicht von jeder Bibliothek unterstützt werden, so hat man mehr Freiheit.

Die Linuxcommunity redet sich mal wieder alles schön, aber kenne ich ja, schließlich bin ich ja lange genug dabei (seit 94)

Das macht sie häufig ja, aber ehrlich gesagt sehe ich da noch immer nicht das Problem.

Greebo schrieb:

Hast du zufällig nen Link zur entsprechenden Methode? Ich bin nur mit den Windows-APIs bis zu XP Zeiten halbwegs vertraut, und da wäre mir keine entsprechende Funktion bekannt. Ist das Ändern der Größe für alle NTFS Versionen möglich, oder nur für die 5er Serie? Der Schluß, dass etwas rein durch seine Unterstützung schon sicher ist, ist übrigens recht gefährlich. Es gibt genug Beispiele bei denen dieser Schluß schlicht und ergreifend falsch war, durch die meisten Systeme und Anwendungen hindurch.

Nein, habe gerade noch einmal gesucht, aber nichts gefunden, entweder es geht nicht, oder ich finde es nur nicht, jedenfalls funktioniert es mit dem Windows Eigenen Pratitionierungstool hervorragend, mehr will ich auch nicht 😉.

Ich habe jedenfalls noch keine Horrormeldungen auf Heise oder Golem gelesen, dass das on the fly vergrößern oder verkleinern Datenverlust verursacht und Vista ist ja jetzt auch schon ein bisschen raus (XP konnte soviel ich weiß das auch noch nicht), daher gehe ich davon aus, dass es nur mit einer sehr geringen Wahrscheinlichkeit (man kann ja bei Software Fehlfunktionen nie ausschließen) zu Fehlern kommt. Außerdem hätte die Linuxcommunity das ganze sicher genüsslich zerlegt und das wäre mir aufgefallen 😉

Das ist weniger ein Problem des Mountverfahrens, sondern der eingesetzten Software, es steht jeder Software frei entsprechend auf ein unsicheres Entfernen zu reagieren, inklusive des verwendeten Desktopmanagers. Wenn ich per Console auf unsicher entfernten Medien arbeite bekomme ich genug Fehlermeldungen.

Ja, dann steck einmal deinen USB stick ein, übertrage eine Große Datei mit "cp" und ziehe währenddessen den Stick raus, mal gucken wie gut da cp darauf reagiert. Bei Unix sind gemountete Partitionen ja nichts anderes als Verzeichnisse. Während der Zugriff beim normal versuch ein Benutztes Verzeichnis zu entfernen fehlschlägt gilt das halt nicht für Wechseldatenträger, da hindert mich niemand daran das ganze gewaltsam zu entfernen und das wird nicht abgefangen und bekommt soviel ich weiß auch kein Programm mit (wäre ja ein typischer Fall einer Ausnahme)

Es gibt Synergieeffekte, keine Frage, es gibt aber auch Vorteile alternative Lösungsmöglichkeiten zu verfolgen, wie schon oben geschrieben. Letztendlich ist das aber so oder so müßig. Die Entwickler hinter den verschiedenen Projekten sind halt großteils unbezahlte Freiwillige, und machen ihr eigenes Ding oder nicht. Und wenn ein Entwickler den Ansatz eines anderen Projekts für fundamental falsch hält, sei es weil die API schlecht konstruiert ist, sei es weil die eingesetzten Techniken ihm nicht liegen, oder schlicht die Lizenz keine Zustimmung findet, gibt es einfach keinen schönen Kompromiss um die verschiedenen Parteien zusammenzufassen.

Naja ich nenne es Zeitverschwendung, aber ich lasse dir deine Meinung, ist ja schön, wenn man auch mal anderer Meinung ist 😉.

Ehrlich gesagt? Ja, ich mache das per Command-Line. Das gibt mir einfach mehr Kontrolle über die entstehende Audio-CD (CD-Text ja/nein, welche Abspielpausen etc.) das kann man natürlich auch mit einer All-In-Wonder Lösung machen, aber wozu soll ich die ganze Zeit Programmfeatures mit mir rumschleifen, die Speicher kosten und die Menüs zuballern, wenn ich alle paar Monate mal ne Audio-CD brenne.

Wieviel Ram hast du 128MB? und noch ne 2GB Festplatte? Gerade wenn jemand nur alle paar Monate etwas bringt, ist ne GUI was feines, weil man sich die ganzen Befehle nicht merken muss. Ich persönlich muss auch jedesmal wieder nachsehen, wie ich mit cdrdao eine CD lösche, obwohl es ja simpel ist, nur mir fällt der Befehl halt nicht ein.

Bei einer GUI sehe ich das ganze ja und ich muss es nur anklicken. Zeitlich effizienter ist sicher das Consolentool, wenn ich es beherrsche ohne Frage, aber schneller ans Ziel komme ich mit einer GUI, wenn ich das ganze vorher noch nie gemacht habe.

Siehe oben. Wenn ich soetwas brauche, verwende ich es lieber getrennt, und da gibt es genug Optionen DVD-Authoring. Zusätzlich ist man nicht künstlich an eine CD/DVD-Brenn Bibliothek gebunden. Das macht mir zumindest in der Praxis selbst keinen Ärger, aber es ist durchaus denkbar, dass Dinge wie Burn-Proof nicht von jeder Bibliothek unterstützt werden, so hat man mehr Freiheit.

Welche Bibliotheken? Soviel ich weiß verwenden alle Brennprogramme entweder cdrecord und/oder cdrdao binary zum Brennen. Soviel Auswahl hast du da letzlich auch nicht.

Das macht sie häufig ja, aber ehrlich gesagt sehe ich da noch immer nicht das Problem.

Schlimm ist ist nicht, nur ob es hilfreich ist naja.

frindly schrieb:

und an anderer ecke wird dann btrfs entwickelt. was.... ja wie ext4 auch wieder ähnliche ziele hat

[ ] Du hast btrfs verstanden.

Wir wollen für unsere nicht Temp-Dateisysteme alle btrfs, nur die meisten wissen es nicht. Eigentlich wollen wir ZFS, aber das hat mit Linux Lizenzprobleme.

Ich will mal kurz aufzählen was wir mit so einen morderen Dateisystem wie ZFS kriegen würden:

• Eingebautes Crypto. Einfach mal locker das System verschlüsseln.

• Checksums. Wenn unsere Datenträger Mist machen erfahren wir das zumindestens.

• Sinnvolle verteilung von Dateisystemen über mehrere Physikalische Platten, wo genau von der Festplatte mit richtiger checksum Daten genommen werden

• Snapshots aka bugfreie inkrementelle Backups

Wer mehr mit seinem Computer macht, als etwas Videos schauen, surfen und Spiele spielen, sollte sich dieser Punkte bewusst sein. Weil manche Leute zu inkompetent sind auf Datensicherheit zu achten gehen Haufenweise wichtige Daten verloren.

Alle anderen Dateisystem sind allerhöchstens Kinderspielzeuge. Momentan würde ich bei ernstzunehmenden Server Solaris statt Linux einsetzen, nur weil es bei Linux kein stabiles Dateisystem für Erwachsene gibt.

Sobald FreeBSD verlässlich von ZFS booten kann, bin ich weg von Linux.

Ich habe auch etwas mit ZFS rumgespielt, als ich OpenSolaris installiert hatte (warum verwendest du das nicht?) und war von den Funktionen auch begeistert.

blard schrieb:

und an anderer ecke wird dann btrfs entwickelt. was.... ja wie ext4 auch wieder ähnliche ziele hat

[ ] Du hast btrfs verstanden.

Muss das sein? Hier ist nicht das Heise Forum.

Wir wollen für unsere nicht Temp-Dateisysteme alle btrfs, nur die meisten wissen es nicht. Eigentlich wollen wir ZFS, aber das hat mit Linux Lizenzprobleme.

Ja die CDDL Inkompatibilität ist echt ein Drama.

• Eingebautes Crypto. Einfach mal locker das System verschlüsseln.

• Checksums. Wenn unsere Datenträger Mist machen erfahren wir das zumindestens.

• Sinnvolle verteilung von Dateisystemen über mehrere Physikalische Platten, wo genau von der Festplatte mit richtiger checksum Daten genommen werden

• Snapshots aka bugfreie inkrementelle Backups

Sabber! Und dann noch einen bezahlbaren Massenspeicher der nicht nach jedem kleinen Stoß abraucht...

Naja, hoffendlich wird in naher Zukunft etwas Vernünftiges aus btrfs.

Sobald FreeBSD verlässlich von ZFS booten kann, bin ich weg von Linux.

Ist das nicht schon der Fall? Was ist eigendlich aus Hammer geworden?

Grüße
Thomas

barristan schrieb:

Greebo schrieb:

Hast du zufällig nen Link zur entsprechenden Methode? Ich bin nur mit den Windows-APIs bis zu XP Zeiten halbwegs vertraut, und da wäre mir keine entsprechende Funktion bekannt. Ist das Ändern der Größe für alle NTFS Versionen möglich, oder nur für die 5er Serie? Der Schluß, dass etwas rein durch seine Unterstützung schon sicher ist, ist übrigens recht gefährlich. Es gibt genug Beispiele bei denen dieser Schluß schlicht und ergreifend falsch war, durch die meisten Systeme und Anwendungen hindurch.

Nein, habe gerade noch einmal gesucht, aber nichts gefunden, entweder es geht nicht, oder ich finde es nur nicht, jedenfalls funktioniert es mit dem Windows Eigenen Pratitionierungstool hervorragend, mehr will ich auch nicht 😉.

Ich habe jedenfalls noch keine Horrormeldungen auf Heise oder Golem gelesen, dass das on the fly vergrößern oder verkleinern Datenverlust verursacht und Vista ist ja jetzt auch schon ein bisschen raus (XP konnte soviel ich weiß das auch noch nicht), daher gehe ich davon aus, dass es nur mit einer sehr geringen Wahrscheinlichkeit (man kann ja bei Software Fehlfunktionen nie ausschließen) zu Fehlern kommt. Außerdem hätte die Linuxcommunity das ganze sicher genüsslich zerlegt und das wäre mir aufgefallen 😉

Ah okey, hätte mich einfach nur interessiert, wie die API dafür strukturiert ist. Horrormeldungen erwarte ich so oder so nicht, da das ändern einer Partition eine so ungebräuchliche Operation ist, dass die meisten Normalnutzer wahrscheinlich noch nie damit in Kontakt gekommen sind. Und die vernünftigeren Nutzer/Firmen machen vor solchen Operationen eh nen Backup (Bzw. machen keins aber reden dann auch nicht drüber, weils peinlich ist 😉).

Das ist weniger ein Problem des Mountverfahrens, sondern der eingesetzten Software, es steht jeder Software frei entsprechend auf ein unsicheres Entfernen zu reagieren, inklusive des verwendeten Desktopmanagers. Wenn ich per Console auf unsicher entfernten Medien arbeite bekomme ich genug Fehlermeldungen.

Ja, dann steck einmal deinen USB stick ein, übertrage eine Große Datei mit "cp" und ziehe währenddessen den Stick raus, mal gucken wie gut da cp darauf reagiert. Bei Unix sind gemountete Partitionen ja nichts anderes als Verzeichnisse. Während der Zugriff beim normal versuch ein Benutztes Verzeichnis zu entfernen fehlschlägt gilt das halt nicht für Wechseldatenträger, da hindert mich niemand daran das ganze gewaltsam zu entfernen und das wird nicht abgefangen und bekommt soviel ich weiß auch kein Programm mit (wäre ja ein typischer Fall einer Ausnahme)

Für mich erstaunlicherweise kommt wirklich standardmäßige keine Fehlermeldung, wenn man auf den Stick kopiert, wobei die Verzeichnisthese für mich nicht überzeugend ist, denn das Übertragen von Daten orientiert sich auf den unteren Ebenen eben doch noch an physischen Blöcken, insofern muss in irgendeiner Form mindestens der Kernel ein "wildes" Beschreiben auf umgemappte Sektoren unterdrücken. Ausnahme bildet da vielleicht ein Ausstecken in der kurzen Lücke zwischen zwei Dateien. Bei versuchen von einem solchen Gerät zu lesen kommt immerhin mal ein

cp: Lesen von „foo.bar“: Input/output error

was durchaus dafür spricht, dass die Daten angemessen "RAW" gelesen werden. Da müsste ich mich aber wirklich mehr in die Materie einarbeiten, was glaube mir gerade den Aufwand nicht wert ist, sorry.

Es gibt Synergieeffekte, keine Frage, es gibt aber auch Vorteile alternative Lösungsmöglichkeiten zu verfolgen, wie schon oben geschrieben. Letztendlich ist das aber so oder so müßig. Die Entwickler hinter den verschiedenen Projekten sind halt großteils unbezahlte Freiwillige, und machen ihr eigenes Ding oder nicht. Und wenn ein Entwickler den Ansatz eines anderen Projekts für fundamental falsch hält, sei es weil die API schlecht konstruiert ist, sei es weil die eingesetzten Techniken ihm nicht liegen, oder schlicht die Lizenz keine Zustimmung findet, gibt es einfach keinen schönen Kompromiss um die verschiedenen Parteien zusammenzufassen.

Naja ich nenne es Zeitverschwendung, aber ich lasse dir deine Meinung, ist ja schön, wenn man auch mal anderer Meinung ist 😉.

Ich nenne es optimale Aquise von humanen Kapital 🐸 , und wie gesagt es hat durchaus auch seine Vorteile.

Ehrlich gesagt? Ja, ich mache das per Command-Line. Das gibt mir einfach mehr Kontrolle über die entstehende Audio-CD (CD-Text ja/nein, welche Abspielpausen etc.) das kann man natürlich auch mit einer All-In-Wonder Lösung machen, aber wozu soll ich die ganze Zeit Programmfeatures mit mir rumschleifen, die Speicher kosten und die Menüs zuballern, wenn ich alle paar Monate mal ne Audio-CD brenne.

Wieviel Ram hast du 128MB? und noch ne 2GB Festplatte? Gerade wenn jemand nur alle paar Monate etwas bringt, ist ne GUI was feines, weil man sich die ganzen Befehle nicht merken muss. Ich persönlich muss auch jedesmal wieder nachsehen, wie ich mit cdrdao eine CD lösche, obwohl es ja simpel ist, nur mir fällt der Befehl halt nicht ein.

Mein Multimediarechner hat wirklich 128MByte RAM, gut geschätzt 😀, das ist aber zugegebenermaßen eher ne Ausnahme. Wichtiger ist mir aber wirklich die Ergonomie, und da sehe ich eben keinen Sinn darin seltene Funktionen mitzuschleifen. Mein Standardbrennformat ist eben zu weit über 90% hundsgemeine Daten-CD/DVD. Und dafür reicht selbst die Nautilus Brennansicht aus. Befehle fallen mir übrigens auch gerne mal nicht ein, dafür führe ich einerseits intern ne Liste praktischer Snippets(Nur zur Sicherheit) und definiere andererseits entsprechende Aliase/Functions. Im Fall AudioCD reicht bei mir in der simpelsten Form ein

burn-audio -r $MUSIKVERZEICHNIS

nicht wirklich schwer zu merken 😉.

Bei einer GUI sehe ich das ganze ja und ich muss es nur anklicken. Zeitlich effizienter ist sicher das Consolentool, wenn ich es beherrsche ohne Frage, aber schneller ans Ziel komme ich mit einer GUI, wenn ich das ganze vorher noch nie gemacht habe.

Ob jetzt GUI oder CLI darüber kann man sich trefflich unterschiedlicher Meinung sein. Für einen absoluten Anfänger ist die GUI sicher vertrauter, ich wollte damit auch nicht anpreisen alles per Console zu machen, mir geht es einfach um die Modularisierung der einzelnen Funktionen. Von mir aus darfs auch ein Brennprogramm sein, bei dem einzelne Zusatzfunktionen als Plugins hinzufügbar sind. Das ist halt vom programmiertechnischen ein sehr viel höherer Aufwand, deswegen machts wohl keiner. Solange reichts mir aber auch meine benötigten Funktionen als Einzelapplikationen aufrufen zu können.

Siehe oben. Wenn ich soetwas brauche, verwende ich es lieber getrennt, und da gibt es genug Optionen DVD-Authoring. Zusätzlich ist man nicht künstlich an eine CD/DVD-Brenn Bibliothek gebunden. Das macht mir zumindest in der Praxis selbst keinen Ärger, aber es ist durchaus denkbar, dass Dinge wie Burn-Proof nicht von jeder Bibliothek unterstützt werden, so hat man mehr Freiheit.

Welche Bibliotheken? Soviel ich weiß verwenden alle Brennprogramme entweder cdrecord und/oder cdrdao binary zum Brennen. Soviel Auswahl hast du da letzlich auch nicht.

cdrkit zB. noch welches nen Fork von cdrtools(cdrecord) ist. Wie gesagt aktuelle Probleme habe ich da auch keine (Na ja gut DVD-RAM funktioniert nicht so toll). Ich bin aber gespannt ob das so bleibt wenn sie anfangen Blueray in tausend Standards zu zergliedern.

Das macht sie häufig ja, aber ehrlich gesagt sehe ich da noch immer nicht das Problem.

Schlimm ist ist nicht, nur ob es hilfreich ist naja.

Im Prinzip bleibt da nur aus meinem letzten Posting. In der letzten Konsequenz kann jeder freiwillig freiwillig werken woran er will. Und offensichtlich will halt nicht jeder an ein und demselben Monumentalprojekt arbeiten (und nicht jedes Monumentalprojekt nimmt jeden an), warum das so ist, liegt ist schwer zu sagen, bestimmt aber nicht an gezielter unproduktivität 😉.

barristan schrieb:

Ich habe auch etwas mit ZFS rumgespielt, als ich OpenSolaris installiert hatte (warum verwendest du das nicht?) und war von den Funktionen auch begeistert.

Weil ich die denkbar inkompatibelste Hardware habe... Plattencontroller sagt immer nur, dass er nicht will. Von Sound wlan und random usb Schreibfehlern will ich gar nicht erst anfangen.

primus pilus schrieb:

blard schrieb:

• Eingebautes Crypto. Einfach mal locker das System verschlüsseln.

• Checksums. Wenn unsere Datenträger Mist machen erfahren wir das zumindestens.

• Sinnvolle verteilung von Dateisystemen über mehrere Physikalische Platten, wo genau von der Festplatte mit richtiger checksum Daten genommen werden

• Snapshots aka bugfreie inkrementelle Backups

Sabber! Und dann noch einen bezahlbaren Massenspeicher der nicht nach jedem kleinen Stoß abraucht...

Noch besser ist in den ersten 2 Wochen nur so sterben... Aber zum Glück sind die SSD Preise schon stetig am sinken.

Naja, hoffendlich wird in naher Zukunft etwas Vernünftiges aus btrfs.

Wollte das mal auf etwas freien speicher mit Ubuntu austesten. Dabei ist mir aufgefallen, dass es klugerweise die btfs tools in den Paketquellen gibt, aber der Kerneltreiber nicht zu finden ist ☹ Ich bin von Gentoo weggegangen, weil ich eben keine Kernel mit geratenen Einstellungen mehr neu bauen will, und erstmal 2 Tage brauche um eine Ordentliche config hinzukriegen.

Sobald FreeBSD verlässlich von ZFS booten kann, bin ich weg von Linux.

Ist das nicht schon der Fall? Was ist eigendlich aus Hammer geworden?

Das Problem ist halt die Verlässlichkeit. Da gibt es zwar schon sowas zusammengehacktes, aber ich will damit wirklich ausfallsicher arbeiten können.