Thema: Linux-Dateisysteme diverses

[SiLæncer]

NTFS-3G nutzt das Filesystem in Userspace

Schon bei der Ankündigung des NTFS-3G-Treibers für Linux wurde dieser als weitgehend stabil bezeichnet. Nun antworten die Entwickler ständigen Nachfragen nach dem Beta-Status damit, dass sie die aktuelle Version kurzerhand zum Release Candidate gemacht haben. Sollten keine großen Probleme auftauchen, so wird NTFS-3G in absehbarer Zeit als fertige Version veröffentlicht.

Das Filesystem in Userspace - oder FUSE - erlaubt es, Dateisystemtreiber im Userspace zu nutzen. Der Nutzer kann somit unabhängig vom Kernel Dateisysteme einbinden. Im Linux-Kernel ist FUSE enthalten, außerdem existieren Portierungen für BSD-Varianten. Google stellte zuletzt FUSE für MacOS X vor. Der NTFS-3G-Treiber nutzt FUSE, um auf mit dem Microsoft-Dateisystem formatierte Datenträger zuzugreifen.

Hauptsächlich habe man die aktuelle Version zum Release Candidate gemacht, da der Treiber weitgehend stabil sei, so die Entwickler. Viele Fehler, die man für Probleme in NTFS-3G gehalten hätte, entpuppten sich als Fehler anderer Software. Nun sollen noch Fehler im Release Candidate gemeldet werden - blieben die aus, so solle bald die stabile Version erscheinen, heißt es in der Ankündigung. NTFS-3G benötigt mindestens FUSE 2.6 und warnt, sofern das fehlerhafte Modul der Version 2.6.2 installiert ist. Beim Einbinden einer NTFS-Partition nutzt der Treiber nun auf Wunsch sämtliche Mount-Optionen wie "umask" oder "fmask". Zudem wurde der Quelltext überarbeitet, damit er besser mit FUSE für MacOS X zusammenarbeitet.

Mit Ntfs-Config gibt es ein grafisches Programm, um Dateisysteme über NTFS-3G einzuhängen. Der Release Candidate von NTFS-3G steht ab sofort zum Download bereit.

http://www.ntfs-3g.org/index.html#download

Quelle : www.golem.de

[SiLæncer]

Der freie NTFS-Treiber für Linux ntfs-3g hat die Versionsnummer 1.0 erreicht. Projektleiter Szabolcs Szakacsits erklärte den Treiber, der sich nach dem vor zwei Wochen erschienenen Release-Kandidaten nicht mehr verändert hat, fertig für den Produktiveinsatz. Szakacsits ist auch der Autor des Tools ntfsresize, das in vielen Partitionierungswerkzeugen und Linux-Installationsroutinen zum Einsatz kommt.

Nachdem Anton Altaparmakow, Hauptautor des aktuellen NTFS-Treibers, seine Bemühungen auf NTFS-Unterstützung für Mac OS X kontentrierte, arbeitete Szakacsits weiter an dem quelloffenen Code-Base des Treibers. Im Sommer 2006 stellte er die Software in einer ersten – schon sehr brauchbaren – Beta-Fassung vor.

Mit dem auf FUSE aufsetzenden ntfs-3g lassen sich Dateien (sofern sie nicht verschlüsselt oder komprimiert sind) auf NTFS-Partitionen modifizieren,löschen und erstellen. Auch wenn NTFS-Berechtigungen noch nicht unterstützt werden, dürfte der komplette Schreibzugriff auf Windows-Partionen unter Linux damit wieder etwas näher gerückt sein.

Quelle : www.heise.de

[SiLæncer]

Ein Bug-Report im Bug-Tracker für die kommende Version 9.04 von Ubuntu (Jaunty Jackalope) beschreibt einen massiven Datenverlust beim Einsatz von Ext4, dem zukünftigen Standard-Dateisystem von Linux, das Ubuntu 9.04 bei der Installation anbieten soll. Dabei gingen bei einemm Systemabsturz kurz nach dem Laden des KDE-4-Desktops die Daten aller Dateien verloren, in die beim Booten geschrieben wurde – darunter auch zahlreiche KDE-Konfigurationsdateien.

