gildot

Topo
Sobre
FAQ
Tópicos
Autores
Preferências
Artigos
Sondagens
Propor artigo


8/3
gildicas
9/30
jobs
10/9
perguntas
10/25
press

 
Será para ext3 que devemos evoluir?
Contribuído por scorpio em 06-11-02 9:33
do departamento leituras
Linux Anonimo Cobarde escreve "Enquanto não se decidem vão lendo este artigo sobre ext3 com algumas quotes de outros sites para o ajudar a decidir sobre o 'journaling filesystem' a adoptar. "
[scorpio: link para o artigo corrigido (funcionou antes do primeiro submit).]

NASA quer acabar com dúvidas sobre ida à Lua | Comparação de software com "fast food"  >

 

gildot Login
Login:

Password:

Referências
  • Anonimo Cobarde
  • artigo
  • Mais acerca Linux
  • Também por scorpio
  • Esta discussão foi arquivada. Não se pode acrescentar nenhum comentário.
    Link? (Pontos:2)
    por jig em 06-11-02 10:07 GMT (#1)
    (Utilizador Info)
    O link está mal,eu estou com problemas nos browsers ou o site está mal concebido?
    Re:Link? (Pontos:2)
    por jig em 06-11-02 11:27 GMT (#5)
    (Utilizador Info)
    Não querendo ser muito cócózinho mas isto mostra qualquer coisa...
    http://validator.w3.org/check/?uri=http%3A//tuxslare.org/
    Para o documento em questão idem.
    To ext3 or not to .... (Pontos:1)
    por xakalito em 06-11-02 10:43 GMT (#4)
    (Utilizador Info)
    Ola... pessoalmente ja uso EXT3 desde que tive uma corrupção de disco a já alguns meses. Estou contente, pois o journaling do FS, consegue em 99.99% das vezes fazer um rollback mto completo.... contudo os restantes 0,01% é que para mim lixa td. Conhecem o ditado, "the bitch is in the detail"?... pois aplica-se aqui mto bem... esses 0.01% qd correm mal... correm mesmo mto mal e dpx nada mais ha a fazer do que repor o backup (como se tds tivessemos estas coisas). Não deixa de ser intressante e não deixa de ser mais seguro em termos de corrompimento de dados em caso de problemas, melhor q o EXT2. Caso gostem do assunto, aconselho-vos a procurar mais dados sobre um FS que veio da IBM. Ja disponivel em linux, embora sem mto suporte (!): o JFS... PS: sim ja vem nos kerneis ;oP
    Re:To ext3 or not to .... (Pontos:2, Informativo)
    por Anonimo Cobarde em 06-11-02 12:40 GMT (#6)
    O JFS nao tem mto suporte? Essa e' boa. Sabes que a IBM tem centenas (milhares) de programadores a programar full time para o Linux, em todo o planeta? Tem technology centers nos EUA (em Austin, em Houston, em Atlanta), na Indina, na Australia, na Gra Bretanha. O JFS existe ha' ANOS e ANOS (diria mesmo decadas), que ideia e' essa de que o JFS nao e' bem suportado? Oh ffs. Informa-te antes de falares, ok?

    Anyway, JFS is crap. Vejam o XFS que e' mto melhor.

    E ja' que estao com a mao na massa e gostam de ser aventureiros, ja' circulam pela LKML snapshots do novo Reiser4, que e', de facto, rapidissimo, dando uma "tareia" monumental nos outros journaled filesystems. E ainda so' vai em fase alpha. Eu uso o Reiser desde os tempos do 3.5 (ou seja, dos kernels 2.2) e nao tenho que dizer -- em termos de performance bate o ext3 aos pontos. Para os mais interessados no lado tecnico, sugiro a leitura deste documento

    Se bem que, ultimamente, o ext3 tenha evoluido imenso, especialmente com a introducao de duas novas features, indexed directories e o Orlov block allocator. As indexed directories (ou hashed trees, vulgo htree) sao uma enorme evolucao no que concerne 'a gestao de directorias com varios milhares de ficheiros -- so' a titulo de exemplo, num kernel 2.5 criar 100.000 mil ficheiros dentro de uma directoria demorava 38 minutos, e agora demora uns meros... 11 segundos! Impressionante. Quanto ao Orlov allocator (este ligeiramente martelado pelo one and only anti-social-man-himself-quickest-killfiller-on-earth Al Viro :) tenta optimizar a maneira comos e' realizada a alocaçao de blocos entre directorias e ficheiros, minimizando o tempo de seeking, e assim aumentando a performance, overall. O kernel 2.5.46 lancado nos ultimos dias integra ambas as funcionalidades.

    Anyway, e para acabar, e de algum modo responder ao teu post, um journaled filesystem _NAO_ garante a ausencia de corrupcao de dados -- um journaled filesystem apenas garante a _CONSISTENCIA_ interna do mesmo e tenta _EVITAR_ a corrupcao de metadata. Os journaled filesystems, por mto bons que sejam, nao sao a miraculosa bala de prata, ou solucao magica.
    Re:To ext3 or not to .... (Pontos:1)
    por xakalito em 06-11-02 12:52 GMT (#7)
    (Utilizador Info)
    LOL... entao faz assim... ve se descobres em PT, uma empresa CREDIVEL (tirando a IBM... ve qt pedem ;]) para deixar q te mexam no teu FS caso tenhas info q precises nele e tenhas ele emborcado....
    Re:To ext3 or not to .... (Pontos:1)
    por xakalito em 06-11-02 12:53 GMT (#8)
    (Utilizador Info)
    Era isto q me tava a referir qd diss de suporte ;P
    Re:To ext3 or not to .... (Pontos:0, Engraçado)
    por Anonimo Cobarde em 06-11-02 13:22 GMT (#10)
    Back-of-the-shack-rice-factory-somwehere-in-Asia. 'Nuff said. Now, let me introdude you to the novel concept of BACKUPS.

    Se porventura algum dos meus filesystems cometesse suicidio, de certeza que nao ia mandar os meus discos 'a IBM ou ao $VENDOR ou $DISTRIBUTION-DU-JOUR para me recuperarem os dados. Simplesmente repunha-os dos backups feitos durante a noite anterior. NUNCA mas mesmo NUNCA iria confiar na IBM ou em quem quer que fosse para andar a meter a unha nos meus dados sensiveis -- now that'd be rich.
    IBM, experiencia pessoal. (Pontos:2)
    por humpback em 06-11-02 18:56 GMT (#17)
    (Utilizador Info) http://www.felisberto.net
    A alguns meses atras um laptop IBM da empresa começou a dar problemas. Ao fim de uns dias a maquina recusava a arrancar. Sacando o disco (tinham aparecido uns erros de smart antes da maquina parar de workar) a maquina arrancava na boa. O disco fazia uns sons muito catolicos quando LEVEMENTE abanado.
    A maquina foi toda para a IBM, ao fim de 15 dias a maquina ta de volta co os dados recuperados.

    Gustavo Felisberto
    72ef1d7183eb2ea89420b94c0cf3e1f1
    apt-get install anarchism
    Re:IBM, experiencia pessoal. (Pontos:1)
    por lucipher em 06-11-02 20:58 GMT (#19)
    (Utilizador Info) http://www.unsecurity.org/
    Tenho lido imensos comentários sobre os discos IBM ide serem fracos, mas tive muito boas experiencias com um (bem antigo por sinal) de 500 e poucos megas, que sobreviveu a mais de 30 instalações de redhat 5.2 em cerca de 1 mês (não, não estou a abusar foram 30 ou mais).

    Para alem disso o disco andou a funcionar suspenso apenas por um cabo IDE, caíu várias vezes ao chão, e mesmo com o barulho todo que fazia e às vezes não arrancava à primeira (nada que uma *pancadita* não resolvesse) portou-se muito bem! eu fiquei com excelente impressão dos discos, mas já tinha visto senhores como Rusty Russel (Netfilter), Larry McVoy (Bitkeeper) a queixarem-se deles.

    Quanto ao assunto deste thread, não gostei do ext3, achei-o parecidissimo demais com o ext2 com uma _suave_ melhoria na rapidez, uso reiserfs mas ando com um certo receio que isto possa de hoje para amanhã dar o berro e la se vai umas horas de repor backups. No entanto, é sem duvida um excelente e rapido filesystem, espero usar o reiserfs 4, mas com a fama desastrosa que este tem.. vou deixar isso la pro kernel 2.6.19 (ou será 3.0.19? oh well).


    "Reality is merely an illusion, albeit a very persistent one." -- A. Einstein
    Re:IBM, experiencia pessoal. (Pontos:1, Esclarecedor)
    por Anonimo Cobarde em 07-11-02 0:35 GMT (#24)
    Os discos antigos sao, regra geral, bons. Os recentes (eg, de 98 para ca') e' que sao desastrosos. Especialmente os DTLA's e afins (vulgo Deskstar, que toda a gente se refere como DeathStar). Eu tive acesso a uma farm onde estavam em uso uns 100 discos da IBM, dos quais 87 comecaram a falhar, ao fim de alguns meses -- ainda que prontamente substituidos pela IBM, o certo e' que mais ninguem confiou neles, e acabaram todos por ser substituidos por Maxtors e Seagates, incluindo os que, aparentemente, gozavam de boa saude. Nao fosse o diabo tece-las... Aparentemente, um upgrade do firmware do disco "cura" as falhas nos mesmos, mas eu e' que nao confio mais num disco desses -- gato escaldado...

    Quanto ao resto, o ext3 so' parece o ext2 por fora, por debaixo do capot sao bastante diferentes. 'E um bom filesystem e pessoalmente uso-o e recomendo-o em ambientes de producao. Sem pestanejar. E o ext3 nao e', linearmente, mais rapido que o ext2. Depende mto do tipo de journaling que escolhes -- date=writeback, data=ordered, data=journal. Talvez para o teu workload estivesses a usar a opcao errada. Procura no google por mais detalhes, e talvez queiras dar uma olhada no ext3 da tree 2.5, e' significativamente mais rapido que o da tree 2.4 (obviamente, sendo Work-In-Progress...)

    Quanto ao Reiser, tal como ja' tinha referido antes, uso-o ha' varios anos nos meus desktops -- desde a altura em que saiu o Mandrake 7.2 (1999 ? 2000? ja' nao me lembro), sem qualquer tipo de problema. Ate' 'a data, e com dezenas de crashes e falhas de luz pelo meio, nunca perdi um unico ficheiro.

    Andas com receio do Reiser porque? Se o usaste sem problemas ate' agora, porque haveria de deixar de funcionar suavemente? Sinceramente, de toda a experiencia que tenho com o Reiser, nao tenho uma unica queixa.

    Nao percebo e' o que queres dizer por fama desastrosa do Reiser4... Nao sei se sabes, mas o Reiser4 so' foi tornado publico ha' 1 semana atras, uns dias antes do fatidico 31 de outubro, que era a data de Feature-Freeze que o Linus tinha imposto. E considerando que ate' 'a data ainda estou para ver um unico post na LKML a dizer "reiser4 ate my disk", e' de todo incompreensivel a tua afirmacao. Lembra-te tambem que o Reiser4 _NAO_ e' baseado no Reiser3, nem um unico bit. Foi escrito de raiz, e' uma code-base relativamente recente (nao tem um ano, sequer), e neste moemnto encontra-se em estado Alpha, ou seja, nem sequer chegou a Beta. Por isso e' normal que seja instavel e tenha bugs. Mas, para ja', do que tenho visto (tenho uma particao com o snapshot de ontem (05-nov-2002) a correr em 2.5.46, no meu desktop, com cerca de 4gb de MP3), gosto. O novo design modular (o Hans Reiser prefer chamar-lhe 'plugins') e' sem duvida um passo em frente, mas a joia da coroa sao as 'atomic-transactions'. Enfim, le o white-paper sobre o Reiser4 em www.namesys.com se te interessa a parte tecnica, e' mto interessante e esclarecedor.

    Quanto 'a numeracao, a proxima versao estavel vai ser 2.6, ao que tudo indica. Andou essa discussao na LKML ha' uns tempos atras, e o Linus nao parecia mto interessado em incrementar artificialmente o numero para 3.0. (can anyone say slackware? sunos? :)
    Re:IBM, experiencia pessoal. (Pontos:1)
    por lucipher em 07-11-02 5:27 GMT (#30)
    (Utilizador Info) http://www.unsecurity.org/
    Em primeiro, agradeço desde já os esclarecimentos, confesso que não estava a par de 75% do que foi dito e, irei certamente dar uma vista de olhos mais aprofundada.

    "Nao percebo e' o que queres dizer por fama desastrosa do Reiser4..."

    Eu não me referia específicamente ao reiserfs v4, referia-me ao reiserfs como um todo, talvêz a minha escrita não tenha sido a mais clara, mas também, nunca pensei que o v4 pudesse ser um re-design do código do filesystem em si. Eu definitivamente tenho receio que um dia me possa acontecer um desastre, isto porque conheco inúmeros casos de amigos meus, alguns mails que li, de pessoas que tiveram problemas com o reiserfs, e isto sim, até ver a mensagem "check transaction log ..." desaparecer, há sempre um receio da minha parte, mas quem tem ... tem medo :)

    Cheers.
    "Reality is merely an illusion, albeit a very persistent one." -- A. Einstein
    Re:To ext3 or not to .... (Pontos:2, Informativo)
    por Khazunga em 06-11-02 14:56 GMT (#13)
    (Utilizador Info)
    Ora, que mania de comprar em PT. Falas com estes senhores:

    http://www.vogon.co.uk/

    que eles levam-te o disco e mandam-to para trás em tapes:

    We specialise in large system and file-server recoveries and also work on workstations and standalone PCs, recovering from all data storage devices, all operating systems and all file/data types.(ênfase minha)

    E provavelmente ainda são mais rápidos que qualquer 'tuga que diz sempre que "está pronto prá semana".

    Re:To ext3 or not to .... (Pontos:1)
    por xakalito em 06-11-02 15:20 GMT (#14)
    (Utilizador Info)
    Cool ... tkx :))
    Re:To ext3 or not to .... (Pontos:1)
    por xakalito em 07-11-02 10:28 GMT (#32)
    (Utilizador Info)
    o unico?!??!?!?
    Duvida... (Pontos:0, Engraçado)
    por Anonimo Cobarde em 06-11-02 21:02 GMT (#20)
    Qual é a diferença entre um journaling filesystem e um filesystem normal? Alguem que me explique isto sff.
    Re:Duvida... (Pontos:1)
    por ultra em 06-11-02 23:19 GMT (#23)
    (Utilizador Info) http://www.gildot.org
    Journalling Filesystems for Linux
    distro fs (Pontos:1)
    por ruben dig em 06-11-02 21:06 GMT (#21)
    (Utilizador Info)
    mandrake -> reiser
    redhat -> ext3
    gentoo -> xfs
    debian -> ext2

    apenas a minha experiencia quando instalei cada um das distros mas nos tempos de hoje qualquer distro suporta todos os filesystems já que são suportados por kernels mais recentes

    Nunca tive problemas com nenhum deles nem reparei que fossem diferentes, não é que não sejam mas nunca precisei das features que as diferenciam. A não ser o parted só suportar o resize para o ext3 salvo erro.
    Re:distro fs (Pontos:1)
    por m3thos em 08-11-02 0:41 GMT (#38)
    (Utilizador Info) http://mega.ist.utl.pt/~mmsf
    gentoo já não é XFS fan... passou para ext3 ou reiserfs.. its up to you to choose!
    Isto por alguns raros problemas do XFS em casos que se tornavam não tão raros assim..
    enfim..

    É conforme a implementação do FS no kernel que eles escolhem o FS, se o reiserfs agora está sólido.. e o ext3 também.. então.. vai-se pra isso.. se daki a dois meses a implementação no mainline kernel tree tiver ou alguns problemas, faz-se o rollback para outro...

    Eu pessoalmente usei reiserfs durante imenso tempo. (coisa de ano e meio) Depois.. tive um problema marado com "permissões" numa directory tree.. (mesmo marado.. userid=0 sem permissões de leitura, escrita, execução...sem volta a dar), e migrei para ext3 com writeback para melhor performance.

    também ouvi dizer bem de JFS, mas não li nada que o comprove..

    só umas ultimas notas
    XFS - bom com ficheiros grandes
    reiserFS - bom com ficheiros pequenos
    ext3 - all round, conforme a configuração pode ser mais rápido, mais robusto, ou mais inovador..(writeback, ordered, metadata)

    Miguel F. M. de Sousa Filipe
    handle: m3thos
    email: mmsf@rnl.ist.utl.pt
    More Human than Human.
    XFS e ACLs (Pontos:2)
    por Astrónomo em 06-11-02 21:22 GMT (#22)
    (Utilizador Info)
    Corrijam-me se estiver enganado: o XFS é o único sistema de ficheiros que suporta Access Control Lists?

    ----
    aqui porque não deves utilizar IE, Outlook, Windows Media e Messenger.

    Re:XFS e ACLs (Pontos:0)
    por Anonimo Cobarde em 07-11-02 0:46 GMT (#25)
    O XFS para Linux nao tem ACL's. A implementacao de ACL's e' exclusiva do XFS do IRIX. No entanto, no 2.5.46 foi introduzido ACL's e Extended Attributes para ext2/ext3, um patch da autoria do Ted T'So, por isso, potencialmente, outros FS's poderao beneficiar disso, com mais ou menos martelanço. Apos uma extensa discussao sobre se ACL's fariam mesmo falta ao Linux, e apesar da veemente oposicao de algumas figuras proeminentes (Al Viro, Alan Cox, etc) e da relutancia do proprio Linus, chegou-se 'a conclusao que a userbase do Samba e' suficientemente grande para justificar a inclusao de ACL's no kernel, ainda que, em termos de seguranca, o incremento nao seja muito. Um dos maiores argumentos, e compreensivel, e' que as ACL's apenas transmitem uma falsa sensacao de seguranca, com todos os problemas que dai' advem.

    Outro patch interessante, que podera' ser incluido em breve, sao as Filesystem Capabilities, que se tem discutido na ultima semana na LKML. Quem estiver interessado pode seguir a discussao atraves dos arquivos (http://marc.theaimsgroup.net), e' mais comodo do que subscrever a propria lista, pois esta tem _MUITO_ trafego (a menos que gostem de receber 500 mails por dia, ou mais :)
    Re:XFS e ACLs (Pontos:2)
    por Astrónomo em 07-11-02 23:25 GMT (#37)
    (Utilizador Info)
    Afinal, segundo a própria SGI, o XFS para Linux suporta ACLs:
    http://oss.sgi.com/projects/xfs/featu res.html

    ----
    aqui porque não deves utilizar IE, Outlook, Windows Media e Messenger.

    Re:XFS e ACLs (Pontos:0, Informativo)
    por Anonimo Cobarde em 07-11-02 1:13 GMT (#28)
    Definitivamente, preciso de sono ;) Afinal de contas, o meu gut-feeling estava certo -- a implementacao do XFS para Linux nao possui ainda ACL's. Quote da LKML:

    List: linux-kernel
    Subject: Re: What's left over.
    From: Christoph Hellwig
    Date: 2002-10-31 3:22:53
    [Download message RAW]

    On Thu, Oct 31, 2002 at 02:00:31PM +1100, Rusty Russell wrote:
    > > I don't know why people still want ACL's. There were noises about them for
    > > samba, but I'v enot heard anything since. Are vendors using this?
    >
    > SAMBA needs them, which is why serious Samba boxes use XFS. Tridge,
    > Ted?

    XFS doesn't have ACLs either in plain 2.5.

    O Christoph Hellwigh trabalha para a SGI e e' um dos developers do port do XFS para Linux.

    So' uma nota de rodape', o JFS neste momento tambem ja' tem ACL's, a partir do 2.5.46. From 2.5.46 log:

    >shaggy@shaggy.austin.ibm.com>
    JFS: add posix acls

    The posix acls are implemented as extended attributes and are compatible
    with ext2/ext3 posix acls.
    Re:XFS e ACLs (Pontos:2)
    por TarHai em 07-11-02 1:59 GMT (#29)
    (Utilizador Info) http://www.dilbert.com
    Sabs que ha mouitos "Anonimo Cobardes" por aqui.Para todos nos resta a duvida se de facto e a mesma pessoa, se sao varios anonimos cobardes com sono...

    Seja como for, obrigado aos varios anonimos pela explicacao ;)
    ---
    anonimos e posts (Pontos:2)
    por higuita em 07-11-02 14:35 GMT (#35)
    (Utilizador Info) http://raff.fe.up.pt/~eq92025/
    eu quem, o anonimo 1, 2, 3 ou 4 8)

    anonimous do gildot, nao sejam preguisos e criem contas, primeiro o seguimento e' melhor e segundo e mais importante, a quando do arquivo dos posts, apenas se arquiva os que teem pontuacao positiva, logo se os posts anonimous nao foram moderados, ele sao perdidos com o tempo

    um ou dois posts anonimos consegue-se moderar, mas tantos posts, os pontos de moderacao nao chegam para tudo e acaba-se por perder informacao util

    a criacao de uma conta nao custa nada, fica no browser, atravez do cookie e nao volta a chatear e elimina estes problemas

    os posts anonimous apenas deveriam ser usados para temas onde o anonimato e' necessario (tipo falar de exemplos das nossas empresas mas nao se quer dizer o nome delas nem que seja associado)

    Higuita
    Re:XFS e ACLs (Pontos:2)
    por raxx7 em 07-11-02 18:49 GMT (#36)
    (Utilizador Info) http://raxx7.no.sapo.pt/
    Já agora, a versão de XFS _não_ incluida nas releases do Linus inclui ACLs.

    Remember to be the Killer, not the Victim! (Nuklear Girl)
    Re:Mac OS X 10.2.2 (Pontos:2)
    por CrLf em 06-11-02 14:42 GMT (#12)
    (Utilizador Info) http://crodrigues.webhop.net
    Segundo li algures (sorry, não tenho tempo agora para procurar) essa feature vem desligada por defeito pois representa uma penalização de performance um pouco elevada (gostaria de saber de onde vem essa penalização que aparentemente é insignificante nos journaled-fs disponíveis em Linux).

    -- Carlos Rodrigues
    Overhead (Pontos:3, Informativo)
    por jneves em 06-11-02 16:04 GMT (#15)
    (Utilizador Info) http://silvaneves.org/
    Sim, há perdas de performance. Em utilização "normal" encontram-se valores algures entre 3 a 5%. A razão para esse atraso é simples: num sistema de ficheiros não-journalled (como FAT ou ext2) apenas escreves os blocos no ficheiro e a estrutura do sistema de ficheiros. Num sistema com journal (ext3, ReiserFS, NTFS, JFS, XFS, etc.) escreves também no journal (um log que permite manter o sistema de ficheiros consistente, aconteça o que acontecer, ou quase). Esta escrita extra é o que provoca o atraso.
    I know but... (Pontos:3, Informativo)
    por CrLf em 06-11-02 18:45 GMT (#16)
    (Utilizador Info) http://crodrigues.webhop.net
    Eu sei isso, eu perguntava-me o porquê dos 10-15% de penalização a nível de performance porque me parece algo elevado (já agora o link).

    Achei isto estranho porque em algumas situações o overhead dos journaled-fs acaba por ser abafado por outras optimizações (não necessáriamente a nível da estrutura em disco mas também) que eles implementam chegando a ser mais rápidos. Um exemplo disto pode ser lido no EXT3-MINI-HOWTO:

    "Despite writing some data more than once, ext3 is often faster (higher throughput) than ext2 because ext3's journaling optimizes hard drive head motion."

    -- Carlos Rodrigues

     

     

    [ Topo | FAQ | Editores | Contacto ]