Kein spin down mehr von einer Platte


megabait

Recommended Posts

Hallo, 

Ich habe bemerkt, dass eine meiner Platten nicht mehr runterfährt. Könnt ihr mit einen Tipp geben, wo ich suchen kann wer da dauernd auf die Platte schreibt? Oder kann es auch an was anderem liegen? Ich würde gern erst selber suchen, damit ich das System besser verstehe, deshalb nur ein paar Tipps.

 

Link to comment
28 minutes ago, megabait said:

Ich habe bemerkt, dass eine meiner Platten nicht mehr runterfährt. Könnt ihr mit einen Tipp geben, wo ich suchen kann wer da dauernd auf die Platte schreibt? Oder kann es auch an was anderem liegen? Ich würde gern erst selber suchen, damit ich das System besser verstehe, deshalb nur ein paar Tipps.

Welche Ordner liegen denn auf der Platte, liegt irgend ein System Ordner (appdata, domains, system) auf dieser disk?

Hast du einen Cache Pool?

Am besten siehst du das wenn du ganz rechts im Main Tab hier klickst:

grafik.png.3c4efb5dfdbbea3dcd5dbfb39e55ab58.png

Link to comment

Danke für die schnelle Reaktion!

1. Also ich habe eine Cache-Platte

2. Belegung Ordner sieht aus wie im Bild. Falls ich da was falsc/blöd gemacht habe, bin ich für jeden Tipp dankbar.

3. Dann hab ich noch ein Datenträgerprotokoll angehängt, spinnt immer down, dann kommt aber immer dieses read smart ...?

 

 

freigaben-berechnet.jpg

datenarray.jpg

Link to comment

Auf den ersten Blick sieht es nach den Dockerdaten aus, wenn denn Docker Container laufen die Daten auf die Array HD loggen.

 

Und ich würde alle Dockercontainer stoppen, dann den Mover laufen lassen. Und dann würde ich direkt unter /mnt/diskx schauen ob noch Appdata/system/domains Folder auf den separaten Platten des Arrays liegen.

 

Wenn nein würde ich AppData/Domains und System auf Cache Only stellen. 

 

Gruss,

Joerg

Link to comment
9 hours ago, MPC561 said:

Wenn nein würde ich AppData/Domains und System auf Cache Only stellen. 

Nutzt du Cache Only bei einem vorgelagerten SSD Cache und der läuft voll, schmieren dir die Container ab, weil sie keine Daten mehr schreiben können.

 

Diesen Nachteil hat man nicht, wenn man Prefer nutzt, die Container Pfade auf /mnt/cache ändert und einen Min Free Space beim Cache Pool einstellt. Denn dann läuft die SSD niemals voll, die Container haben noch genug Platz zum Schreiben und /mnt/cache umgeht Fuse und entlastet damit massiv die CPU.

 

Aber das (und auch Cache Only) empfehle ich nur Fortgeschrittenen, die Backups haben und die verschiedenen unRAID Pfade verstanden haben.

  • Like 1
Link to comment

@mgutt

 

Ist mir schon klar Marc. Mir ging's eher darum das er sein Problem los wird das die eine Platte permanent läuft. Deswegen wie oben beschrieben erstmal Mover damit alles auf den Cache geschoben wird (DC aus) was wirklich ins AppData Verzeichnis etc. gehört und dann nochmal checken ob da nicht noch unberechtigterweise was auf dem Array rumliegt und Cache Only zum testen.

 

Dann darf auf den HDDs nichts mehr sein. Wenn dann doch wieder was auftaucht hat er ein Problem mit einem Dockerpfad der aufs Array schreibt. (Was er vermutlich eh hat wenn ich mir die Freigaben oben anschaue).

 

Wenn er das alles sauber hat kann er wieder auf Prefer beim Cache umstellen.

 

Gruss,

Joerg 

Edited by MPC561
Link to comment
1 hour ago, MPC561 said:

und dann nochmal checken ob da nicht noch unberechtigterweise was auf dem Array rumliegt und Cache Only zum testen.

a) es gibt AFAIK keinen Container, der als Pfad /mnt/diskX voreingestellt hat

 

b) wenn es so wäre, würde Cache Only nichts daran ändern. Die Cache Einstellung hat keinen Einfluss auf Disk Pfade

 