In seiner Antwort erläutert Ext4-Entwickler Ted Ts'o die Hintergründe für dieses Problem. Wie andere moderne Dateisysteme, etwa XFS, implementiert Ext4 delayed allocation – der zum Schreiben neuer Daten erforderliche Platz wird erst mit bis zu 60 Sekunden Verzögerung festgelegt. Das steigert die Performance und erlaubt Optimierungen der Datenorganisation auf der Platte.

Wenn nun eine Anwendung, wie es offenbar die Desktops KDE und Gnome tun, in kurzer Zeit eine große Zahl kleiner Dateien (nämlich die Konfigurationsdateien für die persönlichen Einstellungen) einlesen und neu schreiben und danach das System abstürzt, kann es sein, dass zu diesem Zeitpunkt für die Daten noch gar kein Platz auf der Platte alloziert wurde – die Dateien sind dann alle leer. Dabei hilft auch das Journal nicht, das die Konsistenz der Metadaten sicherstellt: Die Inodes referenzieren ganz korrekt und konsistent keinerlei Datenblöcke. Die genauen technischen Details (entscheidend sind die Systemcalls ftruncate() und rename()) finden sich in Teds Antwort.

Ted Ts'o beschreibt einen Workaround, der versucht, genau diesen Fall zu erkennen und in diesem Fall auf die delayed allocation zu verzichten, weist aber darauf hin, dass auch andere moderne Dateisystem wie XFS und das neue Btrfs von dem Problem betroffen sind. Die Patches werden aber wohl erst in den Kernel 2.6.30 einziehen – in den nächsten Wochen steht erst einmal die Veröffentlichung von 2.6.29 an.

Eigentlich, so der Dateisystementwickler, müsste man allerdings die betroffenen Anwendungen fixen: Die Programmierer hätten sich daran gewöhnt, dass mit Ext3 die Zeit bis zum tatsächlichen Schreiben der Daten höchstens fünf Sekunden beträgt und dass Änderungen an den Metadaten mit der Ext3-Standardoption "data=ordered" erst dann als bestätigt gelten, wenn die Daten tatsächlich auf die Platte geschrieben sind. Diese Annahmen würden mit modernen Dateisystemen nicht mehr gelten.

Quelle : http://www.heise.de/newsticker/Moeglicher-Datenverlust-bei-Ext4--/meldung/134346

[SiLæncer]

Ext4-Entwickler Ted Ts'o hat für das kommende Standard-Dateisystem eine neue Mount-Option eingeführt, die den möglichen Datenverlust bei Ext4 verhindert. In bestimmten Situationen kann es bei Ext4 vorkommen, dass nach einem Systemabsturz bereits bestehende Dateien, die kurz vor dem Crash neu beschrieben wurden, leer sind. Die Mount-Option "alloc_on_commit" sorgt dafür, dass in diesem Fall wie bei Ext3 der alte Dateiinhalt bestehen bleibt.

Siehe dazu auch auf heise open:

    * Kernel-Log: Beutelteufel vorübergehend Linux-Maskottchen, Hintergründe zum Ext4-Problem, Erläuterung des Ext4-Problems und Beschreibung der Lösung

Quelle : www.heise.de

[SiLæncer]

Das finnische Unternehmen Tuxera hat eine umfangreiche Zusammenarbeit mit Microsoft beschlossen. Dadurch soll Tuxera unter anderem in der Lage sein, einen exFAT-Treiber anzubieten.

