Seltsamer Effekt im Dateisystem

[Peter18]

Ein freundliches Hallo an alle,

ich habe an einem Raspberry Pi 2 USB-Platten. eine dient als Datenspeicher, die 2. soll ein Backup davon aufnehmen. Beide Platten sind gleich groß.

Der Effekt:
Ein Mount-Befehl wird ohne Fehlermeldung ausgeführt. In der Liste erscheint aber kein Mountpoint:

Code: Alles auswählen

lsblk
NAME        MAJ:MIN RM   SIZE RO TYPE MOUNTPOINT
sda           8:0    0   1,8T  0 disk
`-sda1        8:1    0   1,8T  0 part
sdb           8:16   0   1,8T  0 disk
`-sdb1        8:17   0   1,8T  0 part /media/platte1
mmcblk0     179:0    0 119,1G  0 disk
|-mmcblk0p1 179:1    0  43,2M  0 part /boot
`-mmcblk0p2 179:2    0   119G  0 part /

Nicht montiert? Doch!

Code: Alles auswählen

ls /media/platte2
Backup

Die Datensicherung bricht mit "No space left on device (28)" ab.

Code: Alles auswählen

df
Dateisystem     1K-Bl▒cke   Benutzt  Verf▒gbar Verw% Eingeh▒ngt auf
/dev/root       122895396 122771204          0  100% /
devtmpfs           469544         0     469544    0% /dev
tmpfs              474152         0     474152    0% /dev/shm
tmpfs              474152     19076     455076    5% /run
tmpfs                5120         4       5116    1% /run/lock
tmpfs              474152         0     474152    0% /sys/fs/cgroup
/dev/mmcblk0p1      43539     22855      20685   53% /boot
/dev/sdb1      1921802500 276642784 1547467656   16% /media/platte1
tmpfs               94828         0      94828    0% /run/user/1000

Die Platte:

Code: Alles auswählen

df /dev/sda1
Dateisystem    1K-Bl▒cke Benutzt Verf▒gbar Verw% Eingeh▒ngt auf
devtmpfs          469544       0    469544    0% /dev

hat noch Platz. Root nicht. Wieso? dort liegen nur ein paar Skripte für die Datensicherung.

Protokolle gehen auf Platte1.

Grüße von der Nordsee

Peter

[mistersixt]

Ich vermute, die 2. Platte war nicht korrekt eingehängt, und Dein Backup-Script hat von Platte 1 alles auf das root-Device des Raspberry kopiert (SD-Karte vermutlich), daher ist dieses jetzt zu 100% voll.

Gruss, mistersixt.

[TomL]

Kannst Du mal die Ausgabe von
# lsblk -o NAME,FSTYPE,SIZE,MOUNTPOINT,LABEL,UUID,TYPE
zeigen?

Und wie ist die Meldung, wenn sda1 manuell im Terminal gemountet wird (vollständiger Befehl plus Ausgabe)? Parallel dazu (bzw. vorher) in einem zweiten Terminal
# journalctl -f
starten und die kurz darauf folgende Ausgabe beobachten.

[Peter18]

Hallo mistersixt,

Dank Dir für die Antwort.

Bei /root sehe ich nur die Daten, die dort zu erwarten sind, einige k. Aber wie finde ich den Speicherfresser??? Wie kann ich /root aufräumen???

Hallo Thomas,

Dank auch Dir!

Code: Alles auswählen

 lsblk -o NAME,FSTYPE,SIZE,MOUNTPOINT,LABEL,UUID,TYPE
NAME        FSTYPE   SIZE MOUNTPOINT     LABEL  UUID                                 TYPE
sda                  1,8T                                                            disk
`-sda1      ext4     1,8T                       2f04f271-e38e-439d-ad7a-dc6851952942 part
sdb                  1,8T                                                            disk
`-sdb1      ext4     1,8T /media/platte1        6dea6d6d-6484-4411-accc-1a236afe89b8 part
mmcblk0            119,1G                                                            disk
|-mmcblk0p1 vfat    43,2M /boot          boot   3725-1C05                            part
`-mmcblk0p2 ext4     119G /              rootfs fd695ef5-f047-44bd-b159-2a78c53af20a part