c) lässt man es auf Prefer und schaut in den Appdata Ordner, dann sieht man doch an Hand der Location welcher Container auf das Array schreibt. Dafür muss man nicht extra auf Cache Only wechseln.

 

Link to comment
15 minutes ago, mgutt said:

a) es gibt AFAIK keinen Container, der als Pfad /mnt/diskX voreingestellt hat

 

 

Mag sein aber trifft hier in dem Fall nicht zu wage ich zu behaupten:

 

Siehe oben die Freigabe "Dockerdaten". Die liegt auf dem Array und nicht dem Cache. Das bedeutet er hat entweder Standardpfade von Containern auf das Array gelegt oder neue Pfade eingefügt die auch aufs Array verweisen. 

 

Zu b) und c) Du hast natürlich recht. 

Link to comment
7 minutes ago, MPC561 said:

Siehe oben die Freigabe "Dockerdaten". Die liegt auf dem Array und nicht dem Cache. Das bedeutet er hat entweder Standardpfade von Containern auf das Array gelegt oder neue Pfade eingefügt die auch aufs Array verweisen. 

Ich beantworte hier ja schon seit einiger Zeit Anfragen und ich kann dir sagen, dass das zu 99% passiert, weil der Nutzer erst das Array eingerichtet hat und nach dessen Start den Cache Pool. Dh Docker wurde auf dem Array installiert, die Dateien sind in Nutzung und können vom Mover nicht vollständig auf den Cache Pool verschoben werden. Ein Klassiker im Forum und ja auch simpel lösbar, wie bereits beschrieben.

 

Allerdings lesen manche Nutzer im Forum "Cache-Only", verstehen den Kontext nicht, stellen darauf um, ohne den Mover erst alles bewegen zu lassen und schon sind alle Container zerschossen, weil sie sich zum großen Teil neu installieren. Diesen Fall haben wir hier immer wieder zu beklagen, weshalb ich ja schon mal vorgeschlagen habe, dass der Nutzer eine Warnung erhalten soll:

https://forums.unraid.net/topic/102826-add-warning-to-use-cache-share-settings-and-disallow-change-for-appdata-share/

 

Bei den restlichen 1% hatte der Nutzer einen voll gelaufenen Cache und dank Prefer, wurde auf das Array ausgewichen. Auch hier wäre die Umstellung auf Cache-Only tödlich für die Container.

 

Das war's. Andere Fälle hatten wir noch nie.

 

Ich mein wie soll das auch gehen. Der Nutzer stellt einen Pfad auf /mnt/disk5/appdata/dockername und vergisst dann, dass er das gemacht hat und wundert sich im Anschluss, dass Disk 5 dauerhaft läuft?! Und was genau ändert Cache-Only an dieser Vergesslichkeit? Er muss doch nur auf den Shares > appdata > Ordner-Icon klicken und sich die Spalte Location anschauen und schon sieht er, dass in diesem Beispiel bei bitwarden was nicht stimmt:

image.png.8a7ffb1dda4c512092e906aad5a56b67.png

 

Dafür muss man doch nicht irgendwelche Cache-Einstellungen ändern?!

 

 

 

 

Link to comment

Mit Cache Only waren wir doch schon durch. Muss nicht sein, hast Du recht. Und ja ich weiss das viele dahingehend Fehler machen, ich musste das auch hart lernen (um es mal so zu formulieren). 

 

Aber nun sieh Dir bitte! nochmal oben seine Freigaben an. 

 

Da gibt es eine Freigabe "Dockerdaten" mit Cache=nein.

 

Was wird da wohl vermutlich drin sein? Ich vermute stark das es Logs von Dockercontainern sind die er statt in Cache/AppData hart auf /mnt/user/diskx legt. 

Einige Host Pfade verweisen vermutlich auf /mnt/user/AppData, andere Hart auf /mnt/diskx/Dockerdaten/xxx. Würde mich nicht wundern wenn das jemand macht um die SSD zu schonen.

 

 

Und ja es kann natürlich auch ein Problem sein das er den Cache erst später angelegt hat.

 

 

Jetzt muss der Kollege mal antworten sonst rätseln wir hier noch ewig.

 

 

Gruss,

Joerg

 

 

 

 

 

