Noch schneller als Voodoo, Lagfix Ableger mit NILFS2 Dateisystem

Ich habe den NILFS-Fix auf eine voodoofreie JM8 draufgemacht. Bisher absolut keine Auffälligkeiten. Auch im Akkuverlauf alles im grünen Bereich. Bin bisher sehr zufrieden.

Speicherplatz wird "weniger". Allerdings soll das laut XDA an der Art und Weise liegen, wie NILFS2 arbeitet und nur eine falsche Anzeige provozieren, ohne dass der nutzbare Speicher reduziert wird.

Das wird wohl der Garbage Collector sein.
Ich verstehe das so, dass NilFS2 wie eine art Systemwiederherstellungspunkte macht (ähnl. Windows) und dies brauch eben auch ein wenig Speicherplatz.

Zu XX? Zeiten setzt dann Automatisch der Garbage Collector ein und spielt Müllabfuhr. Daher auch die kurzzeitig heftige CPU Belastung (Betonung auf kurz).

Was ich noch merke, ist, dass man wie den Riesen erst mal Wecken muss. Bei mir fühlt es sich am Anfang an wie eine JM8 ohne jeglichen Fix und plötzlich kommt der Turbo.

Wobei aber eben NilFS genau das Dateisystem sein soll, das am schnellsten (neben ext2) mit kleinen Dateien umgehen kann, d.h. die Vorzüge von ext2 und ext4 vereint.

Noch was zum Speicherplatz.
Das Nilfs2 Dateisystem macht wie erwähnt diese Snapshots von sich selbst.
Daher kann man auch zusehen wie bei Nutzung Minütlich der verfügbare Speicher runter geht.

Da liegt der Hase begraben ... es macht diese Shots, und setzt den Speicher zu, ist er soweit voll, kommt der Carbage Collector (die Müllabfuhr).

Für den Speicherplatz ist das nur insofern Schlimm, dass es einen Unsicher machen könnte.
Man will 900MB haben, sieht aber nur noch z.B. 600 MB, obwohl nach der "Müllabfuhr" wieder und überhaupt die 900MB bereit stehen.

Allerdings ist das auch ein Grund entweder wieder zum blanko voodoo zu wechseln, oder auf ein schnelles Update des Entwicklers zu hoffen.
Schliesslich ist es ähnlich wie der erste ryanza Lagfix ohne vorherige Betaphase.

Zitat von XDA:

but I got the same problem as many of us with the free space. I think due to the fact that it takes snapshots of itself every minute/second my free space drowns down. I can even click every 30 seconds on Settings / SD Card and see that again 10MB are gone.

... Stimmt!

Hab es mal Beobachtet in den letzten 45 min. mein Speicher ging von 736 MB innerhalb von der Zeit auf unter 600 und dann kam die Müllabfuhr (siehe Foto)

Sending from galaxy s i9000 using Tapatalk and my finger.

Ist es denn nicht so, dass es dabei (noch) keine vernünftige Möglichkeit gibt, die (versehentlich) gelöschten Dateien unter Android wiederherzustellen und diese Snapshotmacherei mit Platzverschwendung und Akkuverbrauch völlig sinnlos ist?

Stellt es sich nicht selbst her?
Nun die Zeiten des Checkpoints(Snapshots) kann man einfach Einstellen.
Also ich nicht, aber der Entwickler.
Denn wie gesagt, NilFS ist für das was man am SGS macht (und anderen Smartphones) das beste Dateisystem.
(einen Pferdefuss gibts überall)

Wer sich auskennt, im Sytem/etc gibts die nilfs_cleanerd.conf. , evtl. kann man da selbst rumwerkeln.

Quelle blah-blah.ch

* The behaviour of NILFS2 is set by the setup in the file /etc/nilfs_cleanerd.conf.



* The garbage-collector did not work for me out-of-the-box when using NILFS2 as root fs. I had to implement a small script that runs "killall nilfs_cleanerd" and "nilfs_cleanerd /dev/sda3" when the OS boots (in the last runlevel).



* NILFS2 doesn't have a filesystem-check utility (fsck) because (from what I understood) if the FS is corrupted it will just enable the youngest checkpoint which is marked as not corrupted. To avoid the message during boot about the fsck-utility not being found just change in /etc/fstab the settings not to perform a filesystem check - in my case:
/dev/sda3 / nilfs2 noatime,rw 0 0

Zitat von spline

Wer sich auskennt, im Sytem/etc gibts die nilfs_cleanerd.conf. , evtl. kann man da selbst rumwerkeln.

