ottima notiziaroftl grazieroftlQuote:
Originariamente inviato da zzzg
[Rom] Android Revolution HD 2.0.0 (Android 2.2.1 basato su ROM 1.72.405.3)
Visualizzazione stampabile
-
24-02-11, 17:37memnoch
-
24-02-11, 17:40molkoRagà ma le addon in che consistono?Quote:
Originariamente inviato da memnoch
-
24-02-11, 17:44zzzgSono le Fly_In_Animations e PowerControlBar,in pratica le animazioni tra schermate e la barra superiore con le iconeQuote:
Originariamente inviato da molko
-
24-02-11, 17:51molko
Ah ok grazie :)
Ma c'è anche incluso advanced power menu? -
24-02-11, 17:53zzzgSiQuote:
Originariamente inviato da molko
............ -
24-02-11, 18:23rescecco
...installata anche io. Fortuna che c'è titanium backup!!! :)
Avrei voluto aspettare alcuni feedback, ma non ho resistito. Al momento sembra...identica alle ultime! :) -
24-02-11, 18:23adonis
Sto uppando la 2.0.15 Clean, con l'aggiunta di bootloader è una notifica carina per sms
-
24-02-11, 18:24Frustu
Vale la pena di fare il full wipe prima di mettere la 0.15 sopra la 0.14 installata appena ieri pomeriggio? Sinceramente mi sono stufato dei wipe :)
Sent from my Desire HD using Tapatalk -
24-02-11, 18:26adonisAspetta vedo se trovo una cosaQuote:
Originariamente inviato da Frustu
-
24-02-11, 18:36memnochmi sa che stanno upgradando i temiroftl forse è meglio aspettare??roftlQuote:
Originariamente inviato da adonis
-
24-02-11, 18:40zzzgIl mio funziona,ovvio che se cìè un upgrade metto quelloQuote:
Originariamente inviato da memnoch
-
24-02-11, 18:44FrustuOk grazie per il link ora scarico e provoQuote:
Originariamente inviato da adonis
Sent from my Desire HD using Tapatalk -
24-02-11, 18:45adonisAvevo trovato un upgrade:full:wipw_1.3 però non so se funziona se vuoi lo postoQuote:
Originariamente inviato da Frustu
-
24-02-11, 18:50FrustuBeh se non sei sicuro preferisco non rischiare e ripristinare con titanium grazie lo stesso.Quote:
Originariamente inviato da adonis
Sapete se hanno reso l advanced power menù compatibile con la nuova cwm o per installarlo devo cambiare per forza recovery ?
Sent from my Desire HD using Tapatalk -
24-02-11, 18:55linux33it
con la .15 il FS di userdata è tornato Ext3
-
24-02-11, 18:59memnoch....per la felicità di @ThayroftlQuote:
Originariamente inviato da linux33it
-
24-02-11, 19:01zzzgSicuro? a me mount da ancora ext 4Quote:
Originariamente inviato da linux33it
-
24-02-11, 19:02linux33itcosa intendi per mount?Quote:
Originariamente inviato da zzzg
-
24-02-11, 19:05zzzgadb shellQuote:
Originariamente inviato da linux33it
mount -
24-02-11, 19:10adonis
Per chi vuole ho finito la 2.0.15 Clean
DOWNLOAD_Rom_Revolution_2.0.15_Clean -
24-02-11, 19:11linux33itinfatti,questo no?Quote:
Originariamente inviato da zzzg
"/dev/block/mmcblk0p26 /data ext3"
tu invece avresti ext4?
hai fatto full wipe? -
24-02-11, 19:12memnochgzzz che versione hai del market? la 2.3.2 o la 2.3.3 ?? voglio capire una cosa...Quote:
Originariamente inviato da zzzg
-
24-02-11, 19:27memnoch
flashato il tema e gmail non mi parte:o mi dice termina applicazione appena la seleziono!!!
Risolto:-) da applicazioni cancellate i dati di gmail e risincronizzate..poi è tutto ok:-) -
24-02-11, 19:29linux33itreinstalla dal marketQuote:
Originariamente inviato da memnoch
-
24-02-11, 19:38adonis
Come vi sembra questa nuova rom
-
24-02-11, 19:38lamb69
Ma è aumentata anche la frequenza? Mi va a 1138 senza setcpu o frills installato
-
24-02-11, 19:42memnoché veroooooroftl ASI mi da 1113.6 Mhz!!! che storia:) vediamo se i consumi sono seriroftlQuote:
Originariamente inviato da lamb69
@Adonis: mi pare perfetta!! é veloce come la 13 e stabile come la 12!! Si nota la differenza!! -
24-02-11, 19:49adonis
Speriamo che da oggi ne fa uscire una almeno ogni settimana, e con aggiunte corpose, dalla 12 alla 15 mi sono sembrate nightly =) sembrava di avere una CM7
-
24-02-11, 19:55memnochguarda vada come vada io questa la tengo 1 mese!! pure se arriviamo alla 21 intantoroftl se mi soddisfa sui consumi sara la mia per un bel poroftl non ha senso cambiare una rom ogni due giorni...neanche se ne apprezzano le potenzialità!! cmq questa storia del boot loop ha dato parecchio filo da torcere a mike e credo che per essere sicuro di non rifare lo stesso errore abbia creato una rom davvero molto stabile oltrechè performanteroftlQuote:
Originariamente inviato da adonis
-
24-02-11, 19:57nexus76adonis, avendo messo la 2.0.13 moddizzata da te, devo dare un wipe per flashare questa? dimmi di no..Quote:
Originariamente inviato da adonis
-
24-02-11, 19:59adonisQuote:
Originariamente inviato da nexus76
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 -
24-02-11, 20:07memnochil wipe è sempre meglio!roftlQuote:
Originariamente inviato da nexus76
-
24-02-11, 20:12zzzgProprio quello mi da ext4,non ho fatto full wipe,sicuramente è quello ma visto che comunque va bene lascio tutto com'èQuote:
Originariamente inviato da linux33it
-
24-02-11, 20:15memnochBuono a sapersi;-) per me questa è la migliore di sempre!Quote:
Originariamente inviato da zzzg
Sent from my Desire HD using Tapatalk -
24-02-11, 20:18zzzgmarket 2.3.2Quote:
Originariamente inviato da memnoch
-
24-02-11, 20:35molkoQuote:
Originariamente inviato da lamb69
Ma è vero questo fatto dell'oc di default? :oQuote:
Originariamente inviato da memnoch
-
24-02-11, 20:37thaylinux confermi ext3? la .15 non l ho ancora provata e in down appena arrivo a casa lo faccioQuote:
Originariamente inviato da linux33it
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 -
24-02-11, 20:44zzzg
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
-
24-02-11, 20:46thayazz ma leggi noQuote:
Originariamente inviato da zzzg
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 -
24-02-11, 20:48zzzgBeh io ho pulling out the battery e non ho lose nessun dataQuote:
Originariamente inviato da thay
Edit: e poi perchè mai uno dovrebbe togliere la batteria senza motivo?