Edited by MPC561
Link to comment
22 minutes ago, MPC561 said:

Ich vermute stark das es Logs von Dockercontainern sind die er statt in Cache/AppData hart auf /mnt/user/diskx legt. 

Jo, Appdata enthält aber eigentlich keine Logs, sondern die Nutzerdaten eines Containers. Die Logs liegen nichts sichbar im docker.img in einem kryptischen Pfad.

 

Wenn es um "Dockerdaten" geht, wird aber Cache Only nicht helfen. Denn wenn er No eingestellt hat, ist der Mover ja für diesen Share bereits deaktiviert und mit Cache Only bleibt er das ja. Er müsste erstmal Docker deaktivieren, Dockerdaten auf Prefer stellen und dann den Mover anschmeißen. Wobei eh die Frage ist warum der Share überhaupt erstellt wurde.

 

@megabait

Erkläre mal bitte warum du "Dockerdaten" erstellt hast? Exakt für diesen Zweck ist der Standard-Share "appdata" gedacht. Wenn es darum geht einen deutschen Namen zu haben, dann weißt du hoffentlich, dass du nicht nur einfach einen zusätzlichen Share erstellen musst, sondern auch in den Docker-Einstellungen den Pfad anpassen musst:

image.png.28e39a1ee2c537fb9b79b38c7a92fcf1.png

 

Machst du das nicht, werden neue Container nach wie vor überall /mnt/user/appdata voreingestellt haben.

 

Und dass Disk 1 ständig läuft, wenn du Disk 1 bei Dockerdaten als Speicherplatz wählst während du den Cache auf "No" gestellt hast, ist ja denke ich logisch 😉

  • Like 1
Link to comment
  • 1 year later...

Hallo,

ich bin relativ neu im unRaid Thema und habe gerade erst mein System (ein MiniPC) aufgesetzt. Seit Begin fährt die 1. Arrayplatte nicht runter. Es liegen dort definitiv keine Systemdateien mehr drauf (alle im Cache)

root@HomeServer:/mnt/disk1# ls -la /mnt/disk1/
total 8
drwxrwxrwx  5 nobody users   49 Mar 30 00:34 ./
drwxr-xr-x 11 root   root   220 Mar 30 00:29 ../
drwxr-xr-x 10 nobody users  161 Mar 29 00:23 FilerunData/
drwxrwxrwx 19 nobody users 4096 Mar 29 09:29 Temp/
drwxrwxrwx  2 nobody users 4096 Mar 30 08:49 isos/

Die VMs haben derzeit auch keine ISO aus dem isos Verzeichnis eingebunden.

Und solange ich nicht über die App Filerun zugreife, sollten auch keine Daten von der Platte gelesen werden?

Link to comment
25 minutes ago, ThomasH71 said:

Seit Begin fährt die 1. Arrayplatte nicht runter. Es liegen dort definitiv keine Systemdateien mehr drauf (alle im Cache)

root@HomeServer:/mnt/disk1# ls -la /mnt/disk1/
total 8
drwxrwxrwx  5 nobody users   49 Mar 30 00:34 ./
drwxr-xr-x 11 root   root   220 Mar 30 00:29 ../
drwxr-xr-x 10 nobody users  161 Mar 29 00:23 FilerunData/
drwxrwxrwx 19 nobody users 4096 Mar 29 09:29 Temp/
drwxrwxrwx  2 nobody users 4096 Mar 30 08:49 isos/

Die VMs haben derzeit auch keine ISO aus dem isos Verzeichnis eingebunden.

Ich weiss jetzt nicht ob das ISOS Verzeichnis die Platte wach hält, aber das ist eines der üblichen Systemverzeichnisse.

Vielleicht das Verzeichnis (auch wenn es leer ist) mal auf den zuständigen Cache verlagern.

 

Link to comment
2 hours ago, ThomasH71 said:

Es ist zwar nicht mehr leer, habe da gerade erstmal meine ISOs abegelgt, die ich noch gefunden habe. Aber ich kann mal versuchen die Daten zu verschieben.

das /iso Verzeichnis ist an sich kein echtes system Verzeichnnis, solange  davon nichts mounted wäre ... passiert auch nichts.

 

ich tippe auf das filerun Verzeichnis, wird wahrscheinlich der Nextcloud Kiste ähneln dass da nicht nur reine User Date liegen sondern ...

 

