[Rom] Android Revolution HD 2.0.0 (Android 2.2.1 basato su ROM 1.72.405.3)

[adonis]

adonis, avendo messo la 2.0.13 moddizzata da te, devo dare un wipe per flashare questa? dimmi di no..

Io consiglio sempre un full wipe ma non è obligatorio, al massimo se noti instalità, lag, batteria che dura poco sai quale è la causa ^_^ provare non nuoce anche se penso che andrà tutto lisco come l'olio

[memnoch]

adonis, avendo messo la 2.0.13 moddizzata da te, devo dare un wipe per flashare questa? dimmi di no..

il wipe è sempre meglio!

[zzzg]

infatti,questo no?
"/dev/block/mmcblk0p26 /data ext3"
tu invece avresti ext4?
hai fatto full wipe?

Proprio quello mi da ext4,non ho fatto full wipe,sicuramente è quello ma visto che comunque va bene lascio tutto com'è

[memnoch]

Proprio quello mi da ext4,non ho fatto full wipe,sicuramente è quello ma visto che comunque va bene lascio tutto com'è

Buono a sapersi;-) per me questa è la migliore di sempre!

Sent from my Desire HD using Tapatalk

[zzzg]

gzzz che versione hai del market? la 2.3.2 o la 2.3.3 ?? voglio capire una cosa...

market 2.3.2

[molko]

Ma è aumentata anche la frequenza? Mi va a 1138 senza setcpu o frills installato

é verooooo ASI mi da 1113.6 Mhz!!! che storia vediamo se i consumi sono seri
@Adonis: mi pare perfetta!! é veloce come la 13 e stabile come la 12!! Si nota la differenza!!

Ma è vero questo fatto dell'oc di default? :o

[thay]

con la .15 il FS di userdata è tornato Ext3

linux confermi ext3? la .15 non l ho ancora provata e in down appena arrivo a casa lo faccio
Ripeto e con questo chiudo l argomento,sono il primo a cui fa piacere avere novita riguardo la rom ma devono essere anche validamente supportate.Non si puo rilasciare una rom al giorno senza senso.ripeto il dev e in gamba ma forse pecca un po di presunzione visto che nell ambito del dhd dev con nomi conosciuti a parte lee non ce ne sono.
Per quelli che volevano info dettagliate su cosa probabilmente( se l autore si fosse degnato di rispondere alle domande forse lo sapremmo) nelle versioni precedenti era utilizzato ecco qui


FSYNC
When writing data to disk, your system and apps will make a call to the driver to ‘write some data to file X’. This data will then be placed into kernel filesystem buffers and streamed off as commands to the MoviNAND. The MoviNAND will then slowly accept these commands, and place them into its own buffer, and the disk controller itself will then go about it’s business writing this data to disk, using lookup tables to determine where to write the data to ensure maximum NAND lifetime, etc. It does a lot of work.

The system or apps also have an extra tool, called FSYNC. When this is used, the kernel and filesystem will clear the buffer for the affected file, and ensure it is written to disk. The current thread will block, and wait for the fsync call to return to signal that the data is fully written to disk. The kernel itself will wait for an event from the MoviNAND to signal that the data has been completely written.

In a ‘dumb’ disk, this fsync is fairly quick – the kernel buffer will be written directly to where the kernel has directed, and the round trip time (RTT) will be as long as it takes for data to be written.

In a ‘very smart’ desktop SSD, the fsync can return instantly – the disk controller will take the data and place it in it’s battery-backup protected, and then go about it’s wear leveling and writing in the background without bothering the system.

In the ‘smart’ MoviNAND, the fsync will take a very very long time to return – sometimes fsync on MoviNAND will take several seconds(confirm?) to return. This is because the MoviNAND may have a long line of housekeeping tasks waiting for it when a fsync is called, and it will complete all of it’s tasks before returning.

RFS

RFS, a file system, has a fairly badly written driver, that will call an fsync on file close.

Basically, RFS runs in ‘ultra secure’ mode by default. This security may not be really needed – I personally don’t want it if it means enormous slow downs. It also doesn’t help data security if the system/app is holding a file open, only if it closes the file. The MoviNAND is also fairly smart, and appears to write it’s cache to disk before turning off, and also appears to have capacitors to keep it alive for a little bit of time in the event of a power cut.

SQLite

