Große Datei kann nicht auf ext2 USB-Stick kopiert werden [geschlossen]


10

Ich habe einen 8G-USB-Stick (ich bin unter Linux Mint) und ich versuche, eine 5.4G-Datei darin zu kopieren, bekomme aber

No space left on device

Die Dateigröße der kopierten Datei vor dem Fehlschlagen beträgt immer 3,6 G.

Eine Ausgabe des montierten Sticks zeigt ..

df -T
/dev/sdc1      ext2       7708584    622604   6694404   9% /media/moo/ba20d7ab-2c46-4f7a-9fb8-baa0ee71e9fe

df -h
/dev/sdc1       7.4G  608M  6.4G   9% /media/moo/ba20d7ab-2c46-4f7a-9fb8-baa0ee71e9fe

du -h --max-depth=1
88K ./.ssh

ls -h myfile 
-rw-r--r-- 1 moo moo 5.4G May 26 09:35 myfile

Eine 5.4G-Datei scheint also nicht auf einem 8G-USB-Stick zu funktionieren. Ich dachte, es gibt keine Probleme mit ext2 und es gab nur Probleme mit fat32 für Dateigrößen und USB-Sticks? Würde eine Änderung der Formatierung einen Unterschied machen?

Bearbeiten: Hier ist ein Bericht von Tunefs für das Laufwerk


sudo tune2fs -l /dev/sdd1

Filesystem volume name: Last mounted on: /media/moo/ba20d7ab-2c46-4f7a-9fb8-baa0ee71e9fe Filesystem UUID: ba20d7ab-2c46-4f7a-9fb8-baa0ee71e9fe Filesystem magic number: 0xEF53 Filesystem revision #: 1 (dynamic) Filesystem features: ext_attr resize_inode dir_index filetype sparse_super large_file Filesystem flags: signed_directory_hash Default mount options: (none) Filesystem state: not clean with errors Errors behavior: Continue Filesystem OS type: Linux Inode count: 489600 Block count: 1957884 Reserved block count: 97894 Free blocks: 970072 Free inodes: 489576 First block: 0 Block size: 4096 Fragment size: 4096 Reserved GDT blocks: 477 Blocks per group: 32768 Fragments per group: 32768 Inodes per group: 8160 Inode blocks per group: 510 Filesystem created: Mon Mar 2 13:00:18 2009 Last mount time: Tue May 26 12:12:59 2015 Last write time: Tue May 26 12:12:59 2015 Mount count: 102 Maximum mount count: 26 Last checked: Mon Mar 2 13:00:18 2009 Check interval: 15552000 (6 months) Next check after: Sat Aug 29 14:00:18 2009 Lifetime writes: 12 GB Reserved blocks uid: 0 (user root) Reserved blocks gid: 0 (group root) First inode: 11 Inode size: 256 Required extra isize: 28 Desired extra isize: 28 Default directory hash: half_md4 Directory Hash Seed: 249823e2-d3c4-4f17-947c-3500523479fd FS Error count: 62 First error time: Tue May 26 09:48:15 2015 First error function: ext4_mb_generate_buddy First error line #: 757 First error inode #: 0 First error block #: 0 Last error time: Tue May 26 10:35:25 2015 Last error function: ext4_mb_generate_buddy Last error line #: 757 Last error inode #: 0 Last error block #: 0


Könnte es sein, dass Sie oder Ihre Tools in Bezug auf GB und GiB verwirrt sind? Und da es ext2 ist, wie viel Speicherplatz ist für root reserviert (standardmäßig sind dies 5%).
0xC0000022L

Danke, wie kann ich feststellen, wie viel Platz reserviert ist?
Ian

@ Ian Um Dateisysteminformationen anzuzeigen, verwenden Sie:tune2fs -l /dev/<device>
Marco

3
Ihr Dateisystem weist Fehler auf. Führen Sie fsckdas Dateisystem aus und überprüfen / löschen Sie den Inhalt von lost+found. Beachten Sie auch, dass 385 MB für root reserviert sind (97894 Blöcke). Möglicherweise möchten Sie diesen Wert mit anpassen tune2fs.
Marco

1
Vielen Dank, das funktioniert jetzt. umount und sudo e2fsck / dev / sdd1 scheinen es behoben zu haben (hatten mehrfach beanspruchte Blockfehler, möglicherweise aufgrund früherer Fehler, da derselbe Dateiname erwähnt wurde). Wenn Sie es als Antwort festlegen möchten, wird akzeptiert.
Ian

Antworten:


9

Ihr 8-GB-Stick hat ungefähr 7,5 GiB und sollte auch mit etwas Dateisystem-Overhead in der Lage sein, die 5,4-GB-Datei zu speichern.

Sie verwenden tune2fs, um den Status und die Eigenschaften des Dateisystems zu überprüfen:

tune2fs -l /dev/<device>

Standardmäßig sind 5% des Speicherplatzes für den Root-Benutzer reserviert. Ihre Ausgabe listet 97894 Blöcke auf, was ungefähr 385 MB entspricht und der Standardwert zu sein scheint. Möglicherweise möchten Sie diesen Wert mithilfe von anpassen, tune2fswenn Sie nicht so viel reservierten Speicherplatz benötigen. Trotzdem sollte die Datei auch mit diesen 385 MB auf das Dateisystem passen.

Ihre tune2fsAusgabe zeigt ein unreines Dateisystem mit Fehlern. Also bitte fsckauf dem Dateisystem ausführen . Dadurch werden die Fehler behoben und möglicherweise einige Dateien im lost+foundVerzeichnis abgelegt . Sie können sie löschen, wenn Sie nicht beabsichtigen, die Daten wiederherzustellen.

Dies sollte das Dateisystem reparieren und das Kopieren der Datei wird erfolgreich sein.


-3

Ok, ich weiß, dass ich ein Windows-Benutzer bin, kein Linux-Benutzer, aber ich hatte vor einiger Zeit ein ähnliches Problem, als ich versuchte, Dateien auf einen 16Gig-Datenstick zu kopieren, um sie von und zu einem alten Laptop zu übertragen. Wie sich herausstellte, unterstützen die meisten Dateisystemformate für Wechselmedien (ext2, fat32 usw.) das Kopieren von Dateien nicht, wenn die Datei größer als 3,2 GB ist, da normalerweise Standardspeicherplatz für Root und System reserviert ist Dateien usw. Ich habe normalerweise eine Fehlermeldung erhalten, dass das Laufwerk voll ist (obwohl es völlig leer und frisch formatiert war).

Nach einigen Recherchen stellte ich fest, dass das NTFS-Dateisystem am besten zum Übertragen großer Dateien vom System auf den Stick geeignet ist, da es das einzige Dateisystem ist, mit dem Dateien über 3.2 problemlos kopiert werden können.

Ich weiß nicht, ob dies hilfreich sein wird, aber es ist immer eine mögliche Lösung.


4
leider für Sie ext2 tatsächlich tut Unterstützung so große Dateien und neben der Grenze für FAT32 ist 2 GiB ohne LFS, 4 GiB mit und 256 GiB mit FAT32 + ( Quelle ).
0xC0000022L
Durch die Nutzung unserer Website bestätigen Sie, dass Sie unsere Cookie-Richtlinie und Datenschutzrichtlinie gelesen und verstanden haben.
Licensed under cc by-sa 3.0 with attribution required.