schau doch mal in das Verzeichnis was da alles so liegt ... wenn da mehr außer den user directorys liegt ... sollte es selbsterklärend sein ...

Link to comment
2 hours ago, ThomasH71 said:

Es ist zwar nicht mehr leer, habe da gerade erstmal meine ISOs abegelgt, die ich noch gefunden habe. Aber ich kann mal versuchen die Daten zu verschieben.

ich nutze dazu den mc, weil der schnell und robust verfschieben (erst kopieren, danach löschen) kann.

 

Aber ich habe bei einem meiner 6.12.0-rc2 Systeme das Problem, daß sich 2 normale Usershares (obwohl sie leer sind) nicht löschen lassen. unter 6.11.5 stable hatte ich dieses Problem nie.

Link to comment
5 hours ago, DataCollector said:

ja

 

Dachte ich mir. Kannst Du einen leeren Ordner unterhalb (!) von AEV manuell (!) löschen?

 

Nur noch mal für mich: AEV wurde während des Kopierens von Windows unterhalb von "cachesam" als Teil eines Kopiervorgangs automatisch angelegt?

 

Bin sehr gespannt. Habe da so meinen Verdacht.

 

Edited by hawihoney
Link to comment
4 hours ago, hawihoney said:

Dachte ich mir. Kannst Du einen leeren Ordner unterhalb (!) von AEV manuell (!) löschen?

Wie manuell?

Ich hatte in dem verlinkten bug report ja schon dargestellt, dass ich es manuell über mc, krusader und filemanager plugin probiert habe: erfolglos.

Console habe ich noch nicht probiert, würde ich aber auch ungerne machen.

Erst mit mc die Dateien so verschieben wie ich es (anders als Mover Standardeinstellungen) durchführen will um danach dann die eigentlich in mc sonst mögliche Löschung (vollautomatisch mit dem verschieben in/mit mc) per console nochmal anzustossen ist nicht so mein Wunsch.

Mover hat bisher mehrfach selber das leere Verzeichnis auch nicht vom ZFS Poll/Cache löschen können.

 

Aktuell liegt da wieder etwas drin und wird recodiert, weshalb ich nun in diesem Moment nicht weiter probieren kann (sollte sich aber heute abend erledigt haben).

 

4 hours ago, hawihoney said:

Nur noch mal für mich: AEV wurde während des Kopierens von Windows unterhalb von "cachesam" als Teil eines Kopiervorgangs automatisch angelegt?

AEV ist ein Share im Array.  Dem Array ist der Cache (Pool SSDs zfs) vorgeschaltet.

AEV auf dem Array ist vorhanden und enthält Dateien.

AEV auf dem Cache (Pool SSDs zfs) wird logischerweise erst angelegt, wenn ich von (beispielsweise außerhalb/extern Windows PC) über Netzwerk Dateien in unraid Share AEV kopiere/verschiebe.

Dann sind logischerweise Dateien im Cache drin.

 

Wenn ich aber weiss, dass ich die in unraid an einer bestimmten Stelle haben will (ggf. abweichend von Mover Standardeinstellung), nehme ich schnell mal den mc und verschiebe das Verzeichnis (incl. enthaltenen Dateien) vom Cache zu der von mir gewünschten Stelle.

Und es bleibt seit Umstellung auf 6.12.0-rc2 und zfs auf einmal das Verzeichnis leer auf dem cache stehen.

 

Link to comment
5 hours ago, DataCollector said:

Wie manuell?

 

MC, ...

 

5 hours ago, DataCollector said:

AEV ist ein Share im Array.

 

Ich dachte es geht um "cachesam" und das ist eindeutig ein ZFS Pool. "cachesam" liegt gem. Deiner Screenshots definitiv nicht auf dem Array. Und das Löschen von AEV auf dem Pool scheitert. So mein Verständnis und daraus hatte ich abgeleitet:

 