Die scheint einiges an Potenzial zu haben; bpw. kann man einstellen, wie häufig der Cleaner läuft, wie alt ein Snapshot sein muss, damit er gelöscht wird, usw.
Ist mir aber zu heikel, ich warte mal ob der Entwickler da noch etwas tunet

Also der Inhalt der Cleanerconfig ist folgender:

Code:

# nilfs_cleanerd.conf - configuration file of NILFS cleaner daemon.
#
# This file contains GC parameters that are loaded when cleaner gets
# started.  You can force them to be reloaded by sending a HUP signal
# to the cleaner process.
#
# Each parameter is declared with a keyword-value pair or a directive
# with no argument.  Lines beginning with "#" are ignored.  For
# details, see the man page of nilfs_cleanerd.conf(5).

# Protection period in second.
protection_period    1800

# Minimum number of clean segments
#   0 = continuous cleaning
# > 0 = pause cleaning until less segments are available
min_clean_segments    40%

# Maximum number of clean segments
max_clean_segments    60%

# The argument of min_clean_segments and max_clean_segments can be
# followed by a percent sign (%) or one of the following
# multiplicative suffixes: K 1024, MB 1000*1000, M 1024*1024, GB
# 1000*1000*1000, G 1024*1024*1024, and so on for T, P, E.
#
# If the argument is followed by "%", it represents a disk capacity
# ratio.

# Clean segment check interval in seconds
clean_check_interval    10

# Segment selection policy.
# In NILFS version 2.0.0, only the timestamp policy is supported.
selection_policy    timestamp    # timestamp in ascend order

# The maximum number of segments to be cleaned at a time.
nsegments_per_clean    2

# The maximum number of segments to be cleaned at a time
# if clean segments < min_clean_segments
mc_nsegments_per_clean    4

# Cleaning interval in seconds.
cleaning_interval    5

# Cleaning interval in seconds
# if clean segments < min_clean_segments
mc_cleaning_interval    1

# Retry interval in seconds.
retry_interval        60

# Use mmap when reading segments if supported.
use_mmap

# Log priority.
# Supported priorities are emerg, alert, crit, err, warning, notice, info, and
# debug.
log_priority        info

Stimmt also, im Halbstundentakt löscht er maximal 60% der Points.
Mein Speicher wedelt zwischen ca. 1100- und 600 MB, was über den Daumen 60% entspricht.

Ich habe mich hier und da erkundigt und es scheint mit dieser Konfiguration wie folgt zu funktionieren:

protection_period 1800

Snapshots werden mindestens eine halbe Stunde lang gehalten

min_clean_segments 40%

Man fängt mit dem Aufräumen an erst wenn weniger als 40% der Partitionkapazität frei bleibt

max_clean_segments 60%

Man hört auf zu löschen wenn mehr als 60% frei ist.

clean_check_interval 10

Alle 10 Sekunden wird geprüft, ob man schon aufräumen muss

nsegments_per_clean 2
cleaning_interval 5

maximal 2 Segmente in 5 Sekunden werden aufgeräumt, um das System nicht unnötig zu belasten.
Segmentgröße beträft meines Wissens 8MB.

retry_interval 60

Man wartet mit dem Aufräumen 60 Sekunden, falls das System gerade was zu tun hat.

Das Klingt ja ganz in Ordnung.

Jetzt müsste man dem Nils nur noch sagen, "Du 2 Snapshot's reichen".
Oder von mir aus gar keiner.
Ryanza bastelt auch grad an einem neuen Fix, wo alles auf ext2 Läuft.
Haut man da den Akku mitten im Betrieb raus ist auch "Bandsalat".
Also von mir aus braucht das Nilfs gar keine Snapshots.
Mal sehen was der Entwickler sagt ...

Der Beweis folgt auf dem Fusse:

alle halbe Stunde bekommt meine CPU was zu Beissen(unten) und der Akku (oben) verhält sich wie der Dowjones am Freitag.

Ich schmeiss mir mal den Stock Kernel drauf und geh mal wieder zu voodoo.
Die nächsten Wochen bleiben spannend :

- Finale Froyo (hoffentlich keine JPH)
- Full ext2 Speedfix von Ryanza
- vom voodoo evtl. auch was neues
- und ganz heiss, weil das optimalste Dateisystem, dieser NilFS2 Fix

Stay Tuned

Das kann ich bei mir auch ohne Grafik so bestätigen: knapp halbe Stunde lang kaum Akkuverbrauch, dann innerhalb von wenigen Minuten ca. 4 Prozent wech.... und so weiter.
Schade.

@spline

Wie heißt die App auf dem Screenshot?