Das Unternehmen Tuxera ging aus dem NTFS-3G-Projekt hervor, das an einem quelloffenen NTFS-Treiber arbeitet. Nun hat Tuxera ein Abkommen mit Microsoft im Bereich des geistigen Eigentums geschlossen und ist zusätzlich Microsofts exFAT-Programm (Extended File Allocation Table) beigetreten. Dadurch soll es Tuxera möglich sein, einen exFAT-Treiber anzubieten.

Denn durch das Abkommen hat Tuxera Zugriff auf die exFAT-Spezifikationen und auf Microsofts Implementierung des Dateisystems. Der Treiber soll zuerst für Linux verfügbar sein. ExFAT ist ein verhältnismäßig junges Dateisystem, das als Standard für die SDXC-Karten festgelegt wurde.

Ferner ist Tuxera der Interop Vendor Alliance beigetreten. Die Interop Vendor Alliance hat Microsoft ins Leben gerufen, um sicherzustellen, dass die Software von Drittherstellern besser mit Microsoft-Systemen arbeitet.

Quelle : www.golem.de

[SiLæncer]

Mit Next3 haben die Entwickler bei CTERA Networks ein Dateisystem für Linux veröffentlicht, das mit dem Ext3-Dateisystem kompatibel sein soll und zusätzlich eine Snapshot-Funktion mitbringt. Next3 steht unter der GPL.

Das Dateisystem Next3 für Linux unterstützt Snapshots auf Dateisystemebene. Es soll darüber hinaus weitgehend kompatibel zu seinem Linux-Pendant Ext3 sein, es kann beispielsweise als solches in das System eingebunden werden.

Bei der Erstellung eines Snapshots wird ein Magic-File in Form einer Sparse-Datei im Dateisystem abgelegt. Lediglich Änderungen am Dateisystem werden in den Snapshots registriert, dabei werden von Änderungen betroffene Blöcke dort zunächst gespeichert, bevor sie im Dateisystem überschrieben werden. Snapshots können lesend als Ext2-Loopback eingebunden werden.

Next3 will in den Kernel

Auch mit den zusätzlichen Schreibvorgängen in den Snapshots sollen die Schreibzugriffe nahezu genauso schnell sein wie die des Ext3-Dateisystems. Allerdings fragmentiert die Verlagerung veränderter Blöcke in die Snapshot das Dateisystem und drückt damit langfristig die Lesegeschwindigkeit. Mit einem speziellen Flag kann die Fragmentierung ausgewählter Dateien jedoch explizit verhindert werden. Enthält das Next3-Dateisystem Snapshots, kann es nur noch lesend als Ext3 eingebunden werden.

Anfang Mai reichte CTERA Networks den Code für Next3 bei den Kernel-Entwicklern ein. Der für Dateisysteme zuständige Kernel-Entwickler Ted T‘so moniert allerdings, dass sich die Entwicklung des Kernel-Teams gegenwärtig auf Ext4 konzentriert und dass es sich bei Next3 eigentlich um einen Fork handelt. T‘so schlägt stattdessen vor, die Snapshot-Funktion von Next3 in Ext4 einzubinden. Die Portierung auf das neuere Dateisystem sei allerdings schwierig, so der zuständige Entwickler bei CTERA Networks, Amir Goldstein.

Das größte Problem liegt bei der Verlagerung von Blöcken in ein Snapshot auf Grund der neuen Extent-Funktionen in Ext4. Zusätzlich haben die Entwickler von Next3 einige Datenstrukturfelder übernommen, die Ext4 für andere Zwecke verwendet. Das wiederum würde bedeuten, dass die Verwaltungswerkzeuge e2fsprogs erweitert werden müssten, um beide Dateisystemformate zu unterstützen, was T‘so ablehnt.

Während also die Kernel-Entwickler die Snapshot-Funktion gerne in die bestehenden Dateisysteme übernehmen möchten, will CTERA Networks Next3 als eigenständiges Dateisystem im Kernel sehen.

Next3 kommt unter anderem auf dem NAS-Gerät C200 der Firma zum Einsatz. Patches für den Linux-Kernel 2.6.32.12 und die e2fsprogs 1.41.12 liegen auf den Sourceforge-Servern des Projekts zum Download bereit.

Quelle : www.golem.de

[ritschibie]

Die aktuelle Community-Version des Ntfs-3g-Treibers für Linux und Mac OS X erhält Optimierungen bei der Datenkompression.
Zahlreiche Reparaturen verbessern die Option zur Größenanpassung.

Mit etlichen Änderungen hat Ntfs-3g-Hersteller Tuxera die Community-Version 2012.1.15 seines Ntfs-Treibers für Linux, Mac OS X und BSD veröffentlicht. Unter den wesentlichen Neuerungen listet das Unternehmen eine verbesserte Unterstützung für die Datenkompression auf. Sie soll nicht nur Schreib- und Lesezugriffe auf das Dateisystem beschleunigen, sondern auch in das dazugehörige Kopierwerkzeug Ntfscp integriert worden sein.

Das Reparaturprogramm Ntfsfix kommt mit den sogenannten Dirty Flags bei der Prüfung von Ntfs-Dateisystemen besser zurecht. Mit einer neuen Option kann die Liste defekter Datenblöcke gelöscht werden. Das Wiederherstellungswerkzeug Ntfsundelete versucht, auch den Dateinamen einer gelöschten Datei wiederherzustellen. Funktioniert das nicht, verwendet das Werkzeug stattdessen die Inode-Nummer (File Record).

Ntfs-3G auch für Android und Haiku

Ntfs-3G wird als Fuse-Treiber in das Betriebssystem eingebunden und bringt zahlreiche Werkzeuge zur Verwaltung des Dateisystems für die Windows-NT-Reihe mit. Er steht nicht nur für Linux, Mac OS X oder BSD-Varianten zur Verfügung, sondern auch für Solaris und dessen Abkömmlinge, etwa Openindiana, Haiku und QNX sowie Android.

Im April 2011 wurden die bislang parallel geführten Projekte Ntfsprogs und Ntfs-3G zusammengelegt. Der Code war zu komplex geworden, so dass sich die Entwickler zu diesem Schritt entschlossen, um doppelten Code zu vermeiden und die Stabilität und Funktionalität zu garantieren.

Exfat nur proprietär

Tuxera ging im Jahr 2009 ein Abkommen mit Microsoft ein, um die Verwendung von geistigem Eigentum abzusichern. Gleichzeitig erwarb die Firma einen Einblick in Microsofts Exfat-Dateisystem und entwickelte daraufhin einen entsprechenden Treiber, allerdings nur eine proprietäre Variante. Der NTFS-3G-Treiber wird hingegen sowohl unter der GPLv2 als auch unter einer proprietären Lizenz vertrieben. Ob das Unternehmen auch mit der Entwicklung eines Treibers für Microsofts neues ReFS-Dateisystem begonnen hat, ist noch nicht bekannt.

Der Quellcode kann von der Webseite des Unternehmens heruntergeladen werden. Eine Liste aller Änderungen haben die Entwickler in den entsprechenden Release Notes zusammengefasst.

Quelle: www.golem.de

[ritschibie]

Ein Bug im Code des Dateisystems Ext4 im aktuellen stabilen Linux-Kernel 3.6.3 kann unter bestimmten Bedingungen zu einem Datenverlust führen. Grund dafür ist eine Änderung in der Kernelversion 3.6.2, schreibt Ext4-Entwickler Ted Ts'o, der bereits einen Patch für den Fehler bereitgestellt hat.

[Update 25.10., 8:00]

Die urprüngliche Diagnose von Ted Ts'o hat sich inzwischen als falsch oder zumindest unvollständig herausgestellt, wie der Ext4-Entwickler schreibt. Offenbar zeigt sich das Problem nur, wenn das System nicht sauber heruntergefahren wird, sodass das Dateisystem nicht sauber gelöst wird; es tritt aber auch dann nicht immer auf. Ted Ts'o weist darauf hin, dass viele Fedora-User bereits den Kernel 3.6.2 verwenden, ohne dass es zu massenhaften Problemen gekommen sei.