"cachesam" ist ein ZFS-Pool. Nun kopierst Du von extern Dateien und Ordner darauf. Darunter befindet sich der Ordner "AEV" und unter "AEV" ggfs. weitere Unterordner. Meine Frage oben zielt darauf ab, ob es einen Unterschied beim Löschen von AEV oder einem Unterordner von AEV gibt. Das wiederum kann Aufschluss darauf geben ob AEV ggfs. als Dataset automatisch angelegt wird und ob AEV zu einem User-Share wird (wie beim Array). Ich habe noch nie in den vergangenen 15 Jahren mit Unraid permanent Wurzelordner (AEV) angelegt und wieder gelöscht. Da diese ja eigentlich zu "User-Shares" werden kann es durchaus sein, dass Unraid diese unter ZFS besonders behandelt bzw. behandeln muss.

 

Dass die Doku angepasst werden muss ist jedem klar. Schon alleine das ZFS Pools Cache-Only benötigen um korrekt zu funktionieren weicht heftig vom Array ab. Aber das wurde schon kommuniziert und bestätigt. Der Cache ist ein Dinosaurier und spätestens mit ZFS muss der anders deklariert und behandelt werden.

 

Wenn ich das falsch verstanden habe, sorry. Wenn das Wurzelverzeichnis AEV permanent auf dem cachesam Pool verbleiben würde, dann tippe ich, dass Du diese Probleme nicht hättest. Deshalb würde mich interessieren ob Du auch Probleme mit dem Löschen von Unterordnern von AEV hast.

 

image.png.275fadccedf2463e1716e2265edaa6cc.png

 

image.thumb.png.0bce9003f1d6e34768686fe9b4f5f5e5.png

 

 

Edited by hawihoney
Link to comment
1 hour ago, hawihoney said:

Ich dachte es geht um "cachesam" und das ist eindeutig ein ZFS Pool. "cachesam" liegt gem. Deiner Screenshots definitiv nicht auf dem Array.

"cachesam" ist der SSD Pool (3 SSD als zfs z1 Raid5)

 

 

1 hour ago, hawihoney said:

Und das Löschen von AEV auf dem Pool scheitert.

Korrekt.

Ich befehle dem mc das gesamte (von unraid selber angelegte) Verzeichnisse AEV vom SSD Pool "cachesam" Files wo anders hin zu verschieben.

Der mc startet und kopiert alles auf das Ziel.

Danach löscht mc automatisch die Dateien und Verzeichnisse und scheitert bei dem Verzeichnis AEV.

Das Verzeichnis AEV bleibt leer im SSD Pool "cachesam" stehen.

 

1 hour ago, hawihoney said:

So mein Verständnis und daraus hatte ich abgeleitet:

"cachesam" ist ein ZFS-Pool. Nun kopierst Du von extern Dateien und Ordner darauf. Darunter befindet sich der Ordner "AEV"

Nein. ich kopiere/verschiebe von extern (WinPC  über SMB) nur Dateien in das unraid Share AEV welches auf dem Array vorhanden und mit Verzeichnissen und Dateien gefüllt ist.

Da dem Share AEV auf dem Array  der SSD Pool Cachesam zugeordnet ist, schreibt unraid logischerweise diese Sachen in das von ihm dann dort selbst neu erstellte Verzeichnis AEV  die kopierten/verschobenen einzelnen Dateien hinein.

Genau so, wie es sein soll, da der Cache ja die Schreibzugriffe auf das Array abfangen soll und unraid damit selbstständig das selbe Verzeichnis, welches auf den Array vorhanden ist auch auf dem Cache anlegt.

 

1 hour ago, hawihoney said:

Meine Frage oben zielt darauf ab, ob es einen Unterschied beim Löschen von AEV oder einem Unterordner von AEV gibt.

Es gibt nur AEV in oberster Ebene.

Es gibt keinen Unterordner namens AEV unter dem Share AEV.

 

1 hour ago, hawihoney said:

Ich habe noch nie in den vergangenen 15 Jahren mit Unraid permanent Wurzelordner (AEV) angelegt und wieder gelöscht.

1. mache ich das auch nicht permanent, sondern lege ich Sharea über die GUI (Shares-Tab) an.

unraid selber legt aber beim darauf schreiben auf dem Cache die selben Verzeichnisse an, weil der Cache eingehende Dateien ja identisch einsortiert um sie später per mover ins Array schieben zu können.

 

1 hour ago, hawihoney said:

Schon alleine das ZFS Pools Cache-Only benötigen um korrekt zu funktionieren weicht heftig vom Array ab.

