# [SOLVED]UDF Dateisystem: Kein Speicherplatz obwohl nur 18%..

## V10lator

Ich suche schon seit langem nach einem guten Dateisystem für eine externe Festplatte. Fat32 fällt weg da es keine Dateien > 4 GB speichern kann, ich aber genau solche speichern möchte. NTFS bremst die per USB 3.0 angeschlossene Platte viel zu sehr aus und alles andere ist nicht Windows kompatibel.

Nun erfuhr ich das UTF genau das sein sollte was ich brauche, also habe ich die Platte mit

mkudffs --media-type=hd --blocksize=512

formatiert und fing fröhlich an Dateien zu kopieren bis ich plötzlich die Meldung erhielt "Auf dem Gerät ist kein Speicherplatz mehr verfügbar". Verwundert gab ich df -h welches mir sagte es seien noch 384 GB frei. Verdutzt versuchte ich sofort wieder eine Datei zu erstellen, doch:

```
$ touch /media/disk/foo

touch: „/media/disk/foo“ kann nicht berührt werden: Auf dem Gerät ist kein Speicherplatz mehr verfügbar
```

Woher kommt dieses falsche Limit und wie kann ich es beheben?

//EDIT: Gerade habe ich auch noch nachgesehen wie viele Inodes frei sind: Von 804791316 sind 57414 benutzt.

//EDIT²: Unter Windows (VM) kann ich problemlos Dateien hinzufügen.  :Sad: Last edited by V10lator on Fri Feb 22, 2013 2:12 pm; edited 1 time in total

----------

## ChrisJumper

 *Quote:*   

> NTFS bremst die per USB 3.0 angeschlossene Platte viel zu sehr aus und alles andere ist nicht Windows kompatibel.

 

Nun mir fällt aktuell kein besseres Format ein als NTFS, auch wenn ich dem NTF-3G Treiber unter Linux noch misstraue. Eben wenn es um Performance-Gründe geht kopiere ich Daten fast ausschließlich über Fileserver mit NFS4.

Die UDF Webseite macht einen relativ veralteten Eindruck und ist wenn ich mich nicht täusche auch eher ein Dateisystem für CD's,  DVD's und so weiter. Alternativ könntest du auch reiserfs Versuchen, dafür gibt es auch Treiber für Windows.. allerdings weiß ich halt nicht wie "bequem" es ist diese Einzubinden. ext3 geht unter Windows ja auch, hier hatte ich aber mit der GUI bei einer Freundin, für den schnellen Versuch schon Probleme die Datenträger einzuhängen.

Schau es dir einfach mal an und entscheide dann welches die beste Lösung für dich ist.

----------

## V10lator

 *ChrisJumper wrote:*   

> Nun mir fällt aktuell kein besseres Format ein als NTFS, auch wenn ich dem NTF-3G Treiber unter Linux noch misstraue.

 

Der Treiber scheint schon stabil zu sein, nur die Performance ist bescheiden. Wenn ich stat eine Stunde plötzlich einen Tag zum kopieren brauche ist das einfach ein no-go.

 *Quote:*   

> Die UDF Webseite macht einen relativ veralteten Eindruck und ist wenn ich mich nicht täusche auch eher ein Dateisystem für CD's,  DVD's und so weiter.

 

Richtig, UDF wurde primär für optische Medien entwickelt. Es wird aber von jedem Betriebsystem unterstützt und schadet auch nicht auf Festplatten. Es ist mit logging Dateisystemen wie JFFS2 vergleichbar.

 *Quote:*   

> Alternativ könntest du auch reiserfs Versuchen, dafür gibt es auch Treiber für Windows.. allerdings weiß ich halt nicht wie "bequem" es ist diese Einzubinden. ext3 geht unter Windows ja auch, hier hatte ich aber mit der GUI bei einer Freundin, für den schnellen Versuch schon Probleme die Datenträger einzuhängen.

 

Extra Treiber sind ein no-go. Ich arbeite ab und an an Computern ohne Admin rechte / die Erlaubniss Sachen zu verändern. Das Dateisystem muss also out of the box unterstützt werden.

