Warum verfügt meine Partition mit genau 100 MiB bei 1 KiB Blockgröße nicht über den entsprechenden verfügbaren Block / Speicherplatz?


33

Ich habe eine virtualisierte Umgebung mit sehr hoher Dichte und Containern, daher versuche ich, jeden Container wirklich klein zu machen. "Wirklich klein" bedeutet 87 MB auf Basis Ubuntu 14.04 (Trusty Tahr), ohne die Paketmanager-Kompatibilität zu beeinträchtigen.

Daher verwende ich LVM als Hintergrundspeicher für meine Container und habe kürzlich sehr merkwürdige Zahlen gefunden. Hier sind sie.

Lassen Sie uns ein logisches Volumen von 100 MiB (yeah, Potenz von 2) erstellen.

sudo lvcreate -L100M -n test1 /dev/purgatory

Ich möchte die Größe überprüfen, also stelle ich aus sudo lvs --units k

test1             purgatory  -wi-a----  102400.00k

Süß, das sind wirklich 100 MiB.

Jetzt machen wir ein ext4- Dateisystem. Und natürlich erinnern wir uns an -m 0Parameter, die Platzverschwendung verhindern.

sudo mkfs.ext4 -m 0 /dev/purgatory/test1

mke2fs 1.42.9 (4-Feb-2014)
Filesystem label=
OS type: Linux
Block size=1024 (log=0)
Fragment size=1024 (log=0)
Stride=0 blocks, Stripe width=0 blocks
25688 inodes, 102400 blocks
0 blocks (0.00%) reserved for the super user
First data block=1
Maximum filesystem blocks=67371008
13 block groups
8192 blocks per group, 8192 fragments per group
1976 inodes per group
Superblock backups stored on blocks:
        8193, 24577, 40961, 57345, 73729

Allocating group tables: done
Writing inode tables: done
Creating journal (4096 blocks): done
Writing superblocks and filesystem accounting information: done

Süß und sauber. Beachten Sie die Blockgröße - unser logisches Volumen ist klein, daher hat mkfs.ext4 beschlossen, einen Block mit einer Größe von 1 KB zu erstellen, nicht die üblichen 4 KB.

Jetzt werden wir es montieren.

sudo mount /dev/purgatory/test1 /mnt/test1

Und rufen dfwir ohne Parameter auf (wir möchten 1 KiB-Blöcke sehen)

/dev/mapper/purgatory-test1     95054    1550     91456   2% /mnt/test1

Warten Sie, oh shi ~

Wir haben insgesamt 95054 Blöcke. Aber das Gerät selbst hat 102400 Blöcke von 1 KiB. Wir haben nur 92,8% unseres Speichers. Wo sind meine Blöcke, Mann?

Schauen wir es uns an einem echten Blockgerät an. A hat eine virtuelle 16-GiB-Festplatte mit 16777216 1-KB-Blöcken, aber nur 15396784 Blöcke sind in der df-Ausgabe enthalten. 91,7%, was ist das?

Nun folgt die Untersuchung (Spoiler: keine Ergebnisse)

  1. Dateisystem konnte nicht am Anfang des Geräts beginnen. Das ist seltsam, aber möglich. Glücklicherweise hat ext4 magische Bytes, lassen Sie uns ihre Anwesenheit überprüfen.

    sudo hexdump -C / dev / purgatory / test1 | grep "53 ef"

Dies zeigt Superblock:

00000430  a9 10 e7 54 01 00 ff ff  53 ef 01 00 01 00 00 00  |...T....S.......|

Hex 430 = Dez 1072, also irgendwo nach dem ersten Kilobyte. Sieht vernünftig aus, ext4 überspringt die ersten 1024 Bytes für Merkwürdigkeiten wie VBR usw.

  1. Das ist Zeitschrift!

Nein ist es nicht. Journal nimmt Platz aus Verfügbar, wenn df ausgegeben wird.

  1. Oh, wir haben dump2fs und könnten die Größen dort überprüfen!

... viele Greps ...

sudo dumpe2fs /dev/purgatory/test1 | grep "Free blocks"

Autsch.

Free blocks:              93504
  Free blocks: 3510-8192
  Free blocks: 8451-16384
  Free blocks: 16385-24576
  Free blocks: 24835-32768
  Free blocks: 32769-40960
  Free blocks: 41219-49152
  Free blocks: 53249-57344
  Free blocks: 57603-65536
  Free blocks: 65537-73728
  Free blocks: 73987-81920
  Free blocks: 81921-90112
  Free blocks: 90113-98304
  Free blocks: 98305-102399

Und wir haben eine andere Nummer. 93504 freie Blöcke.

Die Frage ist: Was ist los?

  • Gerät blockieren: 102400k (lvs sagt)
  • Dateisystemgröße: 95054k (df sagt)
  • Freie Blöcke: 93504k (dumpe2fs sagt)
  • Verfügbare Größe: 91456k (df sagt)

Deshalb verwende ich immer noch ext2für kleine Partitionen.
Frostschutz

@ Frostschutz ext2sieht hier vernünftig aus, sicher
maniaque

Antworten:


32

Versuche dies: mkfs.ext4 -N 104 -m0 -O ^has_journal,^resize_inode /dev/purgatory/test1

Ich denke, das lässt Sie verstehen, "was los ist".

-N 104 (Legen Sie die Anzahl der iNodes fest, die Ihr Dateisystem haben soll.)

  • Jeder iNode "kostet" nutzbaren Speicherplatz (128 Byte)

-m 0(keine reservierten Blöcke)
-O ^has_journal,^resize_inode(Deaktivieren Sie die Funktionen has_journalundresize_inode

  • resize_inode"kostet" freien Speicherplatz (die meisten der 1550 1K-Blöcke / 2%, die Sie in Ihrem df- 12K sehen, werden für den Ordner "lost + found" verwendet)
  • has_journalNutzfläche "kostet" (4096 1K-Blöcke in Ihrem Fall)

Wir 102348raus 102400, weitere 52 Blöcke unbrauchbar (wenn wir den Ordner "lost + found" gelöscht haben). Deshalb tauchen wir ein in dumpe2fs:

Group 0: (Blocks 1-8192) [ITABLE_ZEROED]
  Checksum 0x5ee2, unused inodes 65533
  Primary superblock at 1, Group descriptors at 2-2
  Block bitmap at 3 (+2), Inode bitmap at 19 (+18)
  Inode table at 35-35 (+34)
  8150 free blocks, 0 free inodes, 1 directories, 65533 unused inodes
  Free blocks: 17-18, 32-34, 48-8192
  Free inodes: 
Group 1: (Blocks 8193-16384) [BLOCK_UNINIT, ITABLE_ZEROED]
  Checksum 0x56cf, unused inodes 5
  Backup superblock at 8193, Group descriptors at 8194-8194
  Block bitmap at 4 (+4294959107), Inode bitmap at 20 (+4294959123)
  Inode table at 36-36 (+4294959139)
  8190 free blocks, 6 free inodes, 0 directories, 5 unused inodes
  Free blocks: 8193-16384
  Free inodes: 11-16
Group 2: (Blocks 16385-24576) [INODE_UNINIT, BLOCK_UNINIT, ITABLE_ZEROED]
  Checksum 0x51eb, unused inodes 8
  Block bitmap at 5 (+4294950916), Inode bitmap at 21 (+4294950932)
  Inode table at 37-37 (+4294950948)
  8192 free blocks, 8 free inodes, 0 directories, 8 unused inodes
  Free blocks: 16385-24576
  Free inodes: 17-24
Group 3: (Blocks 24577-32768) [INODE_UNINIT, BLOCK_UNINIT, ITABLE_ZEROED]
  Checksum 0x3de1, unused inodes 8
  Backup superblock at 24577, Group descriptors at 24578-24578
  Block bitmap at 6 (+4294942725), Inode bitmap at 22 (+4294942741)
  Inode table at 38-38 (+4294942757)
  8190 free blocks, 8 free inodes, 0 directories, 8 unused inodes
  Free blocks: 24577-32768
  Free inodes: 25-32
Group 4: (Blocks 32769-40960) [INODE_UNINIT, BLOCK_UNINIT, ITABLE_ZEROED]
  Checksum 0x79b9, unused inodes 8
  Block bitmap at 7 (+4294934534), Inode bitmap at 23 (+4294934550)
  Inode table at 39-39 (+4294934566)
  8192 free blocks, 8 free inodes, 0 directories, 8 unused inodes
  Free blocks: 32769-40960
  Free inodes: 33-40
Group 5: (Blocks 40961-49152) [INODE_UNINIT, BLOCK_UNINIT, ITABLE_ZEROED]
  Checksum 0x0059, unused inodes 8
  Backup superblock at 40961, Group descriptors at 40962-40962
  Block bitmap at 8 (+4294926343), Inode bitmap at 24 (+4294926359)
  Inode table at 40-40 (+4294926375)
  8190 free blocks, 8 free inodes, 0 directories, 8 unused inodes
  Free blocks: 40961-49152
  Free inodes: 41-48
Group 6: (Blocks 49153-57344) [INODE_UNINIT, BLOCK_UNINIT, ITABLE_ZEROED]
  Checksum 0x3000, unused inodes 8
  Block bitmap at 9 (+4294918152), Inode bitmap at 25 (+4294918168)
  Inode table at 41-41 (+4294918184)
  8192 free blocks, 8 free inodes, 0 directories, 8 unused inodes
  Free blocks: 49153-57344
  Free inodes: 49-56
Group 7: (Blocks 57345-65536) [INODE_UNINIT, BLOCK_UNINIT, ITABLE_ZEROED]
  Checksum 0x5c0a, unused inodes 8
  Backup superblock at 57345, Group descriptors at 57346-57346
  Block bitmap at 10 (+4294909961), Inode bitmap at 26 (+4294909977)
  Inode table at 42-42 (+4294909993)
  8190 free blocks, 8 free inodes, 0 directories, 8 unused inodes
  Free blocks: 57345-65536
  Free inodes: 57-64
Group 8: (Blocks 65537-73728) [INODE_UNINIT, BLOCK_UNINIT, ITABLE_ZEROED]
  Checksum 0xf050, unused inodes 8
  Block bitmap at 11 (+4294901770), Inode bitmap at 27 (+4294901786)
  Inode table at 43-43 (+4294901802)
  8192 free blocks, 8 free inodes, 0 directories, 8 unused inodes
  Free blocks: 65537-73728
  Free inodes: 65-72
Group 9: (Blocks 73729-81920) [INODE_UNINIT, BLOCK_UNINIT, ITABLE_ZEROED]
  Checksum 0x50fd, unused inodes 8
  Backup superblock at 73729, Group descriptors at 73730-73730
  Block bitmap at 12 (+4294893579), Inode bitmap at 28 (+4294893595)
  Inode table at 44-44 (+4294893611)
  8190 free blocks, 8 free inodes, 0 directories, 8 unused inodes
  Free blocks: 73729-81920
  Free inodes: 73-80
Group 10: (Blocks 81921-90112) [INODE_UNINIT, BLOCK_UNINIT, ITABLE_ZEROED]
  Checksum 0x60a4, unused inodes 8
  Block bitmap at 13 (+4294885388), Inode bitmap at 29 (+4294885404)
  Inode table at 45-45 (+4294885420)
  8192 free blocks, 8 free inodes, 0 directories, 8 unused inodes
  Free blocks: 81921-90112
  Free inodes: 81-88
Group 11: (Blocks 90113-98304) [INODE_UNINIT, BLOCK_UNINIT, ITABLE_ZEROED]
  Checksum 0x28de, unused inodes 8
  Block bitmap at 14 (+4294877197), Inode bitmap at 30 (+4294877213)
  Inode table at 46-46 (+4294877229)
  8192 free blocks, 8 free inodes, 0 directories, 8 unused inodes
  Free blocks: 90113-98304
  Free inodes: 89-96
Group 12: (Blocks 98305-102399) [INODE_UNINIT, ITABLE_ZEROED]
  Checksum 0x9223, unused inodes 8
  Block bitmap at 15 (+4294869006), Inode bitmap at 31 (+4294869022)
  Inode table at 47-47 (+4294869038)
  4095 free blocks, 8 free inodes, 0 directories, 8 unused inodes
  Free blocks: 98305-102399
  Free inodes: 97-104

und zähle die verwendeten Blöcke (für Backup-Superblock, Gruppendeskriptoren, Block-Bitmap, Inode-Bitmap und Inode-Tabelle) oder wir grepund zähle:

LANG=C dumpe2fs /dev/mapper/vg_vms-test1 | grep ' at ' | grep -v ',' | wc -l

das gibt uns die Anzahl der Zeilen, die einen einzelnen Block haben (in unserem Beispiel) und

LANG=C dumpe2fs /dev/mapper/vg_vms-test1 | grep ' at ' | grep ',' | wc -l

Das gibt uns die Anzahl der Zeilen, die zwei Blöcke haben (in unserem Beispiel).

Wir haben also (in unserem Beispiel) 13Zeilen mit jeweils einem Block und 19Zeilen mit jeweils zwei Blöcken.

13+19*2

Das gibt uns 51Blöcke, die von ext4 selbst verwendet werden. Schließlich ist nur noch ein Block übrig. Der Block 0, der die übersprungenen 1024Bytes am Anfang für Dinge wie den Bootsektor sind.


Und wenn das Journal nur 4096k benötigt, habe ich diese Nummer nicht (95054 - 4096)! = 91456?
Maniaque

Alle Zahlen hier sind in k, also 95054 k insgesamt - 4096 k Zeitschrift! = 91456 k verfügbar.
Maniaque

1
dfbei fs mit journal: 95054k - dfbei fs ohne jorunal 99150k - und mische nicht "nutzbaren" und "freien" speicherplatz.
xx4h

Einige Dateisysteme, z. B. xfs, weisen den Inodes nach Bedarf dynamisch Speicherplatz zu. Sie können xfs und btrfs ausprobieren, wenn Sie neugierig sind. mkfs.xfs -l size=512 -d agcount=1wird ein Dateisystem mit der absoluten minimalen Protokollgröße (aka Journalgröße) erstellen, aber die Schreibleistung kann darunter leiden. Ich glaube nicht, dass die XFS-Code-Unterstützung ohne Protokoll funktioniert. Möglicherweise schreibgeschützt, um Fälle zu unterstützen, in denen ein externes Protokollgerät defekt ist. (Auch agcount=1ist wahrscheinlich eine andere schreckliche Idee für Schreibleistung, vor allem parallel. Und Allokationsgruppen-Header sind wahrscheinlich auch klein.)
Peter Cordes

Bin neugierig geworden und habe XFS ausprobiert. Wenn es für Linux XFS eine Kombination von Optionen gibt, mit denen die minimale Protokollgröße auf das absolute Minimum von 512 Blöcken gesenkt werden kann, ist IDK das, was es ist. mkfs.xfs -d agcount=1auf einer 100MiB Partition stellte ein FS von 95980kiB, mit 5196k verwendet, 90784k zur Verfügung. Die Standardanzahl ist 4, und die Standardprotokollgröße beträgt 1605 Blöcke (ebenfalls das Minimum). Daher verwendet XFS ein so kleines Protokoll, wie Sie es für kleine FSes angeben möchten.
Peter Cordes

19

Die kurze Antwort:

Nicht der gesamte Speicherplatz auf dem Blockgerät wird verfügbarer Speicherplatz für Ihre Daten: Ein Teil des unformatierten Speicherplatzes wird für interne Dateisysteme benötigt, die Buchhaltung hinter den Kulissen.

Diese Buchhaltung umfasst den Superblock, Blockgruppendeskriptoren, Block- und Inode-Bitmaps und die Inode-Tabelle. Außerdem werden an mehreren Stellen Kopien des Superblocks für Sicherungs- / Wiederherstellungszwecke erstellt. Eine ausführliche Beschreibung der Interna des EXT4-Dateisystems finden Sie unter ext4.wiki.kernel.org .

Da EXT4 ein Journaled File-System ist, nimmt es auch etwas Platz ein.

Zusätzlich ist etwas Platz für zukünftige Erweiterungen des Dateisystems reserviert.

Die lange Antwort:

Ich habe Ihr Szenario auf einem meiner Testsysteme neu erstellt:

lvcreate -L 100M -n test MyVG
mkfs.ext4 -b 1024 /dev/MyVG/test 

Dann, noch bevor das Dateisystem gemountet wird, wird Folgendes dumpe2fsangezeigt:

Filesystem state:         clean
Errors behavior:          Continue
Filesystem OS type:       Linux
Inode count:              25688
Block count:              102400
Reserved block count:     5120
Free blocks:              93504
Free inodes:              25677
First block:              1
Block size:               1024
Fragment size:            1024
Reserved GDT blocks:      256
Blocks per group:         8192
Fragments per group:      8192
Inodes per group:         1976
Inode blocks per group:   247
Flex block group size:    16
Filesystem created:       Fri Feb 20 13:20:54 2015
Last mount time:          n/a
Last write time:          Fri Feb 20 13:20:55 2015
...
Journal size:             4096k  
...

und nach der Montage:

df /tmp/test/
Filesystem              1K-blocks  Used Available Use% Mounted on
/dev/mapper/MyVG-test       99150  5646     88384   7% /tmp/test

Was dfzeigt uns das? Von den 102400 Blöcken des Raw-Speichergeräts sind 99150 1-KB-Blöcke für das Dateisystem sichtbar, was bedeutet, dass 3250 1-Kilobyte-Blöcke Raw-Speicherplatz für die tatsächliche Datenspeicherung unbrauchbar geworden sind.

Wohin gingen diese Blöcke? Wenn Sie in der dumpe2fsAusgabe nach unten scrollen, sehen Sie genau, wo:

Group 0: (Blocks 1-8192) [ITABLE_ZEROED]
  Checksum 0x0d67, unused inodes 1965
  Primary superblock at 1, Group descriptors at 2-2
  Reserved GDT blocks at 3-258
  Block bitmap at 259 (+258), Inode bitmap at 275 (+274)
  Inode table at 291-537 (+290)
  4683 free blocks, 1965 free inodes, 2 directories, 1965 unused inodes
  Free blocks: 3510-8192
  Free inodes: 12-1976

1 block (Block # 0) Die ersten 1024 Bytes werden übersprungen, um die Installation von x86-Bootsektoren und anderen Kuriositäten zu ermöglichen.
1 block wird vom primären Superblock besetzt.
1 block enthält die Gruppendeskriptoren.
256 blockssind für die Gruppendeskriptortabelle reserviert, um eine spätere Größenänderung des Dateisystems zu ermöglichen. 16 blocks werden für die Block-Bitmap vergeben.
16 blockssind für die Inode-Bitmap zugewiesen.
246 blockssind der Inode-Tabelle zugeordnet.

Das sind bereits 537 der 3250 fehlenden Blöcke. Ein ext4-Dateisystem ist in eine Reihe von Blockgruppen unterteilt. Wenn Sie nach unten scrollen, wird eine ähnliche Zuordnung der Raw-Speicherkapazität zu den internen Dateisystemen in den anderen Blockgruppen angezeigt:

Group 1: (Blocks 8193-16384) [INODE_UNINIT, ITABLE_ZEROED]
  Checksum 0x0618, unused inodes 1976
  Backup superblock at 8193, Group descriptors at 8194-8194
  Reserved GDT blocks at 8195-8450
  Block bitmap at 260 (+4294959363), Inode bitmap at 276 (+4294959379)
  Inode table at 538-784 (+4294959641)
  7934 free blocks, 1976 free inodes, 0 directories, 1976 unused inodes
  Free blocks: 8451-16384
  Free inodes: 1977-3952
Group 2: (Blocks 16385-24576) [INODE_UNINIT, BLOCK_UNINIT, ITABLE_ZEROED]
  Checksum 0xcfd3, unused inodes 1976
  Block bitmap at 261 (+4294951172), Inode bitmap at 277 (+4294951188)
  Inode table at 785-1031 (+4294951696)
  8192 free blocks, 1976 free inodes, 0 directories, 1976 unused inodes
  Free blocks: 16385-24576
  Free inodes: 3953-5928 
Group ....

Nun zurück zur dfAusgabe:

df /tmp/test/
Filesystem              1K-blocks  Used Available Use% Mounted on
/dev/mapper/MyVG-test       99150  5646     88384   7% /tmp/test

Der Grund, warum auf diesem neuen Dateisystem bereits 7% der Kapazität als belegt markiert sind, ist:

99150 (die Größe des Dateisystems) MINUS 5120 (die Anzahl der reservierten Blöcke) MINUS 5646 (verwendete Blöcke, von denen 4096 aus dem Journal stammen (wieder Teil der Ausgabe von dumpe2fs))
= 88384

Die Anzahl der freien Blöcke in dumpe2fs ist die verfügbare Größe des Dateisystems abzüglich der tatsächlichen Nutzung (und berücksichtigt nicht die reservierten Blöcke), also 99150 - 5646 = 93504.


0

Keine Antwort auf die Frage, aber ich wurde neugierig, also stelle ich mir vor, dass andere es tun werden. Da ich bereits eine Live-CD gebootet hatte und eine Festplatte hatte, mit der ich mich herumschlagen konnte, ohne mir Gedanken über Tippfehler zu machen, die irgendetwas beschädigten, fuhr ich fort und testete.

Ich habe Partitionen mit allen FSes, für die Ubuntu 14.10 ein mkfs liefert, auf 100MiB-Partitionen erstellt. (Mit Ausnahme von Minix, das nur 64 MB unterstützt, und BFS, einer SCO-Funktion, von der ich noch nie gehört habe.)

Zuerst habe ich sah df -kverfügbaren Platz (mit Standard mkfs Einstellungen), dann habe ich dded /dev/zeroauf jeder FS in eine Datei , um sicherzustellen , könnten sie den ganzen Weg werden gefüllt. (Überprüfen Sie also, ob die angeforderte available spacetatsächlich verfügbar war.)
for i in /media/ubuntu/small-*;do sudo dd if=/dev/zero of="$i/fill" bs=16k;done

* FS: empty `df -k` : non-zero `df -k` when full (false bottom)
* jfs:  101020k
* fat32:100808k  : 4
* ntfs:  99896k
* btrfs: 98276k  : 4428
* ext2:  92480k
* xfs:   90652k  : 20
* ext4:  86336k
* ext3:  88367k
* reiserfs(v3): 69552k

Warum hat btrfs so viel unbenutzbaren Speicherplatz? Vielleicht für Metadaten? na nein:

$ for i in /media/ubuntu/small-*;do sudo touch "$i/touched";done
touch: cannot touch ‘/media/ubuntu/small-btrfs/touched’: No space left on device
touch: cannot touch ‘/media/ubuntu/small-reiser/touched’: No space left on device

Beide baumbasierten Dateisysteme können nirgendwo eine leere Datei packen, alle anderen jedoch.

Oder sehen Sie sich an, wie groß eine Datei sein kann:

$ ls -SdlG --block-size=1k /media/ubuntu/small-*/*
-rw-r--r-- 1 root   101020 Feb 21 11:55 /media/ubuntu/small-jfs/fill
-rw-r--r-- 1 ubuntu 100804 Feb 21 11:55 /media/ubuntu/small-fat/fill
-rw------- 1 ubuntu  99848 Feb 21 11:55 /media/ubuntu/small-ntfs/fill
-rw-r--r-- 1 root    97216 Feb 21 11:55 /media/ubuntu/small-ext2/fill
-rw-r--r-- 1 root    93705 Feb 21 11:27 /media/ubuntu/small-btrfs/foo
-rw-r--r-- 1 root    93120 Feb 21 11:55 /media/ubuntu/small-ext3/fill
-rw-r--r-- 1 root    91440 Feb 21 11:55 /media/ubuntu/small-ext/fill
-rw-r--r-- 1 root    90632 Feb 21 11:55 /media/ubuntu/small-xfs/fill
-rw-r--r-- 1 root    69480 Feb 21 11:55 /media/ubuntu/small-reiser/fill
drwx------ 2 root       12 Feb 21 11:33 /media/ubuntu/small-ext2/lost+found
drwx------ 2 root       12 Feb 21 11:43 /media/ubuntu/small-ext3/lost+found
drwx------ 2 root       12 Feb 21 11:29 /media/ubuntu/small-ext/lost+found

(Ich habe meine ext4-Partition "small-ext" genannt, weil ich nicht vorhatte, alle Dateisysteme zu verrückt zu machen. Also ext = ext4 hier. NICHT die ursprüngliche ext2-Partition vor ext.)

Und df -kAusgabe nach dem erneuten Entfernen:

/dev/sdd6          95980    5328     90652   6% /media/ubuntu/small-xfs
/dev/sdd7          95054    1550     86336   2% /media/ubuntu/small-ext
/dev/sdd5         102400   93880    101020  96% /media/ubuntu/small-btrfs
/dev/sdd8         101168  101168         0 100% /media/ubuntu/small-jfs
/dev/sdd9          99150    1550     92480   2% /media/ubuntu/small-ext2
/dev/sdd10        102392   32840     69552  33% /media/ubuntu/small-reiser
/dev/sdd11        100808       1    100808   1% /media/ubuntu/small-fat
/dev/sdd12        102396    2548     99848   3% /media/ubuntu/small-ntfs
/dev/sdd13         95054    1567     88367   2% /media/ubuntu/small-ext3

(jfs wurde auf 1% zurückgesetzt, nachdem ich "touched" ebenfalls entfernt hatte. Entweder gab es eine Zeitverzögerung, oder es dauerte einen weiteren Schreibvorgang, um die verfügbare Größe zum Aktualisieren zu erhalten.)

Jedenfalls denke ich, dass das für meine Neugier ungefähr ist.

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.