Ich habe auch auf dem anderen System ein HDD Pool zfs Cache only, den ich gerade befüllt habe. ich hoffe ich stoße da nicht auch auf probleme, da sich so ca. 36TB Daten nicht mal schnell verschieben/kopieren lassen.    (Backups/Originale sind vorhanden).

1 hour ago, hawihoney said:

Der Cache ist ein Dinosaurier und spätestens mit ZFS muss der anders deklariert und behandelt werden.

Mich irritiert eben, daß ich einfache Dateioperationen (Verzeichnis löschen) auf dem ZFS Cache in dem Fall nicht wie gewohnt ausführen lassen kann.

Da es unter der Vorgängerversion mit BTRFS ging und ich das auch von Windows so gewohnt war, ist das für mich ein Ärgerniß.

 

1 hour ago, hawihoney said:

Wenn ich das falsch verstanden habe, sorry.

Kein problem. Da ich bei zfs neu bin drücke ich mich wahrscheinlich auch nicht genau genug aus.

1 hour ago, hawihoney said:

Wenn das Wurzelverzeichnis AEV permanent auf dem cachesam Pool verbleiben würde, dann tippe ich, dass Du diese Probleme nicht hättest.

Da Wurzelverzeichnis AEV auf dem Cache, der ja nur temporärer Zwischenspeicher ist, will ich dort nur sehen, wenn unraid da auch etwas drin hat. Wenn es leer ist erwarte ich, daß ich es manuell (mc/krusader) nach belieben löschen kann oder timergesteuert (oder manuell angestoßen) der Mover das wegräumt.

 

1 hour ago, hawihoney said:

Deshalb würde mich interessieren ob Du auch Probleme mit dem Löschen von Unterordnern von AEV hast.

Ich habe dort zwar selten unterordner drin, aber bisher besteht mein problem nicht darin den Inhalt von AEV zu verschieben (und damit da raus zu löschen). Nur der AEV auf dem cache selber stellt sich da quer.

 

Link to comment
31 minutes ago, DataCollector said:

Ich befehle dem mc das gesamte (von unraid selber angelegte) Verzeichnisse AEV vom SSD Pool "cachesam" Files wo anders hin zu verschieben.

 

31 minutes ago, DataCollector said:

Nein. ich kopiere/verschiebe von extern (WinPC  über SMB) nur Dateien in das unraid Share AEV welches auf dem Array vorhanden und mit Verzeichnissen und Dateien gefüllt ist.

 

Ich denke, dass diese Vorgehensweise nicht im Sinne des Erfinders ist. Du hast dem User-Share AEV im Array einen ZFS-Pool "cachesam" vorgeschaltet. Solange AEV auf dem Array existiert, wird wohl AEV auch auf dem Pool existieren. Du hast ja auch eingestellt, dass diese Verknüpfung existiert. Ich arbeite nicht mit User-Shares deshalb muss ich fragen: Wie ist das mit einem BTRFS Pool? Würde der Mover zum Abschluss den Ordner AEV auf dem Pool löschen?

 

Meines Erachtens wird mit ZFS ein User-Share auf einem Pool zu einem Dataset. Der Unterschied zwischen BTRFS und ZFS wäre dann nach meinem Verständnis: BTRFS legt den User-Share Ordner automatisch per MKDIR auf dem Pool an und löscht ihn - wenn der User-Share gelöscht wird - mit RMDIR. ZFS hingegen legt mit create einen Dataset an und der muss mit destroy gelöscht werden. MC kennt und kann das aber nicht. Nur mit mkdir erzeugte Ordner können mit rmdir gelöscht werden. IMHO musst Du nix anderes machen als die Finger vom Root-Ordner AEV zu lassen ...

 

32 minutes ago, DataCollector said:

Mich irritiert eben, daß ich einfache Dateioperationen (Verzeichnis löschen) auf dem ZFS Cache in dem Fall nicht wie gewohnt ausführen lassen kann.

Da es unter der Vorgängerversion mit BTRFS ging und ich das auch von Windows so gewohnt war, ist das für mich ein Ärgerniß.

 