Ansonsten entnehme ich deinem Post das ich wohl einen Bug in dem UDF Treiber entdeckt habe? Ich werde mal die kernel Bugs durchtöbern und sollte ich nichts finden einen neuen Report erstellen.

----------

## schmidicom

 *V10lator wrote:*   

> Das Dateisystem muss also out of the box unterstützt werden.

 

Da bleibt wirklich nicht viel zur Auswahl und so schnell wird sich das bei Produkten aus dem Hause Microsoft wohl auch nicht ändern. Das einzige was M$ dazu bringen könnte was anderes als ihren eigenen Mist zu unterstützen wäre vermutlich wenn das UEFI Konsortium beschließen würde das die EFI-Systempartition nicht mehr mit FAT32 laufen sollte.

 *V10lator wrote:*   

> Ansonsten entnehme ich deinem Post das ich wohl einen Bug in dem UDF Treiber entdeckt habe? Ich werde mal die kernel Bugs durchtöbern und sollte ich nichts finden einen neuen Report erstellen.

 

Da wäre ich mir nicht so sicher.

Habe gerade einen USB-Stick (2GB) mit UDF formatiert und unter Windows zeigt der Explorer an dieser wäre zu einem drittel voll obwohl nichts drauf ist.

----------

## V10lator

 *schmidicom wrote:*   

> Da bleibt wirklich nicht viel zur Auswahl und so schnell wird sich das bei Produkten aus dem Hause Microsoft wohl auch nicht ändern.

 

genau das ist ja mein Problem. Es bleibt nur FAT (fliegt raus da es keine Dateien > 4 GB unterstützt), NTFS (fliegt aus performance Gründen raus) und UDF.

 *Quote:*   

> Da wäre ich mir nicht so sicher.
> 
> Habe gerade einen USB-Stick (2GB) mit UDF formatiert und unter Windows zeigt der Explorer an dieser wäre zu einem drittel voll obwohl nichts drauf ist.

 

Komisch, das konnte ich weder mit Windows 7 noch mit Windows 8 reproduzieren. Auf der anderen Seite kann ich meinen Bug perfekt reproduzieren, egal ob ich unter Linux oder Windows formatiere.

//EDIT: Was mir gerade noch auffiel: Windows formatiert nicht die gesammte Partition. Ich vermute wegen wear-leveling. Eventuel macht Linux das selbe wenn du nicht mit --media-type=hd formatierst. Das könnte den belegten Speicher bei dir erklären.

----------

## schmidicom

 *V10lator wrote:*   

> Was mir gerade noch auffiel: Windows formatiert nicht die gesammte Partition. Ich vermute wegen wear-leveling. Eventuel macht Linux das selbe wenn du nicht mit --media-type=hd formatierst. Das könnte den belegten Speicher bei dir erklären.

 

Habe den USB-Stick hiermit formatiert:

```
mkudffs --media-type=hd --blocksize=512 /dev/sdb1
```

----------

## schmidicom

Wegen dem Bug, so ganz unrecht scheinst du nicht zu haben. Habe gerade eine 320GB USB-Harddisk einmal unter Gentoo und dann unter Windows mit UDF formatiert und mir ist dabei was aufgefallen.

Wenn die Harddisk unter Linux formatiert wird ist sie unter Windows angeblich zu 98% voll und kann somit nicht verwendet werden. Formatiere ich die Harddisk aber unter Windows als UDF mit Hilfe von diskpart sind gerade mal 75MB belegt und diese Anzeige ist dann auf beiden Systemen identisch.

----------

## V10lator

Das scheint aber ein anderer Bug zu sein.

BTW: Ich habe bereits einen Report erstellt: https://bugzilla.kernel.org/show_bug.cgi?id=53021

----------

## schmidicom

Vielleicht auch nicht, es geht ja in beiden Fällen um den verfügbaren Speicherplatz.

Versuch doch einfach mal test weise deine USB-Harddisk unter Windows mit UDF zu formatieren und dann unter Linux deine Daten darauf zu kopieren. Wenn es dann klappt ist wohl eher das Tool von sys-fs/udftools fehlerhaft als der Treiber im Kernel.

