mdadm: Cannot get exclusive access to /dev/md3:Perhaps a running process, mounted filesystem or active volume group?

[framp]

Ein RAID5 ist gecrashed und bevor ich anfange zu versuchen das zu recovern möchte ich ein dd Backup aller verbleibender 4 Platten erstellen. Dazu möchte ich das Raid deaktivieren und bekomme als root leider

mdadm --stop /dev/md3
mdadm: Cannot get exclusive access to /dev/md3:Perhaps a running process, mounted filesystem or active volume group?

Das Volume ist umounted. Wie kann ich am besten rausfinden was den Raid Stop verhindert? Auf meiner Syno klappt das ohne Probleme - aber leider nicht bei der Syno vor der ich gerade sitze

 

[maxblank]

Dann gebe mal mit Root-Rechten "synospace --stop-all-spaces" in die Console ein und teste es dann nochmals. Alles natürlich auf deine eigene Verantwortung und ohne Gewähr.

 

[framp]

Danke. Habe das mal auf meiner Syno ausprobiert (auf der ich allerdings auch mit mdadm ein RAID stoppen konnte) und es hat soweit funktioniert. Bin mal gespannt ob es auch auf der Syno hier funktioniert.

 

[framp]

Leider klappt es nicht. Der Befehl hängt und wenn ich ihn dann abbreche sind alle volumes umounted aber die RAIDs immer noch aktiv.

synogear) root@synology:~# lsof | grep md2
md2_defer 14121           root  cwd       DIR                9,0     4096          2 /
md2_defer 14121           root  rtd       DIR                9,0     4096          2 /
md2_defer 14121           root  txt   unknown                                        /proc/14121/exe
md2_defer 14122           root  cwd       DIR                9,0     4096          2 /
md2_defer 14122           root  rtd       DIR                9,0     4096          2 /
md2_defer 14122           root  txt   unknown                                        /proc/14122/exe
md2_raid5 14123           root  cwd       DIR                9,0     4096          2 /
md2_raid5 14123           root  rtd       DIR                9,0     4096          2 /
md2_raid5 14123           root  txt   unknown                                        /proc/14123/exe
(synogear) root@synology:~# lsof | grep md3
md3_defer 14229           root  cwd       DIR                9,0     4096          2 /
md3_defer 14229           root  rtd       DIR                9,0     4096          2 /
md3_defer 14229           root  txt   unknown                                        /proc/14229/exe
md3_defer 14230           root  cwd       DIR                9,0     4096          2 /
md3_defer 14230           root  rtd       DIR                9,0     4096          2 /
md3_defer 14230           root  txt   unknown                                        /proc/14230/exe
md3_raid5 14231           root  cwd       DIR                9,0     4096          2 /
md3_raid5 14231           root  rtd       DIR                9,0     4096          2 /
md3_raid5 14231           root  txt   unknown                                        /proc/14231/exe

Irgendwas greift immer noch auf die beiden RAIDs zu. Wie kann ich rausfinden wer/was das ist?

Eine Alternative wäre auch dass beim Booten die beiden RAIDs einfach nicht gestartet werden. Nur weiss ich noch nicht wie.

Hintergrund: Die DS1817 hat zwei Extensions, md3/DX513 ist gecrashed und ich möchte die restlichen 4 Platten auf die zweite DX517/md2 per dd clonen.

 

[maxblank]

/proc/14121/exe

Frag mal die o.a. PIDs ab. Hier ein Beispiel:

ls -l /proc/14121/exe

Dort sollte dann etwas kommen, wie.

lrwxrwxrwx 1 root root 0 Apr 23 14:00 /proc/14121/exe -> /usr/sbin/smbd

Alternativ die PIDs mit den laufenden Prozessen im Ressourcen-Monitor suchen oder mit der Ausgabe von htop über die Console vergleichen.

 

[framp]

Ich habe ein cat auf /proc/.../exe gemacht. Das ich mir den Link ansehen muss war mir nicht bewusst.
Ich habe erst morgen wieder Zugriff auf das System.

 

[framp]

Leide kommt da nur

ls: cannot read symbolic link 'exe': No such file or directory