Der Ext4-Entwickler hat mittlerweile eine neue Theorie zu der Ursache des Bugs und auch gleich einen neuen Patch bereitgestellt. Da aber, wie Ts'o schreibt, noch nicht völlig klar ist, unter welchen genauen Umständen der Fehler auftritt, ist nicht sicher, dass dieser Patch das Problem endgültig löst.

[/Update]

Der Fehler tritt lediglich auf, wenn das Journal auf Block 0 des Dateisystems die Liste der Transaktionen auf Block 0 des Journals beginnt, was bereits spezielle Optionen beim Anlegen des Dateisystems erfordert. Wenn in diesem Fall das Dateisystem zweimal kurz hintereinander gemountet und gelöst wird, kann es passieren, dass die im Journal gespeicherten Transaktionen durcheinander geraten, sodass sie beim Mounten nicht in der korrekten Reihenfolge zurückgespielt werden. Das kann schlimmstenfalls zu fehlerhaften Metadaten und damit zu Datenverlust führen.

Ted Ts'o bezeichnet den Fehler als "Lance Armstrong bug", bei dem der Code niemals in einem Test auffällt, sich aber trotzdem nicht so verhält, wie er sollte. In seinem Posting auf der Linux Kernel Mailinglist mit dem nur wenige Zeilen langen Patch entschuldigt er sich, dass ihm der Fehler nicht schon beim Sichten des Codes für den Kernel 3.6.2 aufgefallen sei. Betroffen von dem Bug ist auch die Kernelserie 3.5, in die der Bug zurückportiert wurde.

Quelle: www.heise.de

[SiLæncer]

Die Ext4-Entwickler sind dem gestern bekannt gewordenen Bug im Linux-Dateisystem Ext4 offenbar auf die Spur gekommen. Wie Ted Ts'o schreibt, lässt sich der Bug nur unter "sehr esoterischen" Bedingungen reproduzieren – für die allermeisten Anwender dürfte keine Gefahr bestehen.

Der ganze Artikel

Quelle : www.heise.de

[SiLæncer]

Der letzte Woche bekannt gewordene Ext4-Bug tritt offenbar nur bei Kombination mehrerer gefährlicher Mount- und Umount-Optionen auf und ist damit für nahezu alle Linux-Anwender harmlos – bislang ist er lediglich bei einem User aufgetreten. Dennoch will Ext4-Hauptentwickler Ted Ts'o Konsequenzen aus dem Vorfall ziehen.

Wie Ts'o auf Google+ schreibt, waren zwei der kritischen Mount-Optionen (journal_checksum und journal_async_commit) lediglich für Entwickler gedacht und werden wohl in der nächsten Ext4-Version für Anwender nicht mehr zur Verfügung stehen. Zudem sei schon länger geplant gewesen, dass bei der Benutzung anderer als der Standard-Mountoptionen eine Warnung ausgegeben wird; die Implementierung dieser Warnung werde jetzt eine höhere Priorität erhalten.

Auch wenn man jetzt die Bedingungen, unter denen der Ext4-Bug auftritt, recht genau kennt, forschen die Ext4-Entwickler immer noch an den Details, wie die Kombinationen von Lazy Umount und den speziellen Mount-Optionen zu Fehlern im Dateisystem führen. Ts'o hat einen neuen Patch für Ext4 geschrieben, möchte aber zunächst abwarten, ob damit der Fehler bei dem betroffenen User nicht mehr auftritt.

Quelle : www.heise.de

[SiLæncer]

