|
|
|
|
|
|
|
|
Warum guckst du nicht direkt auf der Platte, ob da nur noch Nullen sind wenn du ne Datei gelöscht hast?
|
|
|
|
|
|
|
|
|
|
|
|
Weil das mit TRIM/discard afaik nix zu tun hat. Dabei geht es nur darum, der Platte zu sagen, was frei ist; es wäre merkwürdig von der Platte/SSD diese Sektoren dann nochmal explizit zu überschreiben.
|
|
[Dieser Beitrag wurde 1 mal editiert; zum letzten Mal von csde_rats am 15.05.2014 17:25]
|
|
|
|
|
|
|
|
|
| | Zitat von theromi
Okay, der Kernel merkt sich getrimmte Blöcke bis zum Reboot und lässt fstrim da nicht noch mal drüber fahren. Nach einem Reboot trimmt er wieder einmalig über den ganzen freien Speicher.
| |
Danke! Dann passt das ja (beinahe) wieder auf meine urspruengliche Annahme.
|
|
[Dieser Beitrag wurde 2 mal editiert; zum letzten Mal von hoschi am 15.05.2014 17:35]
|
|
|
|
|
|
|
|
|
| | Zitat von csde_rats
Weil das mit TRIM/discard afaik nix zu tun hat. Dabei geht es nur darum, der Platte zu sagen, was frei ist; es wäre merkwürdig von der Platte/SSD diese Sektoren dann nochmal explizit zu überschreiben.
| |
Was die Platte aber nicht daran hindert, dir mit einer Obiwan-Handbewegung zu sagen, dass hier nicht (mehr) die Daten sind, nach denen du gesucht hast.
|
|
|
|
|
|
|
|
|
|
|
Warum sollte sie? Das würde nur den Blocklesealgorithmus komplexer machen als er schon ist ; statt eine Hashmap (für ausgewechselte Sektoren) abzusuchen müssten zwei Hashmaps (eine weitere für geTRIMte Sektoren in die noch nicht wieder geschrieben wurde) abgesucht werden.
Ich mein, klar, das kann die Platte natürlich machen, aber als Überprüfungsmethode halte ich das für ungeeignet, weil man nicht weiß, ob oder welche Platten das so handhaben.
|
|
[Dieser Beitrag wurde 1 mal editiert; zum letzten Mal von csde_rats am 15.05.2014 18:20]
|
|
|
|
|
|
|
|
|
Gibt Platten, die Nullen anzeigen, gibt Platten, die da alles stehen lassen und gibt Platten, die da Zufallskram hinschreiben.
|
|
|
|
|
|
|
|
|
|
|
|
Kannst du glaub mit hdparm nachgucken.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Dann hau ich halt wieder nen Ubuntu drauf. Hmpf. 
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Hab ich, klappte nicht. Keine Ahnung, warum der nicht hoch kommt...
|
|
|
|
|
|
|
|
|
|
|
Enable doch einfach dhcpcd (ohne @). Ich habe arch ohne Probleme bei Hetzner installieren können und mich an deinen zweiten Link gehalten.
|
|
|
|
|
|
|
|
|
|
|
| | Zitat von Oli
Enable doch einfach dhcpcd (ohne @). Ich habe arch ohne Probleme bei Hetzner installieren können und mich an deinen zweiten Link gehalten.
| |
Hab ich gemacht, er bootet noch immer nicht. >.<
Dann liegt es aber vermutlich am Bootloader oder am Raid oder so.
|
|
|
|
|
|
|
|
|
|
|
|
Warum hat außer mir eigentlich niemand Probleme mit der Arch Installation? Könnte ich wenigstens mal die Fehlermeldung sehen...
|
|
|
|
|
|
|
|
|
|
|
|
HAH! Er bootet! WARUM AUCH IMMER!
|
|
|
|
|
|
|
|
|
|
|
|
Fürs nächste Mal: Boote den Server über den Robot mit VNC. Dann bekommst du den echten Bootloader zu sehen und siehst auch, wo/warum er klemmt.
|
|
|
|
|
|
|
|
|
|
|
Gibts 'ne einfache, effiziente Möglichkeit in einem Verzeichnisbaum alle Verzeichnisse und Dateien zu finden die nicht einem bestimmten Muster (dem des Wurzelverzeichnisses) entsprechen? Die Ausgabe von getfacl -R ist nicht wirklich geil zu parsen...
Aus irgendeinem Grund haben plötzlich einige Unterverzeichnisse andere Berechtigungen als die default ACL vorgibt obwohl darauf außer mir keiner Zugriff hat (haben sollte). Da ich nicht rausfinde warum wüsste ich zumindest gerne erstmal wo.
/e: und warum dauern 100.000 echo '' > blah$i zwei Sekunden und die gleiche Anzahl touch blah$i über sechs Minuten?
|
|
[Dieser Beitrag wurde 3 mal editiert; zum letzten Mal von TheRealHawk am 16.05.2014 16:10]
|
|
|
|
|
|
|
|
|
|
Hm, Zeilen mit # von getfacl rausschmeißen, danach diff gegen als gut bekannte ACL? Prüfen ob diff leer ist, wenn nicht Pfad ausgeben.
|
|
[Dieser Beitrag wurde 1 mal editiert; zum letzten Mal von csde_rats am 16.05.2014 15:07]
|
|
|
|
|
|
|
|
|
Ich hätt' jetzt irgendwie erwartet, dass cppcheck und Konsorten zu diesem Stück C etwas mehr als <nil> zu sagen hätten ... 
|
|
|
|
|
|
|
|
|
|
|
| | Zitat von ShinyDoofy
Fürs nächste Mal: Boote den Server über den Robot mit VNC. Dann bekommst du den echten Bootloader zu sehen und siehst auch, wo/warum er klemmt.
| |
Das...geht? Oh.
|
|
|
|
|
|
|
|
|
|
|
|
Ich weiß nicht, ob das vom Paket abhängt, aber ich hab hier sogar ein Java-KVM Applet bei Hetzner.
|
|
|
|
|
|
|
|
|
|
|
|
Mal eine vielleicht/wahrscheinlich blöde Frage: Ich hab einen Server und während ich für 3 IPv4-Adressen kämpfen musste, hab ich ein IPv6 /64 bekommen. Was mach ich jetzt mit 18,446,744,073,709,552,000 Adressen? Kann ich jetzt einfach lustig Dienste auf IPs verteilen? Soweit ich weiß, kann ich mir da doch auch einfach einzelne IPs rausholen und nutzen, oder?
|
|
|
|
|
|
|
|
|
|
|
|
Weltherrschaft, ja und ja.
|
|
|
|
|
|
|
|
|
|
|
|
Es gibt aber wirklich genug IPv6 Adresse. Wirklich.
|
|
|
|
|
|
|
|
|
|
|
Das hat man vor xx Jahren auch bei IPv4 gedacht.
|
|
|
|
|
|
|
|
|
|
|
| |
| Code: |
--13929-- VALGRIND INTERNAL ERROR: Valgrind received a signal 11 (SIGSEGV) - exiting
--13929-- si_code=1; Faulting address: 0x5F276098; sp: 0x802b99d70
valgrind: the 'impossible' happened:
Killed by fatal signal
==13929== at 0x3805B12A: ??? (in /usr/lib/valgrind/memcheck-amd64-linux)
==13929== by 0x3805CF4F: ??? (in /usr/lib/valgrind/memcheck-amd64-linux)
==13929== by 0x380211D5: ??? (in /usr/lib/valgrind/memcheck-amd64-linux)
==13929== by 0x380213CB: ??? (in /usr/lib/valgrind/memcheck-amd64-linux)
==13929== by 0x38021542: ??? (in /usr/lib/valgrind/memcheck-amd64-linux)
==13929== by 0x3809C78D: ??? (in /usr/lib/valgrind/memcheck-amd64-linux)
==13929== by 0x380AB16C: ??? (in /usr/lib/valgrind/memcheck-amd64-linux)
|
|
Ausgelöst durch einen (1) falschen MM-Call (realloc).
So schlimm hab ich Valgrind noch nie fertig gemacht, dabei hab ich schon öfter dumme Sachen, sogar mit Syscalls, gemacht... :O
|
|
[Dieser Beitrag wurde 1 mal editiert; zum letzten Mal von csde_rats am 16.05.2014 22:14]
|
|
|
|
|
|
|
|
|
| | Zitat von Krypt0n
Das hat man vor xx Jahren auch bei IPv4 gedacht.
| |
Da hat ja der Kühlschrank noch kein Internet gebraucht. Wahrlich ich sage euch, goldene Zeiten brechen an.
|
|
|
|
|
|
|
|
|
|
|
Bald hat jedes Atom in jedem Universum eine eigene IP-Adresse.
|
|
|
|
|
|
|
|
|
|
|
| | Zitat von csde_rats
So schlimm hab ich Valgrind noch nie fertig gemacht, dabei hab ich schon öfter dumme Sachen, sogar mit Syscalls, gemacht... :O
| |
Primär soll es dir ja sagen, wenn was nicht iO ist. Wie es das tut, ist ja wohl ihm selbst überlassen. Unzufriedenes Volk!
|
|
|
|
|
|
|
|
|
|
|
| | Zitat von TheRealHawk
Bald hat jedes Atom in jedem Universum eine eigene IP-Adresse.
| |
Dafür müssten wir einen ca. ~300 Bit großen Addressraum nehmen
teK: war mehr so kindische "ich habs kaputt gemacht" freude
Der Kram ist jetzt btw. open source geworden
|
|
[Dieser Beitrag wurde 1 mal editiert; zum letzten Mal von csde_rats am 16.05.2014 23:27]
|
|
|
|
|
|
| Thema: 100 gute Gründe für Linux ( v0.30 gute Gründe für systemd ) |