Du spielst mit einem RC - das ist noch nicht für den ernsthaften Betrieb gedacht. Außerdem ist die ZFS Integration laut des Announcements erst mit dem nächsten Release komplett. An dieser Stelle lohnt es sich somit, einen Schritt abzuwarten. Auch ich warte auf einen besseren Pool, aber das alles schreckt mich noch ab. Meiner persönlichen Meinung nach muss Limetech nochmal zurück ans Reißbrett um das Verhältnis Array <-> Cache <-> ZFS-Pool glatt zu ziehen.

 

Link to comment
1 hour ago, hawihoney said:

Ich denke, dass diese Vorgehensweise nicht im Sinne des Erfinders ist. Du hast dem User-Share AEV im Array einen ZFS-Pool "cachesam" vorgeschaltet. Solange AEV auf dem Array existiert, wird wohl AEV auch auf dem Pool existieren.

Nein, tut es nicht.

Wenn AEV leer ist, sollte der Mover oder der user manuell den verschwinden lassen (können).

 

Nur so am Rande: Da die Bearbeitung der Daten in AEV nun fertig ist, habe ich vorhin es nochmal versucht:

AEV war leer und ich habe diesesmal direkt den Mover manuell angestossen und: AEV wurde von dem zfs Cache entfernt. genau so, wie es sein soll.

 

Nun muss ich nur noch rausbekommen, wie ich am bequemsten das gleich mit dem mc oder krusader hinbekomme.

 

1 hour ago, hawihoney said:

Du hast ja auch eingestellt, dass diese Verknüpfung existiert. Ich arbeite nicht mit User-Shares deshalb muss ich fragen: Wie ist das mit einem BTRFS Pool? Würde der Mover zum Abschluss den Ordner AEV auf dem Pool löschen?

Beim BTRFS Pool lief es genau so, wie ich wollte und deshalb auch auf dem zfs Pool erwartet hatte:  Ich konnte jederzeit manuell die Verzeichnise auf dem Cache/Pool manuell bearbeiten und löschen.

 

1 hour ago, hawihoney said:

Dataset - MC kennt und kann das aber nicht.

Das mag sein. Ich gebe zu. Dataset sagt mir (noch) nichts, aber da muss ich dann eben wohl noch lernen.

In die vergkleichbare Richtung geht es auch in dem verlinkten Bugreport von mir.

Nur sträube ich mich eben nachdem ich (fast) alles mit mc machen kann und konnte. daß ich dann im nachgang nochmal mit der console hinterher muß, wenn ich manuell diese Verzeichnisse loswerden will.

 

1 hour ago, hawihoney said:

Nur mit mkdir erzeugte Ordner können mit rmdir gelöscht werden. IMHO musst Du nix anderes machen als die Finger vom Root-Ordner AEV zu lassen ...

Das ist ja nur einer von vielen. DATA hatte ich auch erwähnt und ich wollte jetzt auch nicht alle auflisten, da es noch mehr verwirrt hätte.

 

Und da ich das Verhalten von BTRFS nicht kannte und eigentlich für ein Problem/Fehler halte habe ich eben den BugReport aufgemacht.

genau darum um eben limetech dazu zu bringen das wieder etwas userfreundlicher zu gestalten. Genau dafür sind ja Tests mit RC da.

(Wie schon erwähnt, ich habe Backups! Mit einzigartigen und unwiderbringlichen Daten wüßrde ich etwas weniger experimentieren).

 

Edited by DataCollector
Link to comment
22 hours ago, alturismo said:

das /iso Verzeichnis ist an sich kein echtes system Verzeichnnis, solange  davon nichts mounted wäre ... passiert auch nichts.

 

ich tippe auf das filerun Verzeichnis, wird wahrscheinlich der Nextcloud Kiste ähneln dass da nicht nur reine User Date liegen sondern ...

 

schau doch mal in das Verzeichnis was da alles so liegt ... wenn da mehr außer den user directorys liegt ... sollte es selbsterklärend sein ...

Bei mir liegt auf der entsprechenden disk nur die Dateien, die ich oben gepostet habe.  Ich habe jetzt mal die App FileRun beendet, danach sollten die Daten ja nicht mehr gelesen werden. Die Platte fährt immer noch nicht runter. Allerdings blinkt die LED von der externen Disk etwa aller 30 Sekunden, d.h. irgendwas greift da noch lesend drauf zu, das wird wohl der Grund sein, warum sie nicht in den Ruhezustand geht. 

Link to comment

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Restore formatting

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.