Sistemas de arquivos para GNU/Linux
Neste artigo abordarei os principais sistemas de arquivos usados em distribuições GNU/Linux atuais, tais como ext3, ext4, XFS, JFS e ReiserFS.
[ Hits: 219.859 ]
Por: Perfil removido em 22/06/2012
Sistema de arquivos ext4
O sistema de arquivos ext4 é última versão do sistema de arquivos extFS até o momento, ele é na verdade a atualização do ext3, já abordado no artigo.
O ext4 trouxe, de acordo com seus desenvolvedores, alguns recursos que não existiam no ext3, mantendo alguns que a versão anterior já possuía. Na verdade são recursos que estavam tentando implantar na versão 3 do extFS (ext3), porém, devido a alguns problemas na implementação, lançaram essa nova versão com as características descritas abaixo.
Com as mudanças de alocação atrasada, este recurso representa algum risco adicional de perda de dados nos casos em que o sistema trava antes que todos os dados tenham sido gravados no disco.
Devido a isto, o ext4, na versão 2.6.30 do kernel GNU/Linux, detecta automaticamente estes casos e reverte para o comportamento antigo. O cenário típico em que isso pode ocorrer é um programa que substitui o conteúdo de um arquivo sem forçar uma gravação para o disco com sync.
2. Criação do sistema de arquivos:
Assim como no ex3, o ext4 é lento quando se aplica um sistema de arquivos, e se o disco tiver que marcar badblocks, demora mais ainda.
O sistema de arquivos ext4, apesar de possuir journaling, não foi desenvolvido desde o inicio para suportá-lo e este recurso foi integrado a partir da versão 3 do mesmo, por isso o journal não é tão eficaz, nem no ext3 e no ext4, apesar que o último mencionado teve melhorias.
E quando o journal falhar, ele faz uso do fsck para verificar a integridade do sistema de arquivos, e se o fsck não conseguir recuperar a integridade do mesmo, seu sistema de arquivos fica corrompido.
Atualmente o ext4 é bem rápido, tem um ótimo desempenho, mas seu journal pode deixar a desejar quanto à tolerância de falhas, apesar que o mesmo teve melhorias e resiste bem.
O ext4 trouxe, de acordo com seus desenvolvedores, alguns recursos que não existiam no ext3, mantendo alguns que a versão anterior já possuía. Na verdade são recursos que estavam tentando implantar na versão 3 do extFS (ext3), porém, devido a alguns problemas na implementação, lançaram essa nova versão com as características descritas abaixo.
Principais vantagens
- Possui journaling com aprimoramento de checksum.
- Melhorias no journaling: Checagem no journaling, checksum aprimorado permitindo ao ext4 ter mais tolerância à falhas que o ext3 e restruturação mais rápida;
- Suporte para tamanhos maiores de volumes e arquivos em relação à versão 3. O ext4 tem uma margem de 1024 PB (Petabytes) ou 1EB (Exabyte) para partições e 16 TB por arquivo. Isto pode não ser importante para desktops ou servidores simples, porém com certeza é útil para servidores grandes, configurados em Raid e de alta disponibilidade.
- A indexação de quantidade de diretórios foi aumentada;
- Suporte a recuperação de arquivos Undelete: Suporte à recuperação de arquivos, permitindo que arquivos seja recuperados.
- Checagem rápida do sistema de arquivos: O fsck está mais rápido por que a nova estrutura de organização de blocos permite que partes não usadas do HD sejam puladas, o que economiza tempo numa eventual checagem.
- Melhorias na pré-alocação: Às vezes um programa vai usar um espaço do HD mas não na hora, então ele reserva o espaço que vai usar, fazendo uma pré-
alocação, ou seja, ele guarda aquele espaço pra ele e ninguém mais pode usar, como se fosse uma reserva. Para essa ação, a maioria dos file systems enchem de
zeros os inodes que eles vão reservar.
Quando essa ação é executada milhares de vezes, como em um banco de dados, esse tempo de escritas de zeros geram um delay de tempo desnecessário. O ext4 vai permitir pré-alocação de arquivos sem fazer isso, o que vai garantir uma melhoria na performance, principalmente nas rotinas de bancos de dados e em ferramentas multimídia.
- Tempo de alocação estendido: O ext4 vai conseguir manter a alocação do espaço em disco até o último momento, o que pode trazer mais performance.
- Maior número de subdiretórios: O ext3 colocava um limite de subdiretórios ou pastas de 32000, se você achava isso um incômodo, os limites serão apenas o do espaço fornecido pelo disco.
- Alocação tardia: ext4 usa uma técnica de execução do sistema de arquivos chamado allocate-on-flush, também conhecida como a atribuição de atraso. Isso melhora o desempenho e reduz a fragmentação, melhorando a alocação de blocos decisões com base no tamanho do arquivo.
- O ext4 ainda pode contar com algumas ferramentas para gerenciamento de sistema de arquivos extFS, tais como o tune2fs, mke2fs, debugfs e e2fsck.
Principais desvantagens
1. Alocação tardia e potencial perda de dados:Com as mudanças de alocação atrasada, este recurso representa algum risco adicional de perda de dados nos casos em que o sistema trava antes que todos os dados tenham sido gravados no disco.
Devido a isto, o ext4, na versão 2.6.30 do kernel GNU/Linux, detecta automaticamente estes casos e reverte para o comportamento antigo. O cenário típico em que isso pode ocorrer é um programa que substitui o conteúdo de um arquivo sem forçar uma gravação para o disco com sync.
2. Criação do sistema de arquivos:
Assim como no ex3, o ext4 é lento quando se aplica um sistema de arquivos, e se o disco tiver que marcar badblocks, demora mais ainda.
O sistema de arquivos ext4, apesar de possuir journaling, não foi desenvolvido desde o inicio para suportá-lo e este recurso foi integrado a partir da versão 3 do mesmo, por isso o journal não é tão eficaz, nem no ext3 e no ext4, apesar que o último mencionado teve melhorias.
E quando o journal falhar, ele faz uso do fsck para verificar a integridade do sistema de arquivos, e se o fsck não conseguir recuperar a integridade do mesmo, seu sistema de arquivos fica corrompido.
Atualmente o ext4 é bem rápido, tem um ótimo desempenho, mas seu journal pode deixar a desejar quanto à tolerância de falhas, apesar que o mesmo teve melhorias e resiste bem.
Páginas do artigo
1. Introdução2. Journaling
3. Sistema de arquivos ext3
4. Sistema de arquivos ext4
5. Sistema de arquivos XFS
6. Sistema de arquivos ReiserFS
7. Sistema de arquivos JFS
8. Benchmark básico dos sistemas de arquivos
9. Considerações finais
Outros artigos deste autor
Escreva para o VOL - Contribua você também!
soundKonverter - o maravilhoso conversor de áudio
Configuração do serviço NTP em servidor cliente
Instalação e uso do Superkaramba
Leitura recomendada
Ubuntu com Criptografia Total + Snapper
Recuperando arquivos deletados em partições ReiserFS
FAM - Monitorar alteração de arquivos
Introdução ao universo dos filesystems
Comentários
[1] Comentário enviado por removido em 22/06/2012 - 19:41h
Olha rapaz, achei o seu artigo excelente e fico satisfeito em ser o primeiro a comentá-lo e mais ainda por ter saído do assunto em voga "Pinguim x M$" que tá dando no saco!
Quanto aos filesystems, venho usando o reiserfs para o sistema raiz e o xfs para /home e não tenho do que me queixar, exceto o fato do Debian não incluir o reiserfs como opção no Debian Installer, em relação a isso fiz uma dica a respeito:
http://gnu2all.blogspot.se/2012/06/instalacao-do-debian-em-particao.html
Como sugestão, você poderia solicitar a adição do esquema de particionamento para cada um dos sistemas de arquivos junto a moderação do VOL, o que facilitaria a vida daqueles que vierem a criar novas partições.
Um abraço.
Olha rapaz, achei o seu artigo excelente e fico satisfeito em ser o primeiro a comentá-lo e mais ainda por ter saído do assunto em voga "Pinguim x M$" que tá dando no saco!
Quanto aos filesystems, venho usando o reiserfs para o sistema raiz e o xfs para /home e não tenho do que me queixar, exceto o fato do Debian não incluir o reiserfs como opção no Debian Installer, em relação a isso fiz uma dica a respeito:
http://gnu2all.blogspot.se/2012/06/instalacao-do-debian-em-particao.html
Como sugestão, você poderia solicitar a adição do esquema de particionamento para cada um dos sistemas de arquivos junto a moderação do VOL, o que facilitaria a vida daqueles que vierem a criar novas partições.
Um abraço.
[2] Comentário enviado por removido em 22/06/2012 - 19:54h
Obrigado pelo comentário edps e pela sugestão também.
Realmente... as vezes a galera da VOL leva a sério o papo Linux VS M$.
abraço.
Obrigado pelo comentário edps e pela sugestão também.
Realmente... as vezes a galera da VOL leva a sério o papo Linux VS M$.
abraço.
[3] Comentário enviado por pietro_scherer em 23/06/2012 - 10:28h
Ótimo artigo!
É sempre bom ter um domínio das ferramentas e métodos que utilizamos para realizar nossos trabalhos.
Me ajudou bastante, obrigado!
Ótimo artigo!
É sempre bom ter um domínio das ferramentas e métodos que utilizamos para realizar nossos trabalhos.
Me ajudou bastante, obrigado!
[5] Comentário enviado por danielsath em 24/06/2012 - 18:06h
Parabens, muito bom. So gostaria de saber a respeito de uma particao que eu encontrei aqui com o nome extend, que estava querendo saber que sistema de arquivos ela utilizar
Parabens, muito bom. So gostaria de saber a respeito de uma particao que eu encontrei aqui com o nome extend, que estava querendo saber que sistema de arquivos ela utilizar
[6] Comentário enviado por removido em 24/06/2012 - 18:19h
Um dos comandos para saber qual sistema de arquivos uma determinada partição tem é o "blkid".
# blkid /dev/sda5
Obrigado pelos comentários pessoal, grato mesmo!
Um dos comandos para saber qual sistema de arquivos uma determinada partição tem é o "blkid".
# blkid /dev/sda5
Obrigado pelos comentários pessoal, grato mesmo!
[8] Comentário enviado por xerxeslins em 27/06/2012 - 15:48h
Super artigo!
Está nos meus favoritos e nota 10 com certeza.
Super artigo!
Está nos meus favoritos e nota 10 com certeza.
[9] Comentário enviado por rdgacarvalho em 28/06/2012 - 10:45h
Ótimo artigo,
Fica a dica de no futuro abordar o Btrfs que nos trará grandes beneficios.
Abraços.
Ótimo artigo,
Fica a dica de no futuro abordar o Btrfs que nos trará grandes beneficios.
Abraços.
[10] Comentário enviado por lcnrj em 30/06/2012 - 13:47h
Uso o reiserfs há anos, estou pensando em mudar para xfs no meu hd de 1.5TB mas ouvi falar que na falta de luz ele já era. Quando pensei no ext4 me disseram que ele "gasta" mais espaço no HD. Tenho um misto de muitos arquivos pdf pequenos e muitos arquivos com mais de 250MB. Qual a sua sugestão...obrigado!
Uso o reiserfs há anos, estou pensando em mudar para xfs no meu hd de 1.5TB mas ouvi falar que na falta de luz ele já era. Quando pensei no ext4 me disseram que ele "gasta" mais espaço no HD. Tenho um misto de muitos arquivos pdf pequenos e muitos arquivos com mais de 250MB. Qual a sua sugestão...obrigado!
[11] Comentário enviado por removido em 30/06/2012 - 14:09h
Ola amigo lcnrj,
Você leu o artigo inteiro ? pois dei claras explicações durante o artigo e no final deixei algumas sugestões de uso.
Para poder dá uma sugestão de uso ideal, preciso saber qual o esquema de particionamento está sendo usado ou que pretende usar ?
Mas antes mesmo de informar, digo que a melhor solução para seu caso seria usar o ext4 no /home, pois os arquivos que citou ficam localizados no /home né isso ? o ext4 é bem rápido tem um ótimo suporte junto ao kernel, além disso trabalha muito bem com arquivos grandes e pequenos(tanto na leitura quanto na gravação).
*** Esclarecimento****
Qualquer sistema de arquivos, pelo menos até este momento pode ser corrompido, com uma queda de energia, o que existe em si é sistemas de arquivos mas consistentes que outros como foi explicado no artigo.
espero seu retorno.
Ola amigo lcnrj,
Você leu o artigo inteiro ? pois dei claras explicações durante o artigo e no final deixei algumas sugestões de uso.
Para poder dá uma sugestão de uso ideal, preciso saber qual o esquema de particionamento está sendo usado ou que pretende usar ?
Mas antes mesmo de informar, digo que a melhor solução para seu caso seria usar o ext4 no /home, pois os arquivos que citou ficam localizados no /home né isso ? o ext4 é bem rápido tem um ótimo suporte junto ao kernel, além disso trabalha muito bem com arquivos grandes e pequenos(tanto na leitura quanto na gravação).
*** Esclarecimento****
Qualquer sistema de arquivos, pelo menos até este momento pode ser corrompido, com uma queda de energia, o que existe em si é sistemas de arquivos mas consistentes que outros como foi explicado no artigo.
espero seu retorno.
[12] Comentário enviado por Tacioandrade em 11/07/2012 - 00:58h
Muito obrigado pelo artigo, acabei além de conhecer mais sobre os FS's do mercado Linux, com o que você falou sobre o JFS:
"Reparação muito eficaz de um disco com badblocks, ele consegue marcar os setores defeituosos com muita precisão, algo que outros sistemas de arquivos para Linux não fazem."
Vou tentar reavivar uns 20 HDs de la da empresa que estão em uma caixa para descarte por problemas de BadBlock. =)
Valeu mesmo. ^^
Muito obrigado pelo artigo, acabei além de conhecer mais sobre os FS's do mercado Linux, com o que você falou sobre o JFS:
"Reparação muito eficaz de um disco com badblocks, ele consegue marcar os setores defeituosos com muita precisão, algo que outros sistemas de arquivos para Linux não fazem."
Vou tentar reavivar uns 20 HDs de la da empresa que estão em uma caixa para descarte por problemas de BadBlock. =)
Valeu mesmo. ^^
[13] Comentário enviado por removido em 11/07/2012 - 11:44h
Por nada amigo Tacioandrade,
Mas lembre-se que badblocks influência diretamente no desempenho e não é garantido que o mesmo não ficará com outros badblocks, já que como tem vários setores defeituosos no disco.
abraço.
Por nada amigo Tacioandrade,
Mas lembre-se que badblocks influência diretamente no desempenho e não é garantido que o mesmo não ficará com outros badblocks, já que como tem vários setores defeituosos no disco.
abraço.
[14] Comentário enviado por jarlisson em 20/07/2012 - 14:56h
Ótimo.
Sempre lia esses nomes, mas não sabia o que significavam. Sò sabia que funcionava em um sistema, mas nao no outro, e desse via os arquivos daquele etc. Muito bom saber o porquê.
Ótimo.
Sempre lia esses nomes, mas não sabia o que significavam. Sò sabia que funcionava em um sistema, mas nao no outro, e desse via os arquivos daquele etc. Muito bom saber o porquê.
[15] Comentário enviado por jarlisson em 23/07/2012 - 04:38h
Uma dúvida. Por onde você aprendeu isso?
Queria referência de quem entende, pra estudar mais a fundo. Com uma pitada de C, se me entende.
Uma dúvida. Por onde você aprendeu isso?
Queria referência de quem entende, pra estudar mais a fundo. Com uma pitada de C, se me entende.
[16] Comentário enviado por removido em 23/07/2012 - 11:26h
Simples Jarlisson !
Estudando por livros digitais e impressos, estudando pela documentação que os desenvolvedores deixam disponível, pesquisando e estudando pela internet e principalmente, mas principalmente mesmo colocando em prática toda informação estudada e assimilada fazendo uma bateria de testes para poder comprovar o comportamento de todos os sistemas de arquivos abordados no artigo.
Abraço.
Simples Jarlisson !
Estudando por livros digitais e impressos, estudando pela documentação que os desenvolvedores deixam disponível, pesquisando e estudando pela internet e principalmente, mas principalmente mesmo colocando em prática toda informação estudada e assimilada fazendo uma bateria de testes para poder comprovar o comportamento de todos os sistemas de arquivos abordados no artigo.
Abraço.
[18] Comentário enviado por rafamarini em 19/11/2012 - 01:32h
Olá, excelente artigo!
Eu tenho uma duvida em relação ao JFS!
O Journaling que o Sistema de Arquivos JFS utiliza é o Journaling Lógico, correto?
Então, o Journaling Lógico guarda em seu log os metadados de arquivos que sofreram uma alteração recentemente, porém minha dúvida é o seguinte:
-Quando houver um evento de falha (uma queda de luz), ao religar o equipamento ele irá restaurar os dados utilizando o log realizado pelo journaling, como ele recupera os arquivos somente possuindo os seus metadados e não os dados como o Journal Físico?
Obrigado pela atenção!
Olá, excelente artigo!
Eu tenho uma duvida em relação ao JFS!
O Journaling que o Sistema de Arquivos JFS utiliza é o Journaling Lógico, correto?
Então, o Journaling Lógico guarda em seu log os metadados de arquivos que sofreram uma alteração recentemente, porém minha dúvida é o seguinte:
-Quando houver um evento de falha (uma queda de luz), ao religar o equipamento ele irá restaurar os dados utilizando o log realizado pelo journaling, como ele recupera os arquivos somente possuindo os seus metadados e não os dados como o Journal Físico?
Obrigado pela atenção!
[19] Comentário enviado por removido em 19/11/2012 - 11:46h
Obrigado pelos comentários pessoal!
Respondendo as perguntas feitas pelo amigo rafamarini.
[18] Comentário enviado por rafamarini em 19/11/2012 - 01:32h:
O Journaling que o Sistema de Arquivos JFS utiliza é o Journaling Lógico, correto?
Obrigado pela atenção!
R. Correto
[18] Comentário enviado por rafamarini em 19/11/2012 - 01:32h:
-Quando houver um evento de falha (uma queda de luz), ao religar o equipamento ele irá restaurar os dados utilizando o log realizado pelo journaling, como ele recupera os arquivos somente possuindo os seus metadados e não os dados como o Journal Físico?
Obrigado pela atenção!
R. Os metadados também armazena informação sobre a localização dos arquivos no sistema de arquivos, sendo assim, caso computador desligue de forma inesperada no momento da leitura ou escrita de um arquivo, o journal tem no log a informação(metadados) onde esta localizado os blocos do arquivo para tentar restaurar o mesmo, se necessário repetitivamente.
Em um evento citado por você dificilmente perderá o arquivo por completo. por que quando um arquivo é aberto para leitura e ou escrita, o linux cria uma cópia do mesmo, chamado de arquivo swap. assim todas as alterações feitas no arquivo, na verdade são feitas na cópia.
Quando o arquivo é salvo as alterações feitas na cópia são sincronizadas para o arquivo original pelo kernel de forma tardia ou não. Poderá ainda perder se o conteúdo do arquivo estiver em algum bloco defeituoso (bad block) ou se o journal não recebeu a tempo os metadados.
Obrigado pelos comentários pessoal!
Respondendo as perguntas feitas pelo amigo rafamarini.
[18] Comentário enviado por rafamarini em 19/11/2012 - 01:32h:
O Journaling que o Sistema de Arquivos JFS utiliza é o Journaling Lógico, correto?
Obrigado pela atenção!
R. Correto
[18] Comentário enviado por rafamarini em 19/11/2012 - 01:32h:
-Quando houver um evento de falha (uma queda de luz), ao religar o equipamento ele irá restaurar os dados utilizando o log realizado pelo journaling, como ele recupera os arquivos somente possuindo os seus metadados e não os dados como o Journal Físico?
Obrigado pela atenção!
R. Os metadados também armazena informação sobre a localização dos arquivos no sistema de arquivos, sendo assim, caso computador desligue de forma inesperada no momento da leitura ou escrita de um arquivo, o journal tem no log a informação(metadados) onde esta localizado os blocos do arquivo para tentar restaurar o mesmo, se necessário repetitivamente.
Em um evento citado por você dificilmente perderá o arquivo por completo. por que quando um arquivo é aberto para leitura e ou escrita, o linux cria uma cópia do mesmo, chamado de arquivo swap. assim todas as alterações feitas no arquivo, na verdade são feitas na cópia.
Quando o arquivo é salvo as alterações feitas na cópia são sincronizadas para o arquivo original pelo kernel de forma tardia ou não. Poderá ainda perder se o conteúdo do arquivo estiver em algum bloco defeituoso (bad block) ou se o journal não recebeu a tempo os metadados.
[21] Comentário enviado por vinteumdoonze em 16/03/2013 - 23:15h
Poxa, muito bom o seu artigo, estou estudando para LPI e aprendi muito aqui sobre File System, sei que o conteudo abordado no artigo é basico e devo procurar outras fontes, mas já foi uma grande ajuda para a compreenção do assunto.
Esta de parabéns.
Abraço.
Poxa, muito bom o seu artigo, estou estudando para LPI e aprendi muito aqui sobre File System, sei que o conteudo abordado no artigo é basico e devo procurar outras fontes, mas já foi uma grande ajuda para a compreenção do assunto.
Esta de parabéns.
Abraço.
[22] Comentário enviado por galactus em 17/03/2013 - 19:21h
Olá. Gostei do artigo, mas gostaria de deixar meus dois centavos...
Primeiro que o XFS já está muito mais seguro do que antigamente. Em kerneis antigos, realmente, em quedas de energia você poderia corromper dados, mas nas novas versões do XFS e dos kerneis não. Estes benchmarks sintéticos onde você formata um HD e faz os testes logo em seguida não condizem com a realidade de uma sistema em pleno uso, e principalmente com muito tempo de uso! Já li comentários inclusive do principal desenvolvedor do ext4 que estes tipos de testes não mostram a vida real de uma sistema de arquivos, por isso ele não leva muito em consideração esses tipos de testes.
Também assisti a uma palestra postada no Youtube do desenvolvedor do XFS da RedHat falando coisa parecida. São quase 50 minutos dele respondendo a perguntas da galera, quem tiver curiosidade de assisitir é só procurar por: XFS_ Recent and Future Adventures in Filesystem Scalability
Por exemplo, o pessoal olha esses números nus e crus e vai achar que o JFS é uma lesma! Mesmo estando defasado, não é assim. O JFS foi criado numa época em que cada pulso de clock importava, pois eram poucos e muito caros. Portanto seu objetivo era não sobrecarregar o processador e ser seguro. Instale ele numa máquina antiga com apenas um núcleo e comece a fazer mais de uma coisa ao mesmo tempo que você vai ver a que o JFS veio! Olha aqui esse meu video: http://www.youtube.com/watch?v=OCevVWiZCks
O é ext4 pode ser mais rápido enquanto tem poucas requisições sobre ele, mas é só começar a aumentar o número de requisições que a coisa fica feia, na prática você nota como se o sistema ficasse "preso" ao que ele está fazendo e passa a responder muito lentamente! Quando não dá umas congeladas. O XFS tem reserva de requisições por padrão, para não "esgotar" o sistema de arquivos rapidamente quando muitas requisições são feitas ao mesmo tempo. Eu tenho uma servidor multimedia em casa e o XFS dá banho no ext4 nisso. Fora o servidor são mais 4 máquinas, comece a abrir vários vídeos de um mesmo HD pra você ver a diferença. Melhor que ele pra streaming de video em rede só o ZFS com RAID, parece que nem faz força. Desculpem pela redação, acabou ficando quase 50 reais.... hehehehe Mas era só!
Olá. Gostei do artigo, mas gostaria de deixar meus dois centavos...
Primeiro que o XFS já está muito mais seguro do que antigamente. Em kerneis antigos, realmente, em quedas de energia você poderia corromper dados, mas nas novas versões do XFS e dos kerneis não. Estes benchmarks sintéticos onde você formata um HD e faz os testes logo em seguida não condizem com a realidade de uma sistema em pleno uso, e principalmente com muito tempo de uso! Já li comentários inclusive do principal desenvolvedor do ext4 que estes tipos de testes não mostram a vida real de uma sistema de arquivos, por isso ele não leva muito em consideração esses tipos de testes.
Também assisti a uma palestra postada no Youtube do desenvolvedor do XFS da RedHat falando coisa parecida. São quase 50 minutos dele respondendo a perguntas da galera, quem tiver curiosidade de assisitir é só procurar por: XFS_ Recent and Future Adventures in Filesystem Scalability
Por exemplo, o pessoal olha esses números nus e crus e vai achar que o JFS é uma lesma! Mesmo estando defasado, não é assim. O JFS foi criado numa época em que cada pulso de clock importava, pois eram poucos e muito caros. Portanto seu objetivo era não sobrecarregar o processador e ser seguro. Instale ele numa máquina antiga com apenas um núcleo e comece a fazer mais de uma coisa ao mesmo tempo que você vai ver a que o JFS veio! Olha aqui esse meu video: http://www.youtube.com/watch?v=OCevVWiZCks
O é ext4 pode ser mais rápido enquanto tem poucas requisições sobre ele, mas é só começar a aumentar o número de requisições que a coisa fica feia, na prática você nota como se o sistema ficasse "preso" ao que ele está fazendo e passa a responder muito lentamente! Quando não dá umas congeladas. O XFS tem reserva de requisições por padrão, para não "esgotar" o sistema de arquivos rapidamente quando muitas requisições são feitas ao mesmo tempo. Eu tenho uma servidor multimedia em casa e o XFS dá banho no ext4 nisso. Fora o servidor são mais 4 máquinas, comece a abrir vários vídeos de um mesmo HD pra você ver a diferença. Melhor que ele pra streaming de video em rede só o ZFS com RAID, parece que nem faz força. Desculpem pela redação, acabou ficando quase 50 reais.... hehehehe Mas era só!
[23] Comentário enviado por removido em 18/03/2013 - 12:18h
Obrigado pelos comentários thiagomadeira, vinteumdoonze e galactus.
galactus bom você ter comentado e passado mais informações a respeito do assunto abordado no artigo.
Obrigado pelos comentários thiagomadeira, vinteumdoonze e galactus.
galactus bom você ter comentado e passado mais informações a respeito do assunto abordado no artigo.
[24] Comentário enviado por AprendiNoLinux em 20/12/2014 - 15:03h
Fantástico artigo...
Andei pesquisando hoje sobre armazenamento e não consegui chegar em conclusão alguma rsrs.
Pelas possíveis mudanças de tamanho nas partições, a opção XFS foi descartada.
Parece que vou manter ext4 com lvm...
Fantástico artigo...
Andei pesquisando hoje sobre armazenamento e não consegui chegar em conclusão alguma rsrs.
Pelas possíveis mudanças de tamanho nas partições, a opção XFS foi descartada.
Parece que vou manter ext4 com lvm...
[25] Comentário enviado por bl4ckout em 11/03/2019 - 09:56h
Sem dúvidas o Universo Linux é sensacional e principalmente por ter uma comunidade tão viva, unida e dinâmica.
Usei o Windows por muito tempo e estou totalmente motivado a algum dia, contribuir com minhas experiências no Linux com todos aqui, no Viva o Linux.
Pode parecer simples, mas agradeço pelo esforço de todos por manter esse fórum rico como está, pois verdadeiramente é um grande refúgio para novos tripulantes.
Sem dúvidas o Universo Linux é sensacional e principalmente por ter uma comunidade tão viva, unida e dinâmica.
Usei o Windows por muito tempo e estou totalmente motivado a algum dia, contribuir com minhas experiências no Linux com todos aqui, no Viva o Linux.
Pode parecer simples, mas agradeço pelo esforço de todos por manter esse fórum rico como está, pois verdadeiramente é um grande refúgio para novos tripulantes.
[26] Comentário enviado por xerxeslins em 11/03/2019 - 10:19h
[25] Comentário enviado por bl4ckout em 11/03/2019 - 09:56h
Sem dúvidas o Universo Linux é sensacional e principalmente por ter uma comunidade tão viva, unida e dinâmica.
Usei o Windows por muito tempo e estou totalmente motivado a algum dia, contribuir com minhas experiências no Linux com todos aqui, no Viva o Linux.
Pode parecer simples, mas agradeço pelo esforço de todos por manter esse fórum rico como está, pois verdadeiramente é um grande refúgio para novos tripulantes.
http://gph.is/18Sfht9
[25] Comentário enviado por bl4ckout em 11/03/2019 - 09:56h
Sem dúvidas o Universo Linux é sensacional e principalmente por ter uma comunidade tão viva, unida e dinâmica.
Usei o Windows por muito tempo e estou totalmente motivado a algum dia, contribuir com minhas experiências no Linux com todos aqui, no Viva o Linux.
Pode parecer simples, mas agradeço pelo esforço de todos por manter esse fórum rico como está, pois verdadeiramente é um grande refúgio para novos tripulantes.
http://gph.is/18Sfht9
Patrocínio
Site hospedado pelo provedor RedeHost.
Destaques
Artigos
Compartilhando a tela do Computador no Celular via Deskreen
Como Configurar um Túnel SSH Reverso para Acessar Sua Máquina Local a Partir de uma Máquina Remota
Configuração para desligamento automatizado de Computadores em um Ambiente Comercial
Dicas
Como renomear arquivos de letras maiúsculas para minúsculas
Imprimindo no formato livreto no Linux
Vim - incrementando números em substituição
Efeito "livro" em arquivos PDF
Como resolver o erro no CUPS: Unable to get list of printer drivers
Tópicos
SysAdmin ou DevOps: Qual curso inicial pra essa área? (2)
É cada coisa que me aparece! - não é só 3% (3)
Melhorando a precisão de valores flutuantes em python[AJUDA] (5)
Top 10 do mês
-
Xerxes
1° lugar - 66.818 pts -
Fábio Berbert de Paula
2° lugar - 50.540 pts -
Buckminster
3° lugar - 17.966 pts -
Mauricio Ferrari
4° lugar - 15.689 pts -
Alberto Federman Neto.
5° lugar - 14.604 pts -
Diego Mendes Rodrigues
6° lugar - 13.283 pts -
Daniel Lara Souza
7° lugar - 12.822 pts -
edps
8° lugar - 11.396 pts -
Andre (pinduvoz)
9° lugar - 11.047 pts -
Alessandro de Oliveira Faria (A.K.A. CABELO)
10° lugar - 11.038 pts
Scripts
[Python] Automação de scan de vulnerabilidades
[Python] Script para analise de superficie de ataque
[Shell Script] Novo script para redimensionar, rotacionar, converter e espelhar arquivos de imagem
[Shell Script] Iniciador de DOOM (DSDA-DOOM, Doom Retro ou Woof!)
[Shell Script] Script para adicionar bordas às imagens de uma pasta
A maior comunidade GNU/Linux da América Latina! Artigos, dicas, tutoriais, fórum, scripts e muito mais. Ideal para quem busca auto-ajuda.
Site hospedado por:
