Marcos FRM
Highlander
Registrado
10.3K Mensagens
712 Curtidas
Pois dizem exatamente o que o PHIRON comentou, que faz bastante cache de disco e que num desligamento incorreto a chance de perder dados é maior. Daí só faltam colocar uma caveira junto para fazer você ficar com medo... Bobagem. Hoje o EXT4 pode ser até mais seguro com os hacks para lidar com aplicações mal escritas (que não usam a função fsync() de forma adequada) e com a tal de barriers habilitada por padrão. Porém a suposta segurança vem a um custo alto: desempenho horrível. Então nessa altura do campeonato temos que pensar em desempenho no desktop. Na LKML quando decidiram habilitar por padrão barriers para o EXT4 e EXT3 houve muita discussão entre os desenvolvedores do kernel, mesmo entre eles não havia consenso no início. No final as palavras do Ted (um dos principais desenvolvedores do EXT3/4) foram mais ou menos assim: "a idéia [barriers] é importante e talz, segurança do sistema de arquivos é importante e talz, ficará hablitado por padrão; o código relativo a isso realmente não é perfeito e precisa ser melhorado e talz".... Tipo: o desempenho a gente tenta arrumar depois, se der. 
PHIRON
Zumbi
Registrado
6K Mensagens
418 Curtidas
Então, eu estava dando uma olhada no JFS também, foi a IBM que desenvolveu, porém após uns testes que eu vi no phoronix eu fiquei ainda mais confuso, dependendo da aplicação X ou Y o desempenho altera muito, devemos levar em consideração também onde Cada sistema de arquivos se sai melhor, no caso do XFS por exemplo, acredito que o uso em notebooks e desktops com no-breaks seja o bastante para evitar os eventuais problemas, porém para decidir mesmo qual o melhor é complicado, precisa de muito conhecimento, é o preço que se paga por ter tantas opções, pessoalmente, para o "/" e /tmp provavelmente eu não uso mais EXT4, e se usar eu desabilito toda essa "papagaiada" de segurança, pelo menos nos meus micros de uso pessoal claro, em servidores e computadores de terceiros temos que pesar mais os prós e contras 
N0625
Super Zumbi
Registrado
7.1K Mensagens
785 Curtidas
Humm... interessante. Eu lembro que antes de usar o EXT3 como default, usava muito o Reiser. Aí aconteceu aquelas coisas com o Hans Reiser, o desenvolvimento do ReiserFS ficou parado e tal, então adotei o EXT3 e, depois o EXT4. Mas cheguei a usar o Kurumin com o XFS, e não sei qual outra distro com JFS (edit.: lembrei (?); Mandriva 2007, acho). Mas nesta época eu não parava com distro alguma. Agora que sosseguei de vez com o Ubuntu, acho válido fazer um teste com o XFS no Ubuntu 10.04.
Só que esse lance do cache me assustou, já que é ótimo para desempenho, mas ruim no caso de falta e energia. E a bateria do meu nobreak pifou semana passada. =/
Marcos FRM
Highlander
Registrado
10.3K Mensagens
712 Curtidas
O JFS aparenta estar meio morto. O XFS, entretanto, é ativamente mantido, tanto o código do kernel quanto a suíte de ferramentas xfsprogs.
RR_Fang
Super Participante
Registrado
430 Mensagens
39 Curtidas
Marcos FRM, eu recomendo um pouco de calma na adoção do XFS em um desktop ou notebook.
A arquitetura do XFS é fantástica sim, ainda mais se compararmos aos outros sistemas de arquivos de sua geração, já contando com recursos como Extents e delayed allocation (vistos hoje no Ext4 e BTRFS) desde o seu projeto original. Em tese, o design é altamente escalonável.
Na prática, o XFS possui ótimo desempenho com arquivos grandes... Mas provavelmente será preciso uma série de tweaks para melhorar a performance com arquivos pequenos e deletações.
Geralmente, aumentar o tamanho do log / journal do XFS resulta em ganhos consideráveis nas operações de deletação. É possível ainda movê-lo para um outro disco, mas não cheguei a testar este recurso. Aumentar ligeiramente o número de log buffers é outra opção interessante.
Entretanto, recomendo muito cuidado ao experimentar com Allocation Groups: embora ese recurso permita explorar ao máximo o paralelismo do XFS, especialmente em sistemas multi-núcleo, um número muito grande de grupos pode facilmente devorar CPU Time e degradar a performance. Ainda mais conforme o espaço utilizado aumente.
E, claro, utilizar o hdparm ao seu favor e montar o sistema de arquivos com a opção noatime ou pelo menos relatime são medidas bem-vindas no desktop 
-----
No momento estou com o JFS e o XFS no meu notebook, em cima do LVM2 por questões de (des)organização. Não pude otimizar a fundo o sistema de arquivos XFS até então, mas estou gostando da experiência... Quem sabe eu sossego antes de testar o BTRFS 
Ricardo "Fang MoonRupt"
< Archlinux User >
Marcos FRM
Highlander
Registrado
10.3K Mensagens
712 Curtidas
Obrigado pelas dicas. Eu lerei um pouco sobre o XFS antes de tentar qualquer coisa com ele.
angeloshimab...
Veterano
Registrado
933 Mensagens
67 Curtidas
Tudo bem, Marcos? Como este não é o tópico adequado (estou escrevendo um artigo sobre sistemas de arquivos, e devo publicar uma parte aqui), mas há algumas considerações que julgo importantes, pelo menos para você, sobre sistemas de arquivos (SAs).
A perda de dados somente irá ocorrer em caso de travamento ou desligamento não programado do sistema (p.ex., falta de energia), em duas situações (não estou considerando erros de usuário -- p.ex., algum editor com dados alterados, sem gravação): (i) dados alterados na memória cache que não foram transferidos para o disco; (ii) dados alterados que foram enviados para o disco, mas foram interceptados pelo write cache. Ambas as condições podem ser evitadas com um no-break.
A situação (i) pode ter o impacto reduzido se o cache for sincronizado em intervalos menores. Atualmente as páginas (dirty pages) são marcadas para gravação em disco após 30 segundos (/proc/sys/vm/dirty_expire_centisecs = 3000). É desaconselhável colocar um valor muito pequeno (tente algo entre 1500 e 2500). Os valores em dirty_background_ratio (5) e dirty_ratio (10) são suficientemente baixos -- não sei até quanto podem ser reduzidos, assim como dirty_writeback_centisecs (= 500 => 5 s).
A situação (ii) tem duas soluções. Na primeira, habilita-se o write cache no disco (ou na controladora, se SCSI), e também a opção barrier (na montagem do SA), havendo uma perda de desempenho que, a meu ver, não compensa. A segunda opção é simplesmente desabilitar o write cache e usar a opção nobarrier no SA. No caso de controladora SCSI, principalmente RAID, essa é a opção indicada pelo próprio fabricante, ou então colocar uma bateria para o write cache (neste caso, habilita-se o write cache e usa-se a opção nobarrier no SA).
O XFS não é mais sensível a perda de dados que o Ext3 e o ReiserFS. O Linux usa o page cache agressivamente para melhorar o desempenho, e pode haver perda de dados em qualquer SA. Eu mantive um servidor de arquivos com XFS por anos, e houve vários problemas de interrupção de energia, em finais de semana, em que a carga das baterias não foi suficiente, e mesmo assim não houve corrupção do SA. Atualmente mantenho dois servidores de arquivos para arquivos grandes (centenas de GiB) em RAID-0 e RAID-5 -- já houve várias quedas de energia não suportadas pelos no-breaks, sem corrupção do XFS.
Desempenho: este é um fator difícil de analisar. Cada usuário e administrador de redes têm necessidades diferentes e preferências pessoais. Um parâmetro muito citado e (quase) nunca definido é o desempenho em relação ao tamanho do arquivo. Dizem (eu inclusive) que o ReiserFS é o melhor com arquivos pequenos e o XFS é o melhor com arquivos grandes. Mas quais são os valores que determinam esses tamanhos (ou classes de tamanhos)?
Estudando a especificação dos sistemas (Ext3, ReiserFS v3 e XFS), cheguei a algumas conclusões. O primeiro ponto a considerar-se é o contexto histórico. Entre 1999 e 2002, quando os SAs com journaling foram desenvolvidos ou adaptados para Linux, arquivos pequenos tinham centenas de bytes apenas, chegando no máximo a alguns milhares de bytes. Arquivos grandes eram arquivos de vídeo, com centenas de MiB. Hoje, arquivos de texto, muito usados, têm dezenas de KiB. E uma música MP3 ocupa alguns MiB.
O ReiserFS obtém seu melhor desempenho quando o arquivo é menor que 4 KiB, mais precisamente 4048 bytes. Não vou considerar aqui o recurso de tails, pois não é mais habilitado por padrão. Um arquivo no ReiserFS (excluindo-se a opção tail) é armazendo em um bloco formatado denominado item direto (direct item) ou em blocos não formatados apontados por itens indiretos (indirect itens). Um item direto consiste em um bloco formatado com dois cabeçalhos (headers): o cabeçalho do bloco e o cabeçalho do item. Cada um tem 24 bytes de tamanho, portanto o espaço para o item (neste caso, dados do arquivo) é de 4096 - 2x24 - 4048 bytes. Portanto, este deve ser o valor limite para um arquivo pequeno.
O Ext3 acessa mais rapidamente arquivos que ocupem no máximo 12 blocos (este é o número de endereços diretos que podem ser referenciados no nó-i do Ext3). Considerando-se um bloco com 4 KiB, o Ext3 é mais rápido com arquivos cujo tamanho seja igual ou inferior a 48 KiB. Este pode ser considerado um limite adequado para arquivo médio.
O XFS trabalha com extensões, onde o tamanho de cada extensão pode ter no máximo 8 GiB. Um arquivo pode usar várias extensões (e provavelmente ficará fragmentado). Portanto, pode-se considerar um arquivo como grande usando-se qualquer valor maior que 48 KiB. O uso de extensões é bastante complexo, por isso o XFS tem um desempenho sofrível para arquivos pequenos e médios. A análise que eu fiz de alguns testes de benchmark sugere que o XFS tem desempenho igual ou superior ao Ext3 e ReiserFS para arquivos com tamanho entre 60 KiB e 100 KiB. A partir de 100 KiB o XFS normalmente tem desempenho superior.
O ponto fraco do XFS é realmente a remoção de arquivos. Existem ajustes para melhorar, mas não igualar, o desempenho do Ext3 e do ReiserFS.
Os pontos fortes do XFS são a estabilidade e o conjunto de ferramentas, particularmente o xfs_fsr, para desfragmentação de arquivos.
jqueiroz
Cyber Highlander
Registrado
104K Mensagens
5.7K Curtidas
O XFS não é mais sensível a perda de dados que o Ext3 e o ReiserFS. O Linux usa o page cache agressivamente para melhorar o desempenho, e pode haver perda de dados em qualquer SA. Eu mantive um servidor de arquivos com XFS por anos, e houve vários problemas de interrupção de energia, em finais de semana, em que a carga das baterias não foi suficiente, e mesmo assim não houve corrupção do SA. Atualmente mantenho dois servidores de arquivos para arquivos grandes (centenas de GiB) em RAID-0 e RAID-5 -- já houve várias quedas de energia não suportadas pelos no-breaks, sem corrupção do XFS.
Nossos servidores OES são todos instalados em XFS. Não tenho notícia de qualquer um de nós, em qualquer das filiais pelo país inteiro, tenha perdido arquivos com falta de energia. Mas nem por isso deixamos de ter nosso nobreak.
Desempenho: este é um fator difícil de analisar. Cada usuário e administrador de redes têm necessidades diferentes e preferências pessoais. Um parâmetro muito citado e (quase) nunca definido é o desempenho em relação ao tamanho do arquivo. Dizem (eu inclusive) que o ReiserFS é o melhor com arquivos pequenos e o XFS é o melhor com arquivos grandes. Mas quais são os valores que determinam esses tamanhos (ou classes de tamanhos)?
Acredito que o tamanho do bloco de alocação tenha a ver com isso, não?
"chmod 777 nunca ajudou ninguém" (c) 2002-2021 JQueiroz/FGdH
Conheça o
Blog do Zekke
angeloshimab...
Veterano
Registrado
933 Mensagens
67 Curtidas
Não. Os três SAs (Ext3, ReiserFS e XFS) usam blocos com 4 KiB. O ReiserFS v3 suporta apenas este tamanho, o Ext3 e o XFS suportam tamanhos menores, mas os testes em geral são feitos com blocos de 4 KiB. Este é o tamanho da moldura de página (page frame) em sistemas x86 (32 e 64 bits) e o alinhamento entre ambos permite o maior desempenho.
Como disse, uma importante razão para o desempenho diferenciados entre os três é o modo de alocação de blocos para um determinado arquivo. Detalhando mais:
(i) O ReiserFS foi projetado (no fim do século passado) para otimizar o desempenho com arquivos pequenos. Inclusive foi largamente usado, no princípio, a opção tails, que empacota vários arquivos pequenos em um único bloco. Como isso piorava o desempenho geral, essa opção não é mais usada (embora continue disponível). Quando um arquivo tem até 4048 bytes, o ReiserFS aloca um bloco logo após ou muito próximo de um bloco denominado stat item, que nada mais é do que o equivalente ao nó-i em outros SAs. Assim, o desempenho será ótimo. Para arquivos maiores, o desempenho cai rapidamente, pois deve-se alocar primeiro um item indireto (outro bloco), que contém os endereços de até 1012 blocos não-formatados, que irão conter os demais dados do arquivo. Além disso, a alocação é feita por blocos, devendo-se varrer mapas de bits que estão espalhados no disco (um mapa de bits a cada 32 768 blocos).
(ii) O Ext3 aloca diretamente até 12 blocos, tendo seu desempenho ótimo com arquivos de até 48 KiB. Para arquivos maiores, deve usar blocos indiretos, fazendo mais acessos a disco. A alocação também é por blocos, usando mapas de bits com a mesma distribuição do ReiserFS. Eu considero 48 KiB um valor razoável para determinar o que é um arquivo de tamanho médio -- esse tamanho comporta páginas HTMLS e alguns tipos de documentos.
(iii) O XFS usa alocação por extensões, podendo alocar de uma única vez até 8 GiB para um arquivo. Entretanto, o uso de árvore balanceada com extensões torna o esforço de gravar e apagar arquivos pequenos e médios um limitador para o desempenho. Para arquivos maiores, entretanto (poderiam ser considerados como arquivos grandes?), o desempenho é muito bom, não somente pelo método de alocação, mas também por evitar a fragmentação.
Marcos FRM
Highlander
Registrado
10.3K Mensagens
712 Curtidas
angeloshimabuko, jqueiroz, eu estou para colocar um NAS frankstein doméstico tabajara aqui com dois HDs, um de 80GB e outro de 160GB. Usarei LVM para juntar os discos.
Ah, e tudo certo sim, angeloshimabuko. Sempre um privilégio ler suas aulas!
HD1 (80GB)
Partição 1: 0x83, EXT3 -- /boot (250MB)
Partição 2: 0x8e -- PV1 (79GB)
HD2 (160GB)
Partição 1: 0x8e -- PV2 (160GB)
Grupos de Volume
VG1: PV1 + PV2
Volumes Lógicos no VG1
LV1: swap (2GB)
LV2: /, EXT4 (10GB)
LV3: /home, XFS (227GB)
* Tudo arredondado, sem considerar os prefixos binários
Estou usando como base o particionamento padrão do Fedora, que fica mais ou menos assim.
Sobre o XFS, dá para configurar bastante coisa nele, porém nessa mensagem na lista de discussões do XFS, Eric Sandeen diz:
In general, the defaults are optimal for generic use; unless you have
a specific use case that is suffering, it's hard to make recommendations
beyond the defaults....
Então acho que devo começar pelo padrão e ver como a carroagem anda. Os arquivos que serão armazenados no /home acho que podem ser chamados de "grandes": músicas, filmes, fotos, ISOs de CD/DVD, etc.
Pelo jeito a história que o XFS come criancinhas se não for usado com UPS é outro mito... :nao_sei_de_nada:
carq
Geek
Registrado
3.3K Mensagens
65 Curtidas
pelo que eu pude observar o reiser e o ext 3 seriam mais para desktop e o xfs
para servidores de arquivos grandes seria mais ou menos isso para um sistema comum de desktop que não iria ter arquivos maiores que 50mb o ext3 me parece a melhor opção porem eu por minha experiencia no linux sempre achei o reiserfs mais rapido no sistema não por que tudo nele responde mais rapido do que o ext3 mais eu fico entre esses dois ai para desktop