Klingt mittlerweile nicht mehr so toll bzgl. des Energieverbrauchs. Mir ist leider auch nicht ganz klar, wann die Snapshots mir helfen. Würde der Kernel automatisch die Daten wiederherstellen, wenn irgendwas inkonsistent ist?

Ich nutze ja wie weiter oben geschrieben noch den Fix ext2 als extra Partition. Da trage ich das größte Risiko. Trotzdem ist bisher alles gutgegangen *auf Holz klopf*
Ist es trotzdem blauäugig von mir?

Naja kommt sicher noch, ich denke diese Sicherheit von NilFS auszuschalten ist ein kleiner Trick.
Jedoch scheiden sich dann wieder die Geister ob nun Journaling besser ist oder nicht.
Für meinen Teil brauch ich es nicht, ich hab immer ein frisches Backup.
Mein PC mit Raidverbund ist auch gefährdet, ich habs zwar schnell, aber wehe dem eine platte geht kaputt (ist ähnl. dem ext2 )


Und jetzt beim deinstallieren hab ich mir doch glatt noch das SGS zerschossen.
Nix geht mehr.
Guter Grund um auch mal JPH Luft zu schnuppern um dann wieder zu JM8 mit Voodoo zu gehen, die bisher beste Kombination. (für mich)

Zitat von DaiSifu

@spline

Wie heißt die App auf dem Screenshot?

Klingt mittlerweile nicht mehr so toll bzgl. des Energieverbrauchs. Mir ist leider auch nicht ganz klar, wann die Snapshots mir helfen. Würde der Kernel automatisch die Daten wiederherstellen, wenn irgendwas inkonsistent ist?

Ich nutze ja wie weiter oben geschrieben noch den Fix ext2 als extra Partition. Da trage ich das größte Risiko. Trotzdem ist bisher alles gutgegangen *auf Holz klopf*
Ist es trotzdem blauäugig von mir?

Eben ext2 hab ich grad beschrieben.
Man sollte sich bewusst sein, was man damit macht.
Andere User, wie Gabi aus dem Sparmarkt käme dann sicher ins Heulen, wenn ihre bunten pupu Apps weg sind

Das App heisst Systempanel und kann u.a. Monitoring

Hab auch wieder voodoo drauf. Akkuverbrauch war schon höher außerdem war mein telefonspeicher fast weg. Hab jetzt einfach den lagfix ausgeschaltet und den voodoo kernel per update.zip drüber geflasht. Jetzt ist es wieder ext4...
Lief alles total reibungslos ab ohne neuflashen oder so.

Sent from my GT-I9000 using Tapatalk

Zitat von vygi

Das kann ich bei mir auch ohne Grafik so bestätigen: knapp halbe Stunde lang kaum Akkuverbrauch, dann innerhalb von wenigen Minuten ca. 4 Prozent wech.... und so weiter.
Schade.

Eigenartig, bei mir stellt sich das ganze nicht so dramatisch dar... Anfangs hatte ich das Gefühl, das Ding zieht am Akku wie Sau, aber inzwischen geht's eigentlich.
Ich hatte heute morgen nach der ganzen update.zipperei noch 24% Akku, und aktuell habe ich immer noch 8%, das entspricht bei mir etwa dem normalen Verbrauch über einen Tag.

aber an meiner Grafik siehst Du nur ein Zeitfenster von 2h und wie der Akku leidet.
Das Handy hat sonst nichts weiter laufen wie sonst. Kein Wlan nix ...

Zitat von spline

aber an meiner Grafik siehst Du nur ein Zeitfenster von 2h und wie der Akku leidet.
Das Handy hat sonst nichts weiter laufen wie sonst. Kein Wlan nix ...

Ich glaub's Dir schon
Evtl. lässt sich über die config-Datei noch was rausholen; wenn ich mir die manpage dazu anschaue, scheint mir aber, man müsste fast eine eigene Partition für die Snapshots haben. Ansonsten sind die Prozent-Angaben für den freien Speicher u.U. sehr gefährlich; wenn man nämlich sowieso schon weniger als 40% Speicher frei hat(te), wird der cleanerd mach meinem Verständnis ja gar nie mehr aufhören versuchen aufzuräumen.
Werde mal ein bisschen was schrauben...

Sagt mal leute der Reeboot dauert ungefähr wie lange.
Habe Voddoo drauf gehabt in den Ordner Voodoo disable lagfix reingeschrieben telefon aus und Neugestartet.
Hochfahren lassen die Datei umbenannt in update auf die SD Kopiert.
Dann auf Update zip wie immer dann kommt unten irgendwas mit Reeboot und das geht dann weg dann kommt Galaxy S usw und da steht es nun.