Die Ursache des vor einer Woche aufgefallenen Bugs im Linux-Dateisystem Ext4 ist gefunden. Ext4-Chefentwickler Ted Ts'o hat einen wenige Zeilen langen Patch geschrieben und zur Aufnahme in den Kernel 3.7 bereitgestellt. Mit dem Patch soll das Problem, das lediglich bei Verwendung unüblicher Mount-Optionen auftritt und dann zu Fehlern im Dateisystem führen kann, behoben sein. Ts'o hat darüberhinaus angekündigt, einige wenig getestete und daher potenziell gefährliche Mount-Optionen zu deaktivieren oder zumindest mit Warnungen zu versehen.

Quelle : www.heise.de

[SiLæncer]

Der freie, auf FUSE beruhende Treiber für exFAT-Dateisysteme für Linux hat jetzt die Version 1.0.0 erreicht.

exFAT ist ein proprietäres und von Softwarepatenten belastetes Dateisystem von Microsoft für Flash-Medien, das vor einigen Jahren von der SD Card Association zum Standard für SDXC-Karten erklärt wurde. Für Linux gibt es mehrere Implementation des Dateisystems, um SDXC-Karten benutzen zu können. Einige sind von Microsoft lizenziert und daher nicht frei. Dazu zählt beispielsweise das Produkt von Tuxera.

Der ganze Artikel

Quelle : www.pro-linux.de

[SiLæncer]

Einige Kernel-Entwickler haben im Android-Tree einen Patch für eine Verschlüsselungsoption in Ext4 eingestellt, der gute Chancen auf die Aufnahme in den Main-Kernel hat.

Wie es aussieht, verstärkt Google seine Bemühungen, der kommenden Android-Generation eine performantere dateisystemiinterne Verschlüsselung zu spendieren. Jetzt hat ein Entwicklerteam um eCryptFS-Autor Michael Halcrow und Ext4-Maintainer Ted Ts'o einen Patch vorgestellt, der das Standarddateisystem von Linux und Android Ext4 um eine optionale Verschlüsselung erweitert. Im Hinblick auf den Einsatz auf Mobilgeräten konzentriert sich die Neuerung auf die Verschlüsselung der Dateiinhalte und -Namen – Metadaten wie Dateigröße oder Zugriffsrechte bleiben sichtbar. Die Inhalte verwendet die neue Option AES-256-XTS. Dabei generiert sie für jeden Inode eine individuellen 512-Bit-Key und nutzt diesen zum Verschlüsseln.

Einen ersten Überblick verschafft ein PDF mit Vortragsfolien von Halcrow und Ts'o [PDF], detailliertere Informationen liefert ein Google-Dokument mit der Design-Beschreibung, das laut Ts'o allerdings an einigen Stellen nicht mehr dem aktuellen Stand der Implementierung entspricht. So benutze man anstelle des im Design-Dokuments beschriebenen eigenartigen Verfahrens für die Verzeichniseinträge inzwischen AES-256-CBC mit Ciphertext Stealing (CTS). Die Integration direkt im Dateisystemtreiber verspricht geringere Performance-Einbußen im Betrieb, als sie beispielsweise bei eCryptFS und dm-crypt/LUKS anfallen, allerdings um den Preis der Sichtbarkeit von Metadaten.

Wenn nicht noch Unvorhergesehenes dazwischenkommt, hofft Ts'o dass die Patches bereits in die kommende Android-Version "M" einfließen werden. Darüber hinaus hat er sich mit Jaegeuk Kim, dem Maintainer des von einigen Android-Varianten eingesetzten Flash-Dateisystem f2fs über die Erweiterung des Treiber-Interfaces ausgetauscht. Ts'o möchte die Basisfunktionen möglichst schnell in den Mainline-Kernel integrieren, damit eventuell auch andere Dateisysteme von der Krypto-Option profitieren können.

Quelle & Links : http://www.heise.de/newsticker/meldung/Linux-Dateisysteme-Transparente-Verschluesselung-fuer-Ext4-in-Sicht-2599402.html