13
1TB NVMe nur 870GB verfügbar
Hallo Zusammen,
Habe ne docker nextcloud Installation auf meiner rpi. Angeschlossen ist eine NVMe Disk mit 1TB. Als ich die eingebunden habe per USB3.0 Enclosure und unter Linux mit mkfs ext4 formatiert hatte werden lediglich 916GB angezeigt in der rpi Konsole aber in nextcloud nur 870GB?!?
In der docker compose habe ich nur das data Verzeichnis eingebunden auf die ext. Platte alles andere liegt lokal. Und auf der Platte ist gerade nichts drauf Da ich gerade das setup abgeschlossen habe. Wo liegen denn auf einmal
Lsblk:
blkid-o list:
fdisk -l:
df -hl
du -hs:
Habe ne docker nextcloud Installation auf meiner rpi. Angeschlossen ist eine NVMe Disk mit 1TB. Als ich die eingebunden habe per USB3.0 Enclosure und unter Linux mit mkfs ext4 formatiert hatte werden lediglich 916GB angezeigt in der rpi Konsole aber in nextcloud nur 870GB?!?
In der docker compose habe ich nur das data Verzeichnis eingebunden auf die ext. Platte alles andere liegt lokal. Und auf der Platte ist gerade nichts drauf Da ich gerade das setup abgeschlossen habe. Wo liegen denn auf einmal
Lsblk:
Name MAJ:MIN RM SIZE RO TYPE MOUNTPOINT
sda 8:0 0 931.5G 0 disk
└─sda1 8:1 0 931.5G 0 part /media/NVMe_1TBblkid-o list:
device fs_type label mount point UUID
---------------------------------------------------------------------
/dev/mmcblk0p1
vfat boot /boot 37E2-62C3
/dev/mmcblk0p2
ext4 rootfs / 6a932c1f-7335-42d9-9351-1b1b2ca538d4
/dev/sda1 ext4 /media/NVMe_1TB fde88642-33ba-40a9-95a1-0190b9d1c20dfdisk -l:
Disk /dev/sda: 931.51 GiB, 1000204886016 bytes, 1953525168 sectors
Disk model:
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes
Disklabel type: gpt
Disk identifier: 66683651-95B9-B349-9AB7-B2FC71AD1C74
Device Start End Sectors Size Type
/dev/sda1 2048 1953525134 1953523087 931.5G Linux filesystemdf -hl
neno@RPi4:/media/NVMe_1TB $ sudo df -hl
Filesystem Size Used Avail Use% Mounted on
/dev/root 30G 4.3G 24G 16% /
devtmpfs 3.7G 0 3.7G 0% /dev
tmpfs 3.9G 0 3.9G 0% /dev/shm
tmpfs 1.6G 1.3M 1.6G 1% /run
tmpfs 5.0M 4.0K 5.0M 1% /run/lock
/dev/mmcblk0p1 253M 51M 202M 20% /boot
/dev/sda1 916G 42M 870G 1% /media/NVMe_1TB
tmpfs 782M 0 782M 0% /run/user/1000
overlay 30G 4.3G 24G 16% /var/lib/docker/overlay2/aeb7c3d7124e8bec8fb822b78b2be991d1d3908adb3fed7cb408f09be7ac5340/merged
overlay 30G 4.3G 24G 16% /var/lib/docker/overlay2/dccfd5d5cafe29bc350c167e4058e8b09438f6418fa48a161365838a6759c3de/merged
overlay 30G 4.3G 24G 16% /var/lib/docker/overlay2/4197f5857b1beb0a20e0fcddfb97cb93bb97ecaa94b41507ace6dd0800193a07/merged
overlay 30G 4.3G 24G 16% /var/lib/docker/overlay2/b2c43e14413f7951427f6063088b70eadeb4936858d12a204940af0a8440401f/merged
overlay 30G 4.3G 24G 16% /var/lib/docker/overlay2/8db79223b109d1f162c059e231fa75eb9209c166b6f7fee256625a1a73ae556d/mergeddu -hs:
du -hs /media/NVMe_1TB/
42M /media/NVMe_1TB/
Share on Facebook
Share on Twitter
Share on Reddit
Share on LinkedinPlease also mark the comments that contributed to the solution of the article
Content-Key: 3090323926
Url: https://administrator.de/contentid/3090323926
Printed on: April 26, 2024 at 04:04 o'clock
13 Comments
Latest comment
Die partition und das formatieren habe ich so gemacht:
Create new Partition:
sudo fdisk -l
The type „g“ for new partition table, then „n“ for a new partition, then „y“ to remove the signature and finally „w“ to write and quit.
Format the disk:
sudo mkfs.ext4 /dev/sda1
Create new Partition:
sudo fdisk -l
The type „g“ for new partition table, then „n“ for a new partition, then „y“ to remove the signature and finally „w“ to write and quit.
Format the disk:
sudo mkfs.ext4 /dev/sda1
Möglicherweise ist da Platz für root reserviert, siehe z.B. hier:
https://serverfault.com/a/848805
Lass mal Folgendes drüber laufen:
-> Falls bei "Reserved block count" etwas auftauchen sollte, kannst du ja mal rumrechnen, ob das hinkommt, also ob das die bei dir vorhandene Differenz zwischen 916G und 870G erklärt.
Ggf. kann dieser prozentuale Anteil an Reservierung dann auch noch angepasst werden:
https://serverfault.com/a/848805
Lass mal Folgendes drüber laufen:
tune2fs -l /dev/sda1 | egrep "Block count|Reserved block count" Ggf. kann dieser prozentuale Anteil an Reservierung dann auch noch angepasst werden:
tune2fs -m <percentage> <device>
Guter Tipp! Und er ergibt auch was:
sudo tune2fs -l /dev/sda1 | egrep "Block count|Reserved block count"
Block count: 244190385
Reserved block count: 12209519
Joah, kommt doch ziemlich gut hin 
870G / 916G = 0,9498 -> ca. 5% "Verlust"
12209519 / 244190385 = 0,05 -> 5% reserviert
870G / 916G = 0,9498 -> ca. 5% "Verlust"
12209519 / 244190385 = 0,05 -> 5% reserviert
Was wäre das Minimum was ich setzen kann damit ich aber keine Probleme bekomme??? Also 0% wären ja möglich aber nicht empfehlenswert. Evtl 0,005 also:
tune2fs -m 0,005 /dev/sda1
tune2fs -m 0,005 /dev/sda1
Naja die Absicht, die hinter der Reservierung steht, ist es, dem root user bzw. privilegierten System-Prozessen noch ein bisschen Luft zum Atmen zu geben, wenn der Platz "eigentlich" schon aufgebraucht ist. Also für administrative Zwecke.
Siehe man page von tune2fs:
-m reserved-blocks-percentage
"Set the percentage of the filesystem which may only be allocated by privileged processes. Reserving some number of filesystem blocks for use by privileged processes is done to avoid filesystem fragmentation, and to allow system daemons, such as syslogd(8), to continue to function correctly after non-privileged processes are prevented from writing to the filesystem."
Kann man sich jetzt streiten, was bzw. wieviel dafür nötig ist, oder ob man es auch komplett weglassen kann ;) Vermutlich (!) jedoch stammen die 5% noch aus einer Zeit, wo Festplatten noch nicht allzu groß waren, und folglich 5% auch nicht besonders viel (in absolutem Speicherplatz).
Mittlerweile ist es quasi umgekehrt, und die 5% machen derart viel aus, dass man es auch gleich merkt.
Keine Ahnung.. falls da Werte unter 1 möglich sind, würd ich vielleicht mit 0,1 arbeiten.
Das wäre dann knapp unter 1GB -> fände ich persönlich gut verschmerzbar, aber andererseits sollte das noch ausreichen für den Erhalt der "Notfall-Funktion".
Siehe man page von tune2fs:
-m reserved-blocks-percentage
"Set the percentage of the filesystem which may only be allocated by privileged processes. Reserving some number of filesystem blocks for use by privileged processes is done to avoid filesystem fragmentation, and to allow system daemons, such as syslogd(8), to continue to function correctly after non-privileged processes are prevented from writing to the filesystem."
Kann man sich jetzt streiten, was bzw. wieviel dafür nötig ist, oder ob man es auch komplett weglassen kann ;) Vermutlich (!) jedoch stammen die 5% noch aus einer Zeit, wo Festplatten noch nicht allzu groß waren, und folglich 5% auch nicht besonders viel (in absolutem Speicherplatz).
Mittlerweile ist es quasi umgekehrt, und die 5% machen derart viel aus, dass man es auch gleich merkt.
Keine Ahnung.. falls da Werte unter 1 möglich sind, würd ich vielleicht mit 0,1 arbeiten.
Das wäre dann knapp unter 1GB -> fände ich persönlich gut verschmerzbar, aber andererseits sollte das noch ausreichen für den Erhalt der "Notfall-Funktion".
Du meinst 0,01 das wäre 1GB
Nee, schon 0,1.
Also 0,1% von 961 GB.
Also 0,1% von 961 GB.
1
916GB angezeigt
Das Format nimmt aber auch etwas weg oder nicht?in der rpi Konsole aber in nextcloud nur 870GB?!?
Und dann wird immer noch etwas als Cache (%) reserviert.Beides zusammen könnte dann eben das Ergebnis von 870 GB untermauern.
Dobby
Es geht ja hier letztendlich um drei "Sprünge":
- von 1 TB auf 931 GB (wobei "GB" hier nicht korrekt ist, s.u.)
- 931 -> 916
- 916 -> 870
Der erste Sprung kommt dadurch zustande, dass die 931 eben keine GB (Gigabyte) sind, sondern GiB (GibiByte).
1 TB = 1x10^12 Bytes
aber:
Die Darstellung erfolgt (korrekterweise) in GibiBytes, und die Umrechnung von Bytes in die angemessene "höhere" Form erfolgt NICHT so:
10^12 / 10^12 = 1 (TB)
sondern so:
10^12 / 1024^3 = 931,3 (GiB)
-> siehe den Link von LeReseau
Davon geht dann noch ein wenig was runter: 931 -> 916 (GiB).
Da bin ich mir grad auch nicht ganz sicher, aber das wird im weitesten Sinne der Verwaltung des Dateisystems geschuldet sein. Stichwort inodes, etc.
Der letzte Sprung: 916 GiB -> 870 GiB, das sind die o.a. 5% Sicherheitsreserve, die "reserved blocks".
- von 1 TB auf 931 GB (wobei "GB" hier nicht korrekt ist, s.u.)
- 931 -> 916
- 916 -> 870
Der erste Sprung kommt dadurch zustande, dass die 931 eben keine GB (Gigabyte) sind, sondern GiB (GibiByte).
1 TB = 1x10^12 Bytes
aber:
Die Darstellung erfolgt (korrekterweise) in GibiBytes, und die Umrechnung von Bytes in die angemessene "höhere" Form erfolgt NICHT so:
10^12 / 10^12 = 1 (TB)
sondern so:
10^12 / 1024^3 = 931,3 (GiB)
-> siehe den Link von LeReseau
Davon geht dann noch ein wenig was runter: 931 -> 916 (GiB).
Da bin ich mir grad auch nicht ganz sicher, aber das wird im weitesten Sinne der Verwaltung des Dateisystems geschuldet sein. Stichwort inodes, etc.
Der letzte Sprung: 916 GiB -> 870 GiB, das sind die o.a. 5% Sicherheitsreserve, die "reserved blocks".
danke für den link
Danke Han Trio
