Seltsamer Effekt im Dateisystem

Warum Debian? Was muss ich vorher wissen? Wo geht's nach der Installation weiter?
Peter18
Beiträge: 82
Registriert: 14.12.2018 11:56:20

Seltsamer Effekt im Dateisystem

Beitrag von Peter18 » 14.01.2020 11:20:27

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
Zuletzt geändert von Peter18 am 14.01.2020 11:24:15, insgesamt 1-mal geändert.

Benutzeravatar
mistersixt
Beiträge: 6571
Registriert: 24.09.2003 14:33:25
Lizenz eigener Beiträge: GNU Free Documentation License

Re: Seltsamer Effekt im Dateisystem

Beitrag von mistersixt » 14.01.2020 11:23:08

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.
--
System: Debian Buster, 4.19.x.-x-amd64, ext4, AMD Ryzen 7, 8 x 3.7 Ghz., NV-GTX 1060, 16 GB Ram, XFCE

TomL
Beiträge: 5174
Registriert: 24.07.2014 10:56:59

Re: Seltsamer Effekt im Dateisystem

Beitrag von TomL » 14.01.2020 11:25:51

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.
vg, Thomas

Peter18
Beiträge: 82
Registriert: 14.12.2018 11:56:20

Re: Seltsamer Effekt im Dateisystem

Beitrag von Peter18 » 14.01.2020 11:37:38

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
Zuletzt geändert von Peter18 am 14.01.2020 11:48:45, insgesamt 1-mal geändert.

Benutzeravatar
niemand
Beiträge: 13785
Registriert: 18.07.2004 16:43:29

Re: Seltsamer Effekt im Dateisystem

Beitrag von niemand » 14.01.2020 11:44:56

Peter18 hat geschrieben: ↑ zum Beitrag ↑
14.01.2020 11:37:38
Aber wie finde ich den Speicherfresser???
Mit etwa du oder, bequemer, Debianncdu!!!k!
Peter18 hat geschrieben: ↑ zum Beitrag ↑
14.01.2020 11:37:38
Wie kann ich /root aufräumen???
Mit etwa rm oder, bequemer, Debianmc!!!k! Oder auch gleich aus ncdu heraus!!!k!
non serviam.

Peter18
Beiträge: 82
Registriert: 14.12.2018 11:56:20

Re: Seltsamer Effekt im Dateisystem

Beitrag von Peter18 » 14.01.2020 11:57:04

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

Benutzeravatar
niemand
Beiträge: 13785
Registriert: 18.07.2004 16:43:29

Re: Seltsamer Effekt im Dateisystem

Beitrag von niemand » 14.01.2020 12:01:16

Peter18 hat geschrieben: ↑ zum Beitrag ↑
14.01.2020 11:57:04
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!
non serviam.

Benutzeravatar
novalix
Beiträge: 1795
Registriert: 05.10.2005 12:32:57
Lizenz eigener Beiträge: MIT Lizenz
Wohnort: elberfeld

Re: Seltsamer Effekt im Dateisystem

Beitrag von novalix » 14.01.2020 12:51:28

Peter18 hat geschrieben: ↑ zum Beitrag ↑
14.01.2020 11:37:38

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.
Das Wem, Wieviel, Wann, Wozu und Wie zu bestimmen ist aber nicht jedermannns Sache und ist nicht leicht.
Darum ist das Richtige selten, lobenswert und schön.

Benutzeravatar
mistersixt
Beiträge: 6571
Registriert: 24.09.2003 14:33:25
Lizenz eigener Beiträge: GNU Free Documentation License

Re: Seltsamer Effekt im Dateisystem

Beitrag von mistersixt » 14.01.2020 12:59:41

niemand hat geschrieben: ↑ zum Beitrag ↑
14.01.2020 12:01:16

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.
--
System: Debian Buster, 4.19.x.-x-amd64, ext4, AMD Ryzen 7, 8 x 3.7 Ghz., NV-GTX 1060, 16 GB Ram, XFCE

TuxPeter
Beiträge: 1545
Registriert: 19.11.2008 20:39:02
Lizenz eigener Beiträge: MIT Lizenz

Re: Seltsamer Effekt im Dateisystem

Beitrag von TuxPeter » 14.01.2020 13:54:18

Habe mitgelesen und ncdu installiert - feines Teil - Thnx!

wanne
Moderator
Beiträge: 6529
Registriert: 24.05.2010 12:39:42

Re: Seltsamer Effekt im Dateisystem

Beitrag von wanne » 14.01.2020 14:27:43

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.
rot: Moderator wanne spricht, default: User wanne spricht.

Peter18
Beiträge: 82
Registriert: 14.12.2018 11:56:20

Re: Seltsamer Effekt im Dateisystem

Beitrag von Peter18 » 14.01.2020 14:34:04

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
Beiträge: 5929
Registriert: 25.09.2007 19:59:30

Re: Seltsamer Effekt im Dateisystem

Beitrag von MSfree » 14.01.2020 15:07:48

Peter18 hat geschrieben: ↑ zum Beitrag ↑
14.01.2020 14:34:04
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.

Benutzeravatar
novalix
Beiträge: 1795
Registriert: 05.10.2005 12:32:57
Lizenz eigener Beiträge: MIT Lizenz
Wohnort: elberfeld

Re: Seltsamer Effekt im Dateisystem

Beitrag von novalix » 14.01.2020 16:23:20

MSfree hat geschrieben: ↑ zum Beitrag ↑
14.01.2020 15:07:48
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.
Das Wem, Wieviel, Wann, Wozu und Wie zu bestimmen ist aber nicht jedermannns Sache und ist nicht leicht.
Darum ist das Richtige selten, lobenswert und schön.

Peter18
Beiträge: 82
Registriert: 14.12.2018 11:56:20

Re: Seltsamer Effekt im Dateisystem

Beitrag von Peter18 » 14.01.2020 16:41:55

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

Antworten