Most Android apps use SQLite – a fairly simple database that is easy to embed. Sqlite has ‘transactions’ – not real transactions, but a transaction in sqlite is where the database is locked for the duration of a database write, and multiple databases writes can be included in one transaction. At the end of a transaction, sqlite will call FSYNC on the database file, causing a possibly long wait while the MoviNAND does it’s thing. Certain applications will not bunch up writes into a single transaction, and will do all of their writes in new transactions. This means that fsync will be called again and again. This isn’t really a problem on most devices, as fsync is a very fast operation. This is a problem on the SGS, because MoviNAND fsync is very slow.

The various fixes and why they work

Native EXT4 to replace RFS (Voodoo by supercurio)

By replacing RFS with the file system EXT4, the ‘sync on fileclose’ problem is removed. The EXT series of filesystems is also more efficient at allocating information into blocks than RFS/FAT32 is. This means less real writes to MoviNAND, which means that the MoviNAND buffer should be smaller, and when a sync is called, fewer commands have to be run. When a sync is called on EXT4, it will still be very slow, as the MoviNAND’s sync is still slow.
Basically, EXT4 improves filesystem grouping which leads to less commands, and does not have the broken ‘sync on file close’ that RFS does. It will not heavily improve sqlite database access in certain apps, as the full fsync on transaction end will still have to go through MoviNAND, and will be slow.

When pulling out the battery, there is a chance to lose data that has been written to a file but has not yet been told to sync to disk. This means that EXT4 is less secure than RFS. However, I believe the performance to be worth the risk.

Loopback EXT2 on top of RFS (OCLF by ryanza)

By creating a loopback file system of EXT2, the ‘sync on fileclose’ problem is removed as well. Since the Loopback File is never closed until the EXT2 is unmounted, RFS will not call fsync when a file in the EXT2 loopback is closed. Since a single large file is created on RFS instead of multiple small files, RFS is unable to mis-allocate the file, or fragment it. The actual allocation of filesystem blocks is handled by EXT2. As a note, care should be taken in making the large file on RFS – it MUST align correctly with the MoviNAND boundries, or operations will be slowed down due to double-disk accesses for files, etc. It is unknown whether OCLF is aligning this correctly

Loopback also has the benefit of speeding up Sqlite databases , at the expense of a transaction being lost in power outage, as it could still be in ram. As always, this is a performance tradeoff between data security when the battery is pulled out, and performance. When pulling a battery out while using the loopback filesystem, there is a chance to lose the last few seconds of database writes. In practice, this isn’t a huge deal for a mobile phone – most lost data will be resynced when the phone reboots. In my opinion, the performance is worth it because of the very slow speed of a sync on MoviNAND.

Loopback EXT2 on top of EXT4

All of the above for normal loopback EXT2 applies. In addition, when the loopback flushes data, it will be flushed to EXT4 instead of RFS. This will probably be better than flushing to RFS, as the RFS driver is not as well written as the EXT4 driver. The difference should not be very large, though.

A no-RFS solution (ULK by sztupy)
Although the above lagfix solutions mentioned do help reduce the problem of lag, there can be improvements made.

Voodoo only replace the /data’s rfs file system with ext4 while OCLF creates an ext2 loop on /data’s rfs file system. This leaves the /dbdata, /cache, /system, and /efs directories intact with the rfs file system. By replacing these directories with ext4/ext2 file systems, read and write speeds could be further improved. Only the /efs directory cannot be changed because doing so would result in potential data loss, which is even more dangerous as the /efs folder contains product codes related to samsung

[zzzg]

Tu sicuramente capsci qualcosa,per me è aramaico,magari se ci dici quali sono i motivi della tua perplessità in modo che possano capire tutti poi si potrà discutere con cognizione di causa

[thay]

Tu sicuramente capsci qualcosa,per me è aramaico,magari se ci dici quali sono i motivi della tua perplessità in modo che possano capire tutti poi si potrà discutere con cognizione di causa

azz ma leggi no
la possibile corruzione dati
When pulling out the battery, there is a chance to lose data that has been written to a file but has not yet been told to sync to disk. This means that EXT4 is less secure than RFS. However, I believe the performance to be worth the risk.
di sicuro il modo di aggirare la cosa ce ma nella rom non penso,magari ginger ci portera la novita

[zzzg]

azz ma leggi no
la possibile corruzione dati
When pulling out the battery, there is a chance to lose data that has been written to a file but has not yet been told to sync to disk. This means that EXT4 is less secure than RFS. However, I believe the performance to be worth the risk.
di sicuro il modo di aggirare la cosa ce ma nella rom non penso

Beh io ho pulling out the battery e non ho lose nessun data

Edit: e poi perchè mai uno dovrebbe togliere la batteria senza motivo?