Ist ein Celeron M 430. Bin absolut zufrieden mit dem Laptop (HP Compaq NX6310), einzig die kurze Akkulaufzeit durch das fehlende Frequenzy Scaling ist nervig. Anstatt 3+ Stunden nur 2:10.
Ist noch kein großer Unterschied zu ext3 zu erkennen. Wenn man extents nutzt, ist es bei großen Dateien schon etwas flinker als ext3, ansonst nimmt es sich nicht viel.
Probiers nicht aus, wenn dir die Daten in irgendeiner Weise am Herzen liegen.
Die Kernelentwickler würden sich aber sicher über jeden Bugreport freuen, ganz bosonders solche die dir die Partition shreddern. Allerdings akzeptieren sie nur Bugreports von Kerneln die kein proprietäres Modul geladen haben, diese können nämlich die Nachvollziehbarkeit von Bugs empfindlich stören.
Fuer die portage-partition wäres vielleicht nen test wert. kann ja neu gesynct werden ;). Aber mit nvidia-module brauch ich auch keine bugreports schreiben
Von vicbrother am Do, 30. November 2006 um 11:27 #
Also dieses eCryptFS hört sich nett an. Bisher habe ich immer Angst, dass durch den Zugriff von Windows auf meine ext3-Notebookplatte ein Schlüssel zerschossen und damit die daten hinfällig werden. Aber dieses Gefahr scheint es bei eCryptFS nicht mehr zu geben oder?
Von vicbrother am Do, 30. November 2006 um 12:12 #
Ich hatte das so verstanden, das bei eCryptFS jede Datei den Public-Key in sich trägt, ich also meine Private-Key auf nem USB-Stick sichern kann. Bei einem Datencrash kann also eine Datei, nicht aber unbedingt eine ganze Partition verloren sein.
Stimmt. Bin ich jetzt ein Schwarzmaler, wenn ich den Ärger in gemischten SCSI-ATA-Systemen, womöglich noch mit temporären USB- oder FireWire-Massenspeichern, schon kommen sehe???
..schwarz wie die Nacht würd ich mal sagen :o) Hab gestern Abend mein System auf die neuen PATA Module umgestellt und die alten aus dem Kernel entfernt. Das System funktioniert einwandfrei. Auch der DVD-Brenner und diverse USB Geräte und sogwar meine externe FireWire Festplatte funktionieren perfekt.
Ich werde es 'mal testen. Ob das so Nachtschwarz ist? Neulich hat ein Bekannter gemeint, wenn er aus Versehen den USB-Stick beim Booten stecken hat, bricht Linux beim Booten mit Fehlermeldungen ab, weil es offensichtlich seine beiden SATA-Platten (bzw. wohl nur die zweite) dann nicht korrekt zuordnet ... (habs aber selbst nicht gesehen)
Der hatte diesen Fehler übrigens auch nicht am ersten Abend bemerkt sondern erst nach Wochen ;-)
Tja, notfalls kann man seine Partitionen ja noch über LABEL in der fstab zuordnen. Aber Lust habe ich dazu eigentlich keine und ob das zuverlässig auch bei Software-RAID funktioniert, weiß ich auch nicht ...
Für mich ist es jedenfalls unverständlich, warum man jetzt einerseits die Treiber örtlich trennt und gleichzeitig dieselben Bezeichnungen in der fstab einführt!
Von Compressors can dance am Do, 30. November 2006 um 15:01 #
Bin darauf gestossen das in diesem Kernel die alte API für 4vl nicht mehr empfohlen wird, stattdessen der v4l compatible Layer. In den Kerneloptionen kann man auch nur entweder das eine oder das andere auswählen. Bei der neuen API fehlen allerdings irgendwie die Treiber für bttv (Hauppauge TV-Karte) stattdessen stehen da nur einige Chipsatzhersteller.
Was hat es damit auf sich? Gibts die Treiber vielleicht gar nicht extra in der neuen API und die werden nun automatisch erkannt oder wie läuft das jetzt?
Irgendwie läufts bei mir nicht ganz rund, scheinen sich wieder einige Dinge geändert zu haben? - TV-Karte liess sich nicht zum laufen bewegen obwohl der Treiber geladen war. - Beim Portage (Gentoo) hatte ich Access Violations der Sandbox als ich Nvidia und fuse updaten wollte
Kann natürlich auch sein das es ein Fehler irgendwo von mir war. Bin erstmal wieder zurück auf einen 2.6.16 und damit läufts wunderprächtig.
> - TV-Karte liess sich nicht zum laufen bewegen obwohl der Treiber geladen war. Das Problem hatte ich beim .18er, jetzt geht sie wieder.
> - Beim Portage (Gentoo) hatte ich Access Violations der Sandbox als ich Nvidia und fuse updaten wollte Ich auch, zum Glück gibts ja FEATURES="-sandbox"
Ja, lag wohl daran. Bin nochmal einen Vanilla Kernel durchgegangen mit menuconfig anstatt oldconfig... Dann ging es!
Mit der Sandbox haben ich letztlich auch so gemacht, ist aber halt mehr ein dirty workaround das Sicherheitskonzept so auszuhebeln. Wird aber aber sicherlich bald gefixt sein hoffe ich mal
> Die gesamten Block-Gerätetreiber können mit einer Konfigurationsoption deaktiviert werden [...]
Endlich! Hat ganz schön gedauert, bis es akzeptiert wurde. Alles einzeln abwählen, auch wenn das ein Perl macht, ist ziemlich nervig und bei einer neuen Version muss erst jedesmal geprüft werden ob nicht doch einer durchkommt.
Ich bin nicht so der Kernelfreak, kann mir da jemand mal erklären, was damit gemeint ist? Blockgeräte sind doch die ganzen Dateisysteme, wie kommt man dann ohne aus?
oder so ähnlich
Danke, pl-team! Weiter so...
Die Kernelentwickler würden sich aber sicher über jeden Bugreport freuen, ganz bosonders solche die dir die Partition shreddern. Allerdings akzeptieren sie nur Bugreports von Kerneln die kein proprietäres Modul geladen haben, diese können nämlich die Nachvollziehbarkeit von Bugs empfindlich stören.
"Wer auf die neuen Treiber umsteigt, findet seine Geräte nicht mehr unter /dev/hdx, sondern unter /dev/sdx."
Bin ich jetzt ein Schwarzmaler, wenn ich den Ärger in gemischten SCSI-ATA-Systemen, womöglich noch mit temporären USB- oder FireWire-Massenspeichern, schon kommen sehe???
Hab gestern Abend mein System auf die neuen PATA Module umgestellt und die alten aus dem Kernel entfernt.
Das System funktioniert einwandfrei. Auch der DVD-Brenner und diverse USB Geräte und sogwar meine externe FireWire Festplatte funktionieren perfekt.
Ob das so Nachtschwarz ist? Neulich hat ein Bekannter gemeint, wenn er aus Versehen den USB-Stick
beim Booten stecken hat, bricht Linux beim Booten mit Fehlermeldungen ab, weil es offensichtlich
seine beiden SATA-Platten (bzw. wohl nur die zweite) dann nicht korrekt zuordnet ... (habs aber selbst nicht gesehen)
Der hatte diesen Fehler übrigens auch nicht am ersten Abend bemerkt sondern erst nach Wochen ;-)
Tja, notfalls kann man seine Partitionen ja noch über LABEL in der fstab zuordnen. Aber Lust habe
ich dazu eigentlich keine und ob das zuverlässig auch bei Software-RAID funktioniert, weiß ich
auch nicht ...
Für mich ist es jedenfalls unverständlich, warum man jetzt einerseits die Treiber örtlich trennt
und gleichzeitig dieselben Bezeichnungen in der fstab einführt!
In den Kerneloptionen kann man auch nur entweder das eine oder das andere auswählen. Bei der neuen API fehlen allerdings irgendwie die Treiber für bttv (Hauppauge TV-Karte) stattdessen stehen da nur einige Chipsatzhersteller.
Was hat es damit auf sich? Gibts die Treiber vielleicht gar nicht extra in der neuen API und die werden nun automatisch erkannt oder wie läuft das jetzt?
- TV-Karte liess sich nicht zum laufen bewegen obwohl der Treiber geladen war.
- Beim Portage (Gentoo) hatte ich Access Violations der Sandbox als ich Nvidia und fuse updaten wollte
Kann natürlich auch sein das es ein Fehler irgendwo von mir war. Bin erstmal wieder zurück auf einen 2.6.16 und damit läufts wunderprächtig.
Das Problem hatte ich beim .18er, jetzt geht sie wieder.
> - Beim Portage (Gentoo) hatte ich Access Violations der Sandbox als ich Nvidia und fuse updaten wollte
Ich auch, zum Glück gibts ja FEATURES="-sandbox"
b) altbekanntes Problem. Gibt einen patch, du kannst die gentoo-sources benutzen oder - huch - die sandbox für das nvidia-Modul und fuse ausmachen.
Mit der Sandbox haben ich letztlich auch so gemacht, ist aber halt mehr ein dirty workaround das Sicherheitskonzept so auszuhebeln. Wird aber aber sicherlich bald gefixt sein hoffe ich mal
Endlich! Hat ganz schön gedauert, bis es akzeptiert wurde. Alles einzeln abwählen, auch wenn das ein Perl macht, ist ziemlich nervig und bei einer neuen Version muss erst jedesmal geprüft werden ob nicht doch einer durchkommt.