----------

## V10lator

Das habe ich bereits probiert: Selbes Problem.

----------

## schmidicom

Wie ich sehe hat Jan Kara eine Lösung für das Probleme gefunden, gz  :Wink: 

Vielleicht solltest du noch ein solved oben dran setzen?

Und was meinst du, ab welcher Kernelversion wird dieser fix drin sein?

----------

## V10lator

 *schmidicom wrote:*   

> Vielleicht solltest du noch ein solved oben dran setzen?

 

Sorry, total vergessen.  :Embarassed: 

 *Quote:*   

> Und was meinst du, ab welcher Kernelversion wird dieser fix drin sein?

 

Da Jan meinte er versucht es im nächsten merge window denke ich ab 3.9(-rc1)

----------

## schmidicom

 *V10lator wrote:*   

> Da Jan meinte er versucht es im nächsten merge window denke ich ab 3.9(-rc1)

 

Also muss man bis dahin wohl selbst patchen, könnte schlimmer sein.

Aber der eigentliche Autor von diesem Code wird doch sicher einen Grund gehabt haben warum er nicht gleich ein "int" daraus gemacht hat...

Hmm ich bin auf C nicht gut genug die folgen dieser Änderung zu erkennen aber ich hoffe mal für deine Daten das es passt, gib bescheid wenn was schief läuft.  :Smile: 

----------

## V10lator

 *schmidicom wrote:*   

> Aber der eigentliche Autor von diesem Code wird doch sicher einen Grund gehabt haben warum er nicht gleich ein "int" daraus gemacht hat...

 

Fehler sind menschlich und ohne gäbe es keinen Bug und damit auch keinen Fix.  :Wink: 

 *Quote:*   

> Hmm ich bin auf C nicht gut genug die folgen dieser Änderung zu erkennen aber ich hoffe mal für deine Daten das es passt, gib bescheid wenn was schief läuft. 

 

Ich bin auch nicht gut genug, konnte aber bis jetzt keine Fehler (vor allem keine neuen) entdecken. Ich nutze die Platte regelmässig und ausser langen mount zeiten (ist under Windows das selbe, scheint also eine Eigenart von UDF zu sein) funktioniert alles wie es soll und meine Daten scheinen konsistent zu bleiben.  :Smile: 

----------

## schmidicom

 *V10lator wrote:*   

> Ich nutze die Platte regelmässig und ausser langen mount zeiten (ist under Windows das selbe, scheint also eine Eigenart von UDF zu sein) funktioniert alles wie es soll und meine Daten scheinen konsistent zu bleiben. 

 

Das könnte aber vielleicht auch daran liegen das es für UDF keine ID gibt, alle Partitionen die als UDF formatiert werden bekommen die ID 6. Also wird vermutlich sowohl Windows als auch Linux zuerst krampfhaft versuchen das ganze mit FAT zu mounten und erst später merken das es was anderes nehmen sollte.

http://en.wikipedia.org/wiki/Partition_type

----------

## schmidicom

Ich habe gerade nachgesehen und die Änderung scheint nun im Kernel zu sein wenn gleich in etwas anderer Form.

Patch von "Jan Kara"

```
--- a/fs/udf/udf_sb.h

+++ b/fs/udf/udf_sb.h

@@ -82,7 +82,7 @@ struct udf_virtual_data {

 struct udf_bitmap {

    __u32         s_extLength;

    __u32         s_extPosition;

-   __u16         s_nr_groups;

+   int         s_nr_groups;

    struct buffer_head    **s_block_bitmap;

 };
```

Patch von kernel.org

```
--- a/fs/udf/udf_sb.h

+++ b/fs/udf/udf_sb.h

@@ -80,10 +80,9 @@ struct udf_virtual_data {

 };

 

 struct udf_bitmap {

-        __u32                   s_extLength;

         __u32                   s_extPosition;

-        __u16                   s_nr_groups;

-        struct buffer_head      **s_block_bitmap;

+        int                     s_nr_groups;

+        struct buffer_head      *s_block_bitmap[0];

 };

 

 struct udf_part_map {
```

----------

