Hallo,
ich hatte heute morgen Ordner auf den Seafile Server kopiert “Webgui” und ging dann auf abrechen.
Ich dachte, dass von diesem Ordner nichts kopiert worden ist.
Jedoch war der Order unter /home/seafile/haiwen/seafile-data/storage/blocks schon mit 33M belegt.
Git es da eine Möglichkeit, dass beim abrechen vom kopieren die Dateien gelöscht werden ?
Liebe grüsse
guten morgen,
dass hatte ich auch getestet, allerdings ohne Erfolg.
der Ordner blocks hatte ca. 300k, nach dem hochladen einer ISO hatte dieser 291M. Nach dem löschen der ISo Datei und einem Server stop
sudo -u seafile /home/seafile/haiwen/seafile-server/seaf-gc.sh
und Server start hatte dieser immernoch 291M ?
oder habe ich da etwas übersehen?
liebe grüsse
Hallo,
ich hatte nun die Dateien per Console gelöscht. rm -r block-id
Es ist aber nicht Sinn der Sache, alles gelöschte im Webgui “ID-block” mit dem Inhalt “dem Order blocks” zu vergleichen.
Bin ich der einzige, der dieses Problem hat?
Da gibt es schon einige Einträge im Forum.
Bei der pro. Version klappt dass ganze.
Wäre für jeden Tipp dankbar.
schönes Wochenende
Und wie hast du die Block ID herausgefunden? Sieht eher so aus als hättest du die ganze Bibliothek gelöscht.
Wie wurden die Versionen für die Bibliothek konfiguriert?
Hallo ork23, ich hatte mal einen ähnlichen Fall.
Wenn du eine Datei aus einer Bibliothek löschen tust, wandert diese erst in den Papierkorb. Im Webgui kann man den Papierkorb nochmal extra leeren, erst dann wird die Datei auch vom Garbage Collector erfasst.
Viele Grüße
Dennis
Guten morgen Dennis,
ja, hatte ich auch versucht. Geht aber leider immer noch nicht!
291M 0868ba1b-61af-4622-a630-e16c6d6e0841
Dass wird langsam zum Problem. Hätte da jemand einen Tipp weshalb das Scipt nicht greift?
Im Webgui hat die Bibliothek 0 / 0 Bytes? Die Mülleimer sind alle LEER?!
Das Problem scheint aber bekannt zu sein. Wie erkäre ich dass nun meinem Kunden?
Wäre für jeden Tipp dankbar.
System Ubuntu 18 LTS / 6.2.5 64bit
Auf einem Ubuntu 16 LTS genau das gleiche Problem.
vielen dank
Wenn die Bibliothek 0Bytes hat also ich nehme an komplett leer ist, versuche mal die komplette Bibliothek zu löschen, auch hier darauf achten unter dem Menüpunkt “Mehr” gibt es nochmal einen Papierkorb für Bibliotheken, auch dort aufräumen, dann seafile stoppen und seaf-gc laufen lassen. Spätestens dann müsste die ID 0868ba… rausfliegen.
…
Hallo,
einmal mit 30 Tagen, dann ohne Begrenzung
Ich habe ein Bib TEST erstellt. In dieser befindet sich eine ISO von ca. 300 MB. Auf der Consloe einen
du -sch *
304K 0868ba1b-61af-4622-a630-e16c6d6e0841
8.0K 997b9a41-cfa0-4c85-b0fd-e3fe30623b39
293M a2e014c9-9b25-4d84-852f-3fe8d255c45d
Jetzt lösche ich das ISO File
“342.01-desktop-win8-win7-winvista-64bit-international.exe ist gelöscht”
Dann gehe ich in den Papierkorb “Keine gelöschten Bibliotheken vorhanden”
Im Sysadmin
TEST 0 / 0 Bytes a2e014c9-9b25-4d84-852f-3fe8d255c45d info@grafjochen.de
Auf der Console
293M a2e014c9-9b25-4d84-852f-3fe8d255c45d
Danach
Stopping seafile server …
Done.
Stopping seahub …
Done.
sudo -u seafile /home/seafile/haiwen/seafile-server/seaf-gc.sh
Starting seafserv-gc, please wait …
[08/13/18 13:21:29] gc-core.c(440): GC version 1 repo TEST(a2e014c9-9b25-4d84-852f-3fe8d255c45d)
[08/13/18 13:21:29] gc-core.c(313): GC started. Total block number is 37.
[08/13/18 13:21:29] gc-core.c(46): GC index size is 1024 Byte.
[08/13/18 13:21:29] gc-core.c(327): Populating index.
[08/13/18 13:21:29] gc-core.c(181): Populating index for repo a2e014c9.
[08/13/18 13:21:29] gc-core.c(234): Traversed 3 commits, 37 blocks.
[08/13/18 13:21:29] gc-core.c(341): Scanning and deleting unused blocks.
[08/13/18 13:21:29] gc-core.c(364): GC finished. 37 blocks total, about 37 reachable blocks, 0 blocks are removed.
[08/13/18 13:21:29] gc-core.c(440): GC version 1 repo My Library Template(997b9a41-cfa0-4c85-b0fd-e3fe30623b39)
[08/13/18 13:21:29] gc-core.c(313): GC started. Total block number is 1.
[08/13/18 13:21:29] gc-core.c(46): GC index size is 1024 Byte.
[08/13/18 13:21:29] gc-core.c(327): Populating index.
[08/13/18 13:21:29] gc-core.c(181): Populating index for repo 997b9a41.
[08/13/18 13:21:29] gc-core.c(234): Traversed 2 commits, 1 blocks.
[08/13/18 13:21:29] gc-core.c(341): Scanning and deleting unused blocks.
[08/13/18 13:21:29] gc-core.c(364): GC finished. 1 blocks total, about 1 reachable blocks, 0 blocks are removed.
[08/13/18 13:21:29] gc-core.c(440): GC version 1 repo Meine Bibliothek(0868ba1b-61af-4622-a630-e16c6d6e0841)
[08/13/18 13:21:29] gc-core.c(313): GC started. Total block number is 1.
[08/13/18 13:21:29] gc-core.c(46): GC index size is 1024 Byte.
[08/13/18 13:21:29] gc-core.c(327): Populating index.
[08/13/18 13:21:29] gc-core.c(181): Populating index for repo 0868ba1b.
[08/13/18 13:21:29] gc-core.c(234): Traversed 2 commits, 1 blocks.
[08/13/18 13:21:29] gc-core.c(341): Scanning and deleting unused blocks.
[08/13/18 13:21:29] gc-core.c(364): GC finished. 1 blocks total, about 1 reachable blocks, 0 blocks are removed.
[08/13/18 13:21:29] gc-core.c(384): === Repos deleted by users ===
[08/13/18 13:21:29] gc-core.c(456): === GC is finished ===
sudo -u seafile /home/seafile/haiwen/seafile-server/seaf-gc.sh -r
Starting seafserv-gc, please wait …
[08/13/18 13:22:16] gc-core.c(384): === Repos deleted by users ===
seafserv-gc run done
Done.
[08/13/18 13:22:39] …/common/session.c(132): using config file /home/seafile/haiwen/conf/ccnet.conf
Starting seafile server, please wait …
Seafile server started
Done.
LC_ALL is not set in ENV, set to en_US.UTF-8
Starting seahub (fastcgi) at 127.0.0.1:8000 …
Seahub is started
Done.
Der Ornder in blocks ist immer noch
du -sch a2e014c9-9b25-4d84-852f-3fe8d255c45d
293M a2e014c9-9b25-4d84-852f-3fe8d255c45d
gross.
Das bringt mir leider nichts wenn ich die ganze Bib lösche “dann geht es”.
Ich kann ja nicht immer die ganze Bib löschen, damit der Speicher freigegeben wird.
Bin ich hier der einizge mit diesem Problem?
danke liebe grüsse
Nur wenn du einstellst “Versionen nicht Speichern” kann der GC gelöschte Dateien auch sofort löschen. Wenn du einstellst alle Versionen Speichern wird der GC NIE etwas löschen. Und wenn du einstellst X Tage wird der GC erst etwas löschen wenn eine Datei vor mehr als X Tagen gelöscht wurde.
Ansonsten wäre das mit den Versionen ja auch sinnlos. Ich stelle z.B. 30 Tage ein, eine Malware löscht meine Dateien, der Provider lässt automatisch den GC laufen und alle Dateien sind sofort weg statt wie eingestellt für 30 Tage gesichert.
ok, dann werden alle Dateien erst nach x Tagen gelöscht, auch wenn diese im Papierkorb gelöscht worden sind.
Versionen sind zwar gut, aber wenn ich 5 Dateien hochlade mit je 1GB mal 10 Nutzern = 50GB “nur zum Zwischenspeichern für einen Kunden”,
und diese werden in eine Bib geladen mit 30 Tagen Versionen und ich lösche dann alle, schleppe ich dann diese noch
weitere 30 Tage mit auf dem Server und diese müssen dann jedesmal mitgesichert werden und werden erst nach 30 Tagen aus dem Ordner blocks gelöscht.
Wenn der Papierkorb gelöscht wurde, dann brauche ich Dateien auch nicht mehr.
Angenommen ich lösche jede Datei aus dem Papierkorb, im Ornder blocks sind diese aber noch vorhanden.
Wie würde ich denn an diese Dateien kommen? Bzw. wie mache ich da einen Restore davon, ansonsten schleppe ich ja nur Balast mit. Oder ich muss schon bei den Bibs aufpassen, wie lange ich da Versionen vergebe.
Kann ich das Einstellen “global”, dass alle Bibs nru eine Version von 2 Tagen bekommen?
vielen dank für deine Antwort
Du kannst die Versionierung auf 2 Tage begrenzen oder Komplett abschalten, nur den GC brauchst du dann halt noch.
ganz abschalten habe ich gefunden, aber wie kann ich diese Global auf 2 Tage begrenzen?
danke
Ich bin mir gerade nicht 100% sicher. Über die Versionen Seite sollte es jedoch gehen.
da gibt es aber keiner Versionen mehr, da der Papierkorb gelöscht wurde.
Alle Einträge hängen im Ordner blocks!
Mir scheint es so, dass es keiner so genau weiss, wie man dass macht.
Da ich meine Sicherungen mit Bacula fahre, könnte ich mit der exclude " Bib" arbeiten".
Dass kann ja nicht Sinn der Sache sein.
leider bekommt man hier, gar keine Informationen.
Da ich selbst Proxmox mit Seafile anbiete, und nicht mal geklärt werden kann, wie ich den Ballast los werde,
bzw. an diesen kommen könnte, ist dass ganze nur eine finde.
Sorry, aber dass verstehe ich nicht.
danke für deinen Liink, aber dass Löst dass Problem nicht!
Ich muss ganzu offen zugeben, dass Wir Owncloud nutzen und auf Seafile umsteigen wollten.
Naja, dass hat sich wohl erledigt, Die einfachfachsten Fragen, wenn es um die Löschung der Dateien geht.
Bei einer Plattenspiegelung mit Raid 1 habe ich verloren.
Da ich Proxmox anbiete mit ZFS Snapshiots zwei mal.
Es gibt Firmen, die nicht einmal 100GB aus den Hut zaubern können.
Sorry, da fehlt einfach die Info!.
Die Dateien werden vom GC nur gelöscht wenn sie außerhalb der eingestellten Zeit liegen.
Mir ist auch nicht ganz klar was hier passiert ist.
Sind die Dateien denn älter das Konfigurierte Limit?
Inwiefern? Betreibe meinen Seafile Server seit 4 Jahren auf einem RaidZ2 (~Raid 6) mit 4*3 TB, bisher keine Probleme und der GC löscht auch regelmäßig Dateien. Aktuell mehr als 800 000 Dateien von denen ein Großteil über den Client mit Geräten synchronisiert wird (die größte davon hat 275630 Dateien).
Auf Deutsch wird es hier mit den richtigen Antworten auch schwierig, da das Unternehmen, welches Seafile entwickelt keine deutschen Mitarbeiter hat.
Hallo, es ist so, dass die Version Community Edition alle Dateien speichert.
Also, wenn diese für 30 Tage sind “Versionen” , dann werden diese gespeichert, obwohl alles im Papierkorb gelöscht wurde. “Diese werden noch im System behalten”. “30 Tage”.
Wenn ich aber nach dem zweiten Tag die “30Tage” in den Versionen auf 2 Tage setze, klappt dass aber auch nicht.
Lege ich die BIB auf die Version von 30 Tage auf = 0 Tage, dann wird alles im Sytem gelöscht.
Ich habe mich in den letzten Wochen mal damit beschätigt. Da geht sehr vieles, Daten zu behalten, auch wenn die Versionen auf dem Server auf "nicht speichern gesetzt worden sind?
Wie ZB. ZFS Snapsots oder VSS untger Windows.
liebe grüsse