12 respostas a este tópico

[mundano]

NOTA: Algumas conclusões foram re-escritas após testes mais aprofundados. Se já tinham lido, podem ler novamente, especialmente a parte em que discuto a opção NO-RFS vs Voodoo.Tem havido muitas perguntas sobre que Lagfix em concreto usar.. A ROM ONE.PT como usa o "sztupy's Universal Lagfix" apresenta uma serie de opções que por serem tantas podem deixar qualquer um indeciso.Antes de mais, é opinião +/- geral, e é uma opinião especialmente defendida por pessoas como o Supercurio que foi quem fez o primeiro fix real para a lag, com o seu kernel Voodoo, que opções que usam loop's ext2 por cima de outro filesystem são perigosas e demasiado propensas a problemas. Qualquer corte na bateria, ou desligar brusco no sistema pode implicar corrupção do sistema e obrigar a uma formatação total, pelo que eu pessoalmente, não uso nem recomendo nenhuma destas opções...As opções que usam loop's ext2 são:* OCLF: /data stays at rfs, but has an ext2 loop device on top of it* No-RFS Standard: /data is rfs+ext2, all other partitions are ext4* No-RFS Overkill: turns on all options: everything is ext4+ext2 and /data/data is bound to /dbdata* No-RFS Overkill JFS: turns on all options: everything is jfs+ext2 and /data/data is bound to /dbdataÉ claro que quem quiser a maxima performance pode sempre usar o No-RFS Overkill JFS, mas lembrem-se que quando as coisas correrem mal, a culpa é vossa..Posto isto há apenas duas grandes escolhas a fazer se transformamos apenas a partição /data, ou todas.. E qual o sistema de ficheiros. Em relação à primeira escolha temos:1º o metodo Voodoo\JFS, que é formatar apenas a partição /data ,2º o metodo No-RFS que implica formatar as partições /data /dbdata e /cache .. O método NO-RFS apareceu porque algumas pessoas acham que o RFS é lento por natureza. Mas isso não é verdade, o que é lento é a combinação de memoria flash do tipo moviNAND com o sistema de ficheiros RFS, já que a forma como os drivers RFS interagem com esta memoria fazem com que as escritas de ficheiros originem sempre uma sincronização do FS o que é um processo muito lento nas memorias moviNAND e isso faz com que o terminal fique parado à espera que a memoria acaba de escrever... Assim, o uso de outros filesystems mais compatíveis com moviNAND como o ext4 ou o JFS tem-se revelado extremamente eficaz a erradicar a lag do terminal.A memoria moviNAND é o SD de 8 GB (ou 16GB) que aloja a partição /data e o espaço de 6 GB acessível ao utilizador.As restantes partições, nomeadamente a partição /dbdata e /cache estão noutro tipo de memoria, a memoria oneNAND. Todos os testes existentes indicam que o RFS e as memorias oneNAND funcionam perfeitamente juntos. E as vantagens em usar outros sistemas de ficheiros em termos de velocidade são muito poucas.Assim, tendo em conta que os lagfixes são sempre elementos estranhos nas ROM's e que potencialmente podem causar problemas, não vejo grande utilidade no método NO-RFS, já que as vantagens em termos de velocidade não são praticamente nenhumas e estamos a aumentar exponencialmente a probabilidade de algo correr mal.Por fim a questão mais importante, ext4 ou JFS??Aqui há três pontos essenciais que importa discutir, a estabilidade, a performance e a bateria. 1º Em relação à estabilidade, tanto JFS como ext4 oferecem níveis de segurança idênticos. Ambos são relativamente seguros e não há relatos em especial de corrupção de dados com nenhum dos dois. No entanto existem alguns bugs na implementação do JFS, que até ver são apenas 3, mas que podem significar outro problemas mais graves por detrás da implementação que existe. Esses bugs são:* O modos USB-Debug fica sempre ligado quando se liga o telefone. (não é bem um bug, é uma feature propositada.)* A lingua e o Timezone resetam sempre para o default. Se definirem uma Timezone manualmente esta "reseta" para GMT+0 quando reiniciam o telefone. O que em Portugal não é problema porque é o nosso Timezone. Se usarem o setting automático, também não há problema. A lingua, no caso da ROM.ONE muda para PT.* Aparentemente, quando nas definições das aplicações tentamos limpar a cache ou os dados da aplicação, não acontece nada.. [Este bug só acontece se usarem o metodo NO-RFS JFS, se apenas usarem o lagfix na partição /data como é recomendado este bug não aparece).Todos eles são "minor bugs" que não estragam a experiencia com o telefone, nem de forma alguma se tornam obstrusivos.2º A performance... Fiz alguns testes e os resultados foram:JBench: EXT4- leitura 2,55MB/s- Escrita 1,37 MB/sJFS - Leitura 2,58 MB/s- Escrita 1,79 MS/sSDcardBenchmark:Ext4 - Leitura 95,33 - Escrita 37,26JFS - Leitura 95,33- Escrita 63,82Quadrant: EXT4 - 1505JFS - 1535 Aqui a vitoria é clara para o JFS, na leitura os valores são idênticos, mas na escrita o JFS é muito mais rápido. A juntar a isto segundo todos os relatos o JFS consume bastante menos CPU para realizar as mesmas operações o que deixa mais recursos livres para ainda ajudar mais a combater as lag's do terminal.3º Quanto à bateria, a conclusão também é facil. O JFS consome menos CPU e escreve as coisas na memoria em menos tempo, pelo que tem um consumo bastante menor de bateria. Pensa-se mesmo que aplicar o lagfix JFS ajuda a reduzir o consumo da bateria em relação a um terminal sem lagfix. Pelo contrario o ext4 é pesado para o CPU e em consequência para a bateria também. Nota-se um aumento de consumo em relação a um terminal sem lagfix quando se usam lagfixes baseados em ext4.Eu pessoalmente acho que medindo os prós e os contras, apesar dos pequenos bugs, o método JFS é a escolha certa para quem conseguir conviver com os 2 bugs que referi (3 caso optem pelo NO-RFS)... É um file system bastante leve para o CPU e que ajuda a poupar bateria, é muito rápido e seguro.. Caso algum desses bugs se torne incomodativo, o Voodoo (ext4) deverá ser a escolha..E vocês, qual usam? Qual acham que é a melhor escolha e porque?