obwohl ls ausgibt dass exe existiert und ein symbolic link ist :-(

root@synology:/proc/13516# lsof | grep md3
md3_defer 13516                     root cwd       DIR                9,0     4096          2 /
md3_defer 13516                     root rtd       DIR                9,0     4096          2 /
md3_defer 13516                     root txt   unknown                                        /proc/13516/exe
md3_defer 13517                     root cwd       DIR                9,0     4096          2 /
md3_defer 13517                     root rtd       DIR                9,0     4096          2 /
md3_defer 13517                     root txt   unknown                                        /proc/13517/exe
md3_raid5 13518                     root cwd       DIR                9,0     4096          2 /
md3_raid5 13518                     root rtd       DIR                9,0     4096          2 /
md3_raid5 13518                     root txt   unknown                                        /proc/13518/exe
root@synology:/proc/13516# ls -l /proc/13516/exe
ls: cannot read symbolic link '/proc/13516/exe': No such file or directory
lrwxrwxrwx 1 root root 0 Apr 25 20:48 /proc/13516/exe
root@synology:/proc/13516# ls -la
ls: cannot read symbolic link 'exe': No such file or directory
total 0
dr-xr-xr-x   8 root root 0 Apr 25 20:32 .
dr-xr-xr-x 275 root root 0 Apr 25 20:31 ..
dr-xr-xr-x   2 root root 0 Apr 25 20:49 attr
-r--------   1 root root 0 Apr 25 20:49 auxv
-r--r--r--   1 root root 0 Apr 25 20:32 cgroup
--w-------   1 root root 0 Apr 25 20:49 clear_refs
-r--r--r--   1 root root 0 Apr 25 20:32 cmdline
-rw-r--r--   1 root root 0 Apr 25 20:49 comm
-rw-r--r--   1 root root 0 Apr 25 20:49 coredump_filter
lrwxrwxrwx   1 root root 0 Apr 25 20:48 cwd -> /
-r--------   1 root root 0 Apr 25 20:49 environ
lrwxrwxrwx   1 root root 0 Apr 25 20:48 exe
dr-x------   2 root root 0 Apr 25 20:48 fd
dr-x------   2 root root 0 Apr 25 20:49 fdinfo
-r--------   1 root root 0 Apr 25 20:49 io
-r--r--r--   1 root root 0 Apr 25 20:49 limits
-r--r--r--   1 root root 0 Apr 25 20:48 maps
-rw-------   1 root root 0 Apr 25 20:49 mem
-r--r--r--   1 root root 0 Apr 25 20:49 mountinfo
-r--r--r--   1 root root 0 Apr 25 20:49 mounts
-r--------   1 root root 0 Apr 25 20:49 mountstats
dr-xr-xr-x   6 root root 0 Apr 25 20:49 net
dr-x--x--x   2 root root 0 Apr 25 20:48 ns
-rw-r--r--   1 root root 0 Apr 25 20:49 oom_adj
-r--r--r--   1 root root 0 Apr 25 20:49 oom_score
-rw-r--r--   1 root root 0 Apr 25 20:49 oom_score_adj
-r--r--r--   1 root root 0 Apr 25 20:49 pagemap
-r--r--r--   1 root root 0 Apr 25 20:49 personality
lrwxrwxrwx   1 root root 0 Apr 25 20:48 root -> /
-rw-r--r--   1 root root 0 Apr 25 20:49 sched
-r--r--r--   1 root root 0 Apr 25 20:49 schedstat
-r--r--r--   1 root root 0 Apr 25 20:49 smaps
-r--r--r--   1 root root 0 Apr 25 20:49 stack
-r--r--r--   1 root root 0 Apr 25 20:32 stat
-r--r--r--   1 root root 0 Apr 25 20:49 statm
-r--r--r--   1 root root 0 Apr 25 20:32 status
-r--r--r--   1 root root 0 Apr 25 20:49 syscall
dr-xr-xr-x   3 root root 0 Apr 25 20:48 task
-r--r--r--   1 root root 0 Apr 25 20:49 wchan

 

[maxblank]

Dann gleiche die PID, so wie ich es oben schon geschrieben hatte, über htop ab.




Oder gehe über die Prozess-Übersicht des Aufgaben-Managers im Ressourcen-Monitor:

 

[maxblank]

Wie hast du ""lsof" installiert? Über Entware oder irgendwelche Syno Tools?

 

[framp]

(synogear) root@synology:/# ps -ef | grep 13476
root      7166  2130  0 23:44 pts/0    00:00:00 grep --color=auto 13476
root     13476     2  0 20:32 ?        00:00:03 [md2_defer0]

Dasselbe sehe ich in htop: md2_defer0
Das hilft leider nicht weiter :-(

Wie hast du ""lsof" installiert? Über Entware oder irgendwelche Syno Tools?

lsof ist in synogear drin. Wurde aber auch über die CLITools installiert.

 

[maxblank]

Da stehen doch die PIDs drin. Ich habe dir doch oben extra Screenshots gepostet. Was hilft da denn nicht weiter?

 

[framp]

Anbei habe ich Screenshots angefügt. Aber ich sehe da nur md2_defer0 und md2_defer1. Beim ersten Screenshot von anderen PIDs seiht man was aufgerufen wird. Aber nicht bei den md2_defer0/1. D.h. die Screenshots helfen mir leider nicht weiter um rauszufinden was das RAID blockiert :-(

(synogear) root@synology:/# ps -fp 13476
UID        PID  PPID  C STIME TTY          TIME CMD
root     13476     2  0 Apr25 ?        00:00:18 [md2_defer0]
(synogear) root@synology:/# ps -fp 2
UID        PID  PPID  C STIME TTY          TIME CMD
root         2     0  0 Apr25 ?        00:00:00 [kthreadd]

Wie man sieht ist die PPID 2 und das ist kthreadd. Was ein ktheradd ist steht z.B. hier. Hilft mir aber leider nicht weiter :-(

 

[framp]

kthreadd Link

 

[Benares]

Ich hab mal nach "synospace" "--stop-all-spaces" gegoogelt und dabei das hier gefunden:
https://www.apvnorge.no/how-to-properly-do-a-filesystem-check-fsck-or-e2fck-on-synology-dsm-7/

Die machen da nach

synospace –stop-all-spaces

noch ein

touch /tmp/volume_skip_check
synosetkeyvalue /etc/synoinfo.conf disable_volumes volume1

und einen Reboot bevor sie weiter machen

Vielleicht hilft das ja.

 

[framp]

Danke für den Link Das sieht sehr interessant und passend aus. Keine Ahnung warum ich das nicht gefunden habe denn ich bin auch kräftig am Suchen.

 

[framp]

Dem Besitzer der 1817 mit den beiden DXen gefällt der Vorschlag von @DaveR - ein zweifach Diskgehäuse mit Clonefunktion zu nutzen - und will so clonen. Somit kann ich nicht testen ob die verlinkte Anleitung zum Auschalten eines RAIDs funktioniert Hätte ich gerne getan.

Vielleicht hat ja zukünftig noch mal jemand das Problem, findet diesen Thread mit dem Link und kann seine Erfahrung teilen

 

[framp]

Nachtrag:

Hintergrund dieser Aktion war dass alle 5 Plalten eines defeckten btrfs RAID5s gecloned werden sollten um danach zu versuchen das RAID5 zu reparieren da leider kein Backup existiert. ( Der Besitzer der 1817 hat jetzt verstanden dass ein RAID kein Backup ist und ist dabei seine Daten jetzt zu sichern )

Genaugenommen ist das RAID5 nicht defekt sondern das Filesystem. Wenn man in ein bestimmtes Unterverzeichnis geht hängt sich die 1817 auf und muss hart restartet werden.

Die Clonerei ging mit dem 2Slot Gerät langsam (Eine 6 TB Platte brauchte immer so einen Tag) aber nachdem die Originalplatten durch die geclonten Platten ersetzt wurden war das RAID5 mit seinem Fehlverhalten wieder da als wären die Originalplatten drin.

Ich habe in der Zeit viel im Netz gesucht und diverse Hinweise gefunden. Letztendlich fand ich auch einen Mailthread bei den btrfs Entwicklern. Dort schrieb jemand man solle zuerst ein scrubbing machen. Und Ihr werdet es nicht glauben: Danach war das Filesystem wieder OK und auf die Folder konnte wieder zugegriffen werden Der Besitzer der 1817 ist happy und kopiert gerade seine verlorengedachten Daten ... und wird sie zukünftig auch sichern. D.h. btrfs hat offensichtlich auch Redundanzen im Filesystem die sich durch Scrubbing fixen lassen. Gut zu wissen ...

Manchmal ist die Lösung doch so einfach ... ich habe das Scrubbing von der Commandline gestartet. Im DSM wäre es selbst für den Besitzer ganz einfach zu starten gewesen.

 

[maxblank]

War das Volume dabei gemountet?
Hast du deine Vorgehensweise samt Befehlen noch und könntest diese bitte hier posten?

 

[framp]

Wie ich schon schrieb reicht es das Scrubbing im Storagemanager anzuschmeissen und dabei muss das Volume gemounted sein.

Anbei der vollsändigkeitshalber ncoh die Commands auf der Console:

btrfs scrub start -Bd <mountpoint> #start scrubbing
btrfs scrub status <mountpoint> # check scrubbing status

Ob Adminrechte ausreichen weiss ich nicht. Ich habe die Befehle als root abgesetzt.

 

[maxblank]

Das hatten wir in einem anderem Thema ebenfalls versucht, sowohl über GUI als auch über die CMD.
In der dortigen Konstellation hatte es leider nicht funktioniert, daher mein Interesse. Danke dir!