| Esta discussão foi arquivada. Não se pode acrescentar nenhum comentário. | | | O link está mal,eu estou com problemas nos browsers ou o site está mal concebido?
|
| | | | | | 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.
|
| | | | 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
|
| | | | | 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.
|
| | | | 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....
|
| | | | Era isto q me tava a referir qd diss de suporte ;P
|
| | | 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.
|
| | | | 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 |
| | | | 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 |
| | | 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? :)
|
| | | | 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 |
| | | | | 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".
|
| | | | | 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.
|
| | | | | | | 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.
|
| | | | | | 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.
|
| | | | Corrijam-me se estiver enganado: o XFS é o único sistema de ficheiros que suporta Access Control Lists?
----
Lê aqui porque não deves utilizar IE, Outlook, Windows Media e Messenger. |
| | | | | 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 :)
|
| | | | 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.
|
| | | | 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 ;)
--- |
| | | | 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 |
| | | | 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) |
| | | | 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
|
| | | | | | 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.
|
| | | | 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
|
| |
|