[pedronveloso]

Vou comentar esta thread, mas de um ponto de vista mais teórico, o post do mundano já explica aquilo que quem veio cá para se decidir saber escolher, portanto essas pessoas não precisam de ler o que escrevi em baixo.De facto o JFS é mais rápido, e é fácil perceber porquê, uma vez que esse sistema de ficheiros organiza a informação no armazenamento interno (dizer disco não parece apropriado, uma vez que na verdade não existe um disco a sério) com uma hierarquia de árvores binárias de procura. Esse género de aproximação é má para armazenamento como os discos rígidos convencionais dos computadores, porque a agulha do disco perde muito tempo a mexer de um lado para o outro, e enquanto que em Ext4 ela ficaria mais tempo a ler informação de uma forma sequencial, deixando de necessitar de andar a "pular" de posição no disco. Ora como o armazenamento interno dos telemóveis é memória NAND, flash, etc, esses géneros de memória têm um tempo de acesso aleatória muito mais baixo, e faz sentido tirar proveito disso.Para mim este problema da JFS não é considerado "minor" :"Aparentemente, quando nas definições das aplicações tentamos limpar a cache ou os dados da aplicação, não acontece nada.. "Eu ainda aguardo que se começe a usar o sistema de ficheiros que a meu ver seria o ideal para este telemóvel, o BTRFS, tem uma aproximação por árvores binárias, e é bem mais recente que o JFS, e tem algumas características interessantes que permitirão manter maior integridade de sistema, por exemplo, a nível de suporte de "transactions" (para quem percebe de base de dados, é a mesma coisa que as transacções de SQL, mas a nível do filesystem), que poderiam ser usadas para as partições que contêm dados mais sensíveis.Um exemplo de uma plataforma que está a apostar neste sistema de ficheiros é o MeeGo.Em teoria existe ainda outra coisa que ainda não foi explorada. O facto de termos 2 cartões externos, poderia permitir algumas configurações de RAID, entre as quais uma mais voltada para performance. (aí rebentava com o quadrant )

[mundano]

Já agora, e só por curiosidade, a misteriosa ROM do GT-i9200 que apareceu usa um filesystem diferente de todos estes, usa o UBIFS, que é um sistema desenvolvido inicialmente pela Nokia e mais tarde integrado no Kernel Linux, é o sistema usado pelo N900. E segundo os relatos disponíveis pela net tem uma excelente performance com MTD's (moviNAND e oneNAND que são os dois tipos de flash usada pelo Galaxy S, são MTD's)..

[mundano]

Bem... Já devo ter formatado o telefone umas 10 vezes, e corrido o Quadrant umas 20 ou 30.. E acho que ao contrario do que disse antes, o método NO-RFS não traz qualquer tipo de vantagens... Estou até capaz de dizer que produz piores resultados no Quadrant.EDIT: se usar apenas a partição /data formatada com JFS e o resto em RFS o terceiro bug que relatei desaparece. A limpeza dos dados das aplicações produz efeito, acabei de experimentar com o Market e tive que aceitar novamente a licença. :cheer: Acho que definitivamente o método NO-RFS traz mais problemas do que vantagens.Vou editar o primeiro post. Mas já agora também gostava de receber mais feedback.

[mepp]

Que lagfix aconselhas então? O que têm aconselhado para a rom one não te parece apropriado?Eu tenho-o usado e estou satisfeito porque já não noto lag nenhum. Mas se houver outras alternativas mais seguras e com igual ou melhor performance, estou disponível para testar!Abraço e obrigado pelas explicações!

[on.one]

Que lagfix aconselhas então? O que têm aconselhado para a rom one não te parece apropriado?Eu tenho-o usado e estou satisfeito porque já não noto lag nenhum. Mas se houver outras alternativas mais seguras e com igual ou melhor performance estou disponível para testar!Abraço e obrigado pelas explicações!

Eu penso que o melhor compromisso é mesmo o que aconselhei, isto não desvalorizando de modo algum o feedback do Mundano e a experiência por ele feita. Contudo, a ultima decisão é sempre do utilizador face às suas necessidades e ao que cada um valoriza mais, pois há sempre compromissos. Eu sinto-me muito confortável com o compromisso do NO-RFS Advanced a=ext4.Um abraço.

[gonsa]

mais um lagfix.desta vez é o novo z4mod do RyanZa.http://forum.xda-developers.com/showthread.php?t=845337

[on.one]

mais um lagfix.desta vez é o novo z4mod do RyanZa.http://forum.xda-developers.com/showthread.php?t=845337

Bom dias Gonsa,Obrigado pela informação, mas esse tipo de lagfix é só para rom's com stock kernel e não funciona com outros tipos de kernel. A rom ONE não tem um stock kernel.Um abraço.

[mundano]

Com a nova versão do Kernel SpeedMod, o K9A, deixa de ser forçado o modo USB Debug, quando se usa o Lagfix JFS. Já só resta um bug..

[mundano]

Estou a testar o novo Kernel K10 com o LAG FIX All ext4, no Journalling.Para que fique bem assente, este lagfix tem uma probabilidade de haver corrupção de dados bem superior ao sistema RFS standard, a performance é ligeiramente superior ao Lag Fix que estava a usar nos últimos dias (JFS Data). Os resultados do quadrant no meu setup andam em torno dos 1685..

[on.one]

Estou a testar o novo Kernel K10 com o LAG FIX All ext4 no Journalling.Para que fique bem assente, este lagfix tem uma probabilidade de haver corrupção de dados bem superior ao sistema RFS standard, a performance é ligeiramente superior ao Lag Fix que estava a usar nos últimos dias (JFS Data). Os resultados do quadrant no meu setup andam em torno dos 1685..

O JFS mantêm-se na mesma?Estou mesmo tentado a experimentar o kernel do raspdeep em anticipatory com JFS.Um abraço.

[mundano]

Andei uma semana com JFS e até ver para mim é o melhor compromisso. A performance é ligeiramente inferior ao ext4 sem journaling, mas é superior ao ext4 com journaling. NOTA: O JFS usa journaling, pelo que é bem mais seguro do que o ext4 sem journaling.O consumo de bateria é inferior às soluções com ext4. O grande problema é mesmo o bug do timezone/língua.. Reseta sempre o timezone e a lingua para o default da ROM, no caso da ROM ONE reseta sempre para Português e GMT+0..

[on.one]

Andei uma semana com JFS e até ver para mim é o melhor compromisso. A performance é ligeiramente inferior ao ext4 sem journaling mas é superior ao ext4 com journaling. NOTA: O JFS usa journaling, pelo que é bem mais seguro do que o ext4 sem journaling.O consumo de bateria é inferior às soluções com ext4. O grande problema é mesmo o bug do timezone/língua.. Reseta sempre o timezone e a lingua para o default da ROM, no caso da ROM ONE reseta sempre para Português e GMT+0..

Pois esse é para mim o maior problema pois já estou habituado a usar o telefone em Inglês. O ganho na performance e na bateria ainda podia ser maior com o kernel do raspdeep com o scheduler em anticipatory para tirar partido do filesystem.Obrigado pela informação.Um abraço.