Code: Alles auswählen

pi@S-SpeBo:~ $ sudo mount /dev/sda1 /media/platte2
pi@S-SpeBo:~ $

Code: Alles auswählen

Jan 14 11:38:15 S-SpeBo kernel: w1_master_driver w1_bus_master1: Attaching one wire slave 00.964800000000 crc 21
Jan 14 11:38:15 S-SpeBo kernel: w1_master_driver w1_bus_master1: Family 0 for 00.964800000000.21 is not registered.
Jan 14 11:39:20 S-SpeBo kernel: w1_master_driver w1_bus_master1: Attaching one wire slave 00.564800000000 crc eb
Jan 14 11:39:20 S-SpeBo kernel: w1_master_driver w1_bus_master1: Family 0 for 00.564800000000.eb is not registered.
Jan 14 11:40:22 S-SpeBo kernel: w1_master_driver w1_bus_master1: Attaching one wire slave 00.d64800000000 crc 67
Jan 14 11:40:22 S-SpeBo kernel: w1_master_driver w1_bus_master1: Family 0 for 00.d64800000000.67 is not registered.
Jan 14 11:40:48 S-SpeBo kernel: w1_master_driver w1_bus_master1: Attaching one wire slave 00.364800000000 crc 8e
Jan 14 11:40:48 S-SpeBo kernel: w1_master_driver w1_bus_master1: Family 0 for 00.364800000000.8e is not registered.
Jan 14 11:41:27 S-SpeBo kernel: w1_master_driver w1_bus_master1: Attaching one wire slave 00.b64800000000 crc 02
Jan 14 11:41:27 S-SpeBo kernel: w1_master_driver w1_bus_master1: Family 0 for 00.b64800000000.02 is not registered.
Jan 14 11:42:07 S-SpeBo kernel: w1_master_driver w1_bus_master1: Attaching one wire slave 00.764800000000 crc c8
Jan 14 11:42:07 S-SpeBo kernel: w1_master_driver w1_bus_master1: Family 0 for 00.764800000000.c8 is not registered.
Jan 14 11:42:08 S-SpeBo sshd[26850]: Accepted password for pi from 10.168.0.5 port 1307 ssh2
Jan 14 11:42:08 S-SpeBo sshd[26850]: pam_unix(sshd:session): session opened for user pi by (uid=0)
Jan 14 11:42:08 S-SpeBo systemd-logind[381]: New session c8 of user pi.
Jan 14 11:42:08 S-SpeBo systemd[1]: Started Session c8 of user pi.
Jan 14 11:43:09 S-SpeBo kernel: w1_master_driver w1_bus_master1: Attaching one wire slave 00.f64800000000 crc 44
Jan 14 11:43:09 S-SpeBo kernel: w1_master_driver w1_bus_master1: Family 0 for 00.f64800000000.44 is not registered.
Jan 14 11:44:02 S-SpeBo kernel: w1_master_driver w1_bus_master1: Attaching one wire slave 00.0e4800000000 crc f2
Jan 14 11:44:02 S-SpeBo kernel: w1_master_driver w1_bus_master1: Family 0 for 00.0e4800000000.f2 is not registered.
Jan 14 11:45:01 S-SpeBo sudo[26903]:       pi : TTY=pts/1 ; PWD=/home/pi ; USER=root ; COMMAND=/bin/mount /dev/sda1 /media/platte2
Jan 14 11:45:01 S-SpeBo sudo[26903]: pam_unix(sudo:session): session opened for user root by pi(uid=0)
Jan 14 11:45:04 S-SpeBo kernel: EXT4-fs (sda1): mounted filesystem with ordered data mode. Opts: (null)
Jan 14 11:45:04 S-SpeBo sudo[26903]: pam_unix(sudo:session): session closed for user root
Jan 14 11:45:04 S-SpeBo systemd[1]: media-platte2.mount: Unit is bound to inactive unit dev-disk-by\x2duuid-2A71C17C\x2dFAC0\x2d4607\x2dB19C\x2d2A5462208627.device. Stopping, too.
Jan 14 11:45:04 S-SpeBo systemd[1]: Unmounting /media/platte2...
Jan 14 11:45:05 S-SpeBo systemd[1]: Unmounted /media/platte2.
Jan 14 11:45:05 S-SpeBo kernel: w1_master_driver w1_bus_master1: Attaching one wire slave 00.8e4800000000 crc 7e
Jan 14 11:45:05 S-SpeBo kernel: w1_master_driver w1_bus_master1: Family 0 for 00.8e4800000000.7e is not registered.
Jan 14 11:45:43 S-SpeBo kernel: w1_master_driver w1_bus_master1: Attaching one wire slave 00.4e4800000000 crc b4
Jan 14 11:45:43 S-SpeBo kernel: w1_master_driver w1_bus_master1: Family 0 for 00.4e4800000000.b4 is not registered.

Grüße von der Nordsee

Peter

[DeletedUserReAsG]

Aber wie finde ich den Speicherfresser???

Mit etwa du oder, bequemer, ncdu!!!k!

Wie kann ich /root aufräumen???

Mit etwa rm oder, bequemer, mc!!!k! Oder auch gleich aus ncdu heraus!!!k!

[Peter18]

Hallo niemand,

auch Dir meinen Dank.

Code: Alles auswählen

--- /root -----------------------------------------------------------------------------------------------------------------------------
   16,0 KiB [##########] /.ssh
e   4,0 KiB [##        ] /.nano
    4,0 KiB [##        ]  .bash_history
    4,0 KiB [##        ]  Backup_Std
    4,0 KiB [##        ]  Backup_Tag.save
    4,0 KiB [##        ]  Backup_Tag
    4,0 KiB [##        ]  Backup_Woche
    4,0 KiB [##        ]  .bashrc
    4,0 KiB [##        ]  Backup_Monat
    4,0 KiB [##        ]  Backup_BSrv
    4,0 KiB [##        ]  Backup_Platte2
    4,0 KiB [##        ]  .profile

Aber wo ist der Speicherfresser???

Grüße von der Nordsee

Peter

[DeletedUserReAsG]

Aber wo ist der Speicherfresser???

Offensichtlich nicht unter /root!!!k Mit „Root-Device“ war wahrscheinlich auch eher das Device gemeint, welches das Rootverzeichnis (also /, nicht /root – das wäre „Roots Verzeichnis“ ) beinhaltet!!!k Du solltest ncdu also von / an (dem Rootverzeichnis, nicht Roots Verzeichnis) laufen lassen, und deinen Platzfresser finden!!!k!ka.

Wenn ich raten sollte, würde ich behaupten, dass unter /media/platte2/ Daten zu finden sind, deren Größe ziemlich genau dem fehlenden Platz entspricht!!!k! Sollte das unerwarteterweise nicht der Fall sein, und auch sonst nix zu finden sein, könnte man mal /media/platte1 aushängen, und dann in dem Verzeichnis nachsehen. Wenn man nämlich ein FS mountet, maskiert es den Inhalt des als Mountpoint dienenden Verzeichnisses, was zu Effekten, wie unauffindbaren Platzfressern führen kann.!!!k!

[novalix]

Code: Alles auswählen

Jan 14 11:45:01 S-SpeBo sudo[26903]:       pi : TTY=pts/1 ; PWD=/home/pi ; USER=root ; COMMAND=/bin/mount /dev/sda1 /media/platte2
Jan 14 11:45:01 S-SpeBo sudo[26903]: pam_unix(sudo:session): session opened for user root by pi(uid=0)
Jan 14 11:45:04 S-SpeBo kernel: EXT4-fs (sda1): mounted filesystem with ordered data mode. Opts: (null)
Jan 14 11:45:04 S-SpeBo sudo[26903]: pam_unix(sudo:session): session closed for user root
Jan 14 11:45:04 S-SpeBo systemd[1]: media-platte2.mount: Unit is bound to inactive unit dev-disk-by\x2duuid-2A71C17C\x2dFAC0\x2d4607\x2dB19C\x2d2A5462208627.device. Stopping, too.
Jan 14 11:45:04 S-SpeBo systemd[1]: Unmounting /media/platte2...
Jan 14 11:45:05 S-SpeBo systemd[1]: Unmounted /media/platte2.

Du hängst die Platte ein und systemd hängt sie wieder aus.
https://unix.stackexchange.com/question ... able-drive

Dadurch wird Dein Backup wahrscheinlich unter dem Pfad "/media/platte2" auf dem Gerät, welches unter / eingehängt ist, gelandet sein.

[mistersixt]

Offensichtlich nicht unter /root!!!k Mit „Root-Device“ war wahrscheinlich auch eher das Device gemeint, welches das Rootverzeichnis (also /, nicht /root – das wäre „Roots Verzeichnis“ ) beinhaltet!!!k Du solltest ncdu also von / an (dem Rootverzeichnis, nicht Roots Verzeichnis) laufen lassen, und deinen Platzfresser finden!!!k!ka.

Also "ncdu -x /" ... damit solltest Du vermutlich mehr sehen ("-x Do not cross filesystem boundaries, i.e. only count files and directories on the same filesystem as the directory being scanned.").

Gruss, mistersixt.

[TuxPeter]

Habe mitgelesen und ncdu installiert - feines Teil - Thnx!

[wanne]

Nochmal für dich ohne Fachwörter

Nicht montiert? Doch!

Nein!
/media/platte2 ist ein ganz normaler Ordner auf deiner SD-Karte. Da hast du jetzt das Backup hin kopiert. Nicht auf die Platte.

[Peter18]

Hallo novalix, hallo mistersixt,

nochmals Dank!

Der Tipp war gut! Ich habe einen anderen Mountpoint angelegt und die Platte ließ sich ordnungsgemäß mounten, der Mountpoint wird nun angezeigt, der Inhalt ebenfalls. Soweit ist alles gut.

Wie aber kann da etwas anderes auf dem Mountpoint liegen, was ich dort nicht hingelegt habe, soweit ich weiß und wie kann ich herausfinden was da passiert ist??

Grüße von der Nordsee

Peter

[MSfree]

Wie aber kann da etwas anderes auf dem Mountpoint liegen, was ich dort nicht hingelegt habe, soweit ich weiß und wie kann ich herausfinden was da passiert ist?

Ein typischer Fall ist, du legst den Mountpoint /media/MeinePlatte an. Dann startest du den Rechner neu, ohne die (externe USB-)Platte angeschlossen zu haben. Der MountPoint existiert ja noch von vorher.

Dann kopierst du lustig in das Verzeichnis /media/MeinePlatte, in der Annahma, daß da ja deine externe Platte gemountet ist, und schreibst damit das /-Dateisystem voll. Wenn du dann die externe Platte wieder unter /media/MeinePlatte mountest, wird der Inhalt des Verzeichnises vom Inhalt der externen Platte ver- bzw. überdeckt. Nur das /-Dateisystem ist natürlich jetzt voll und du weißt nicht, mit was.

[novalix]

Ein typischer Fall ist, du legst den Mountpoint /media/MeinePlatte an. Dann startest du den Rechner neu, ohne die (externe USB-)Platte angeschlossen zu haben. Der MountPoint existiert ja noch von vorher.

In diesem Fall ist der PEBCAK-Anteil allerdings wahrscheinlich gering. Aus dem Log geht ja eindeutig hervor, dass hier ein Bug von systemd zugeschlagen hat.
Hier wird der mount-Befehl einwandfrei (ohne Fehlermeldung) ausgeführt und systemd unmounted das Dateisystem sofort wieder, ohne eine direkte Benachrichtigung.
Als user musst Du also davon ausgehen, dass hinter dem Mount Point das angeschlossene Gerät liegt.
Bekloppterweise tut es das nach einem Reboot auch, wenn das Gerät angeschlossen ist.

[Peter18]

Hallo MSfree, hallo novalix,

Dank Euch! Die Sache ist nun soweit klar, aber:

Was sitzt auf dem Mountpoint, ein Link?, wie kann ich das feststellen??

Nachtrag:
Die UUID hat sich anscheinend geändert. Nun ist es "2f04f271-e38e-439d-ad7a-dc6851952942". In der fatab war "2A71C17C-FAC0-4607-B19C-2A5462208627" eingetragen. War das vielleicht die Ursache?? Kann sich die UUID durch einen Stromausfall ändern??

Grüße von der Nordsee

Peter

[debianoli]

Was sitzt auf dem Mountpoint, ein Link?, wie kann ich das feststellen??

Nein, da sitzt nix wie ein Link, völlig falsch verstanden.

Du mountest Dateisysteme bei Linux immer in ein bereits vorhandenes Verzeichnis. D.h., dass du Daten immer in ein Verzeichnis schreibst. Ist in das Verzeichnis ein Dateisystem=Festplatte gemountet, dann landen die Daten physikalisch auf dieser Festplatte. Ist da nix gemountet, dann landen die Daten auf der Festplatte, auf dem der entsprechende Ordner liegt.

[MSfree]

Die UUID hat sich anscheinend geändert. Nun ist es "2f04f271-e38e-439d-ad7a-dc6851952942". In der fatab war "2A71C17C-FAC0-4607-B19C-2A5462208627" eingetragen. War das vielleicht die Ursache?

Ja, das kann etwas ausmachen. Der Automounter mountet dann die externe Platte nicht wie in der fstab angegeben sondern auf einen Ich-weiß-nicht-wie-generierten Pfad. Das heißt, du hättest zwar die Fesplatte gemountet, aber nicht auf das von dir erwartete Verzeichnis.

Wenn du dann in des erwartete Verzeichnis kopierst, tritt das ein, was ich oben beschrieben habe.

Kann sich die UUID durch einen Stromausfall ändern?

Nicht wirklich. Die UUID steht an einer Stelle auf der Festplatte, die nur einmalig beim Anlegen des Dateisystem geschrieben wird. Ein Stromausfall kann zwar auf den Datenblöcken Unfug erzeugen, die zuletzt im Schreibzugriff waren, aber nicht auf einem Block, der nie wieder (außer beim Neuformatieren) geschrieben wird.

Kann es sein, daß das einfach eine ganz andere Platte war?

[Peter18]

Hallo debianol, hallo MSfree,

Dank Euch! Es kann also sein, dass ich versehentlich die falsche UUID in der Zwischenablage hatte und das System hat dann irgend etwas gemounted? Aber umount hat auch nicht funktioniert und es gab die Fehlermeldung "Not mounted". War der Mountpoint reserviert? Jeder Versuch etwas anderes zu montieren wurde verhindert? Anscheinend konnte ich den Mountpoint nur wie ein normales Verzeichnis verwenden.

Kann es sein, daß das einfach eine ganz andere Platte war?

Da waren nur 2 Platten, die eine habe ich gesehen (Samba), die andere erschien nicht. Vielleicht irgendwo in den Untiefen des Dateisystems.

Grüße von der sonnigen Nordsee

Peter