Fórum Ubuntu Linux - PT
Área para Iniciantes => Dicas e Truques => Tópico iniciado por: galactus em 06 de Abril de 2012, 08:46
-
Atenção: Leia todo o artigo antes de realizar quaisquer mudanças e por favor, FAÇA backup! Não me responsabilizo por perda de dados, eu deixo bem claro o que pode ou não acarretar risco em perda de dados. Por favor, se algo estiver errado me avise!
Data da Publicação: 06/04/2012 - Editado em 07/11/2012 - Nova edição em 18/03/2015 na sessão "Considerações Gerais"!
1) Introdução
Esse artigo não é bem um tutorial, talvez mais propriamente um relato com algumas dicas de minha experiência com ele nos últimos meses em alguns PCs e alguns Notebooks de usuários comuns. Nesses últimos meses venho utilizando o XFS em minhas máquinas pessoais e no trabalho. Como ele não é o sistema de arquivos padrão de nenhuma distro que eu conheça, o pessoal acaba não fazendo muito uso dele no desktop. Este artigo está longe de mostrar tudo o que o XFS é capaz de fazer, visei apenas a situação mais usual, um usuário comum com apenas um HD.
O XFS foi criado e pensando para ser grande. Ele é um sistema de arquivos 64bits nativo com grande escalabilidade. Seu uso em desktop geralmente é indicado para quem quer montar aquele PC onde você armazena seus filmes, o “HTPC”, contudo como acabei descobrindo, ele também pode ser muito útil para uso em geral do seu PC. Como em qualquer outro sistema de arquivos, se você quiser tirar o máximo de desempenho o ideal é você mesmo realizar a formatação manual de acordo com suas necessidades. Este é um ponto onde o XFS é muito bom, existem muitas opções de formatação de acordo com o que você precisa.
Como exemplos:
a) É possível passar parâmetros específicos se o seu sistema de arquivos tiver muitos pequenos arquivos nos diretórios para melhorar o desempenho do XFS.
b) Seu Journal interno máximo de até 128MB pode ser colocado em outro disco externo para aumentar o seu tamanho e desempenho, contudo, do que eu pude ler, não recomendo o uso dessa técnica em desktops.
c) Você pode alterar o número de grupos de alocação ou o tamanho deles de acordo com o tipo de arquivos e carga de trabalho a que o seu sistema de arquivos será submetido.
Portanto ele pode ser muito versátil como você já pode ter imaginado. Outras vantagens são:
1) É o único sistema de arquivos usado pelo Linux que permite desfragmentação online (com o seu sistema ligado e seu disco montado), assim como o NTFS do Windows.
2) Checagem do sistema de arquivos muito rápida, muitas vezes mais rápida que a do ext4.
3) Outra característica peculiar é a reserva de banda para requisições, com isso ele tenta garantir que mesmo com altas cargas de transferência de dados você será atendido.
4) Excelente para lidar com arquivos grandes, como filmes, vídeos e imagens virtuais do VmWare ou do Virtual Box.
Como desvantagens eu poderia listar:
1) Ele pode ser expandido mas não diminuído. Isso mesmo, depois de definido o seu tamanho inicial não há mais volta se quiser diminuir o tamanho dessa partição. Então muito cuidado no planejamento do tamanho das partições do XFS.
2) Para melhor desempenho e segurança de seus dados você deve usar a versão mais nova possível do XFS e um kernel moderno, de preferência do 2.6.39 em diante! Melhor ainda se for do 3.1 em diante.
3) Em suas opções padrões ele é perceptivelmente mais lento ao lidar com arquivos pequenos do que o ext4. Principalmente na hora de descompactar arquivos durante a instalação de pacotes. O que leva a um usuário comum desavisado a pensar que o XFS é muito lento como um todo o que não é verdade.
2) Formatando o Sistema
O XFS assim como o ext4 e o brtfs são sistemas de arquivos usados pelo Linux em constante evolução. Por isso na hora de procurar tutoriais sobre o XFS, me deparei com um grande número de tutoriais desatualizados. Antigamente se usava alguns parâmetros na hora de formatar para melhorar o seu desempenho, acontece que os desenvolvedores já colocaram a maior parte desses parâmetros como padrão nas versões mais recentes do XFS e do kernel Linux. Por isso o meu aviso de procurar usar as versões mais recentes do XFS e do kernel Linux! Portanto prefira versões do xfsprogs (o utilitário que gerencia o sistema de arquivos XFS) acima da 3.1.1. Atualmente a última versão é a 3.1.7 e de preferência de kerneis do 3.0 em diante.
Então para a grande maioria dos usuários desktops comuns, você pode simplesmente aceitar as opções padrões do sistema sem ter que se preocupar, isso com uma versão recente do XFS e do kernel Linux, as opções que melhoram o desempenho do XFS com arquivos pequenos serão colocadas no fstab após a formatação! Entretanto, eu chamaria sua atenção para dois parâmetros que podem ser alterados na hora da formatação, são eles o agcount e o maxpct!
O agcount especifica o número de grupos de alocação. O XFS divide o seu sistema de arquivos em grupos de alocação para aumentar o desempenho com leituras em paralelo dos blocos e inodes. Em teoria quanto maior o número de grupos de alocação, mais dados podem ser lidos em paralelo nos blocos e inodes resultando em maior desempenho. Em teoria! Na prática um número muito alto ou muito baixo pode prejudicar o desempenho de acordo com a carga do sistema e se o seu processador não tiver muito poder de fogo para processar tantas leituras em paralelo! Por padrão o mkfs.xfs calcula o número de agcount de acordo com o tamanho do dispositivo a ser formatado.
Seus valores variam geralmente entre 4 / 8 / 16 e 32. Você também pode colocar outros valores como 2/ 6 / 56 ou até mesmo números maiores. Para um usuário comum com apenas um HD, do que pude aprender lendo vários textos, prefira usar 4 para sistemas abaixo de 1TB e 16 para sistemas com mais de 1TB.
O maxpct especifica a porcentagem máxima que o sistema de arquivos pode alocar com inodes. Os valores padrões são: 25% para um sistema de arquivos com menos de 1TB, 5% para os menores que 50TB e 1% para os acima dos 50TB. Como podem ver novamente o XFS foi pensado para ser grande, quem vai usá-lo em um sistema de arquivos pequeno é quem mais vai ter espaço desperdiçado. Com 25% em um sistema com menos de 1TB você provavelmente terá um monte de inodes nos blocos iniciais do sistema de arquivos. Não use 0% pois assim todos os blocos podem se transformar em inodes! Então se o seu sistema de arquivos tiver menos de 1TB, na hora de formatar use 5% para o maxpct.
Para poder fazer uso dos comandos que colocarei abaixo você terá que instalar os dois pacotes seguintes: xfsprogs e xfsdump.
Na hora de formatar, para sistemas com menos de 1TB, você pode usar:
mkfs.xfs -i maxpct=5 -d agcount=4 /dev/sdxy
Para um sistema com mais de 1TB:
mkfs.xfs -d agcount=16 /dev/sdxy
Ao final da formatação você terá um relatório de como está organizado o seu sistema de arquivos como no exemplo abaixo:
meta-data=/dev/sda5 isize=256 agcount=4, agsize=17945472 blks
= sectsz=512 attr=2
data = bsize=4096 blocks=71781888, imaxpct=5
= sunit=0 swidth=0 blks
naming =version 2 bsize=4096 ascii-ci=0
log =internal bsize=4096 blocks=35049, version=2
= sectsz=512 sunit=0 blks, lazy-count=1
realtime =none extsz=4096 blocks=0, rtextents=0
3) Alterações pós formatação
Aqui vão algumas opções que julguei úteis para o fstab de um usuário comum, você pode pesquisar e testar outras opções que julgar útil a você:
noatime = Os tempos de acesso dos dados não serão atualizados quando lidos, apenas quando gravados. Não há risco de perda de dados com essa opção. Se o tempo de acesso dos dados for importante para você não use essa opção.
nodiratime = Os tempos de acesso dos diretórios não serão atualizados quando lidos, apenas quando gravados. Não há risco de perda de dados com essa opção. Se o tempo de acesso dos diretórios for importante para você não use essa opção.
nobarrier = essa opção faz com que a verificação dos dados entre o cache do disco e o buffer da memória não sejam mais feitas. Com essa opção ativa você acelera a gravação dos dados mas existe o risco de perda de dados em uma queda de energia ou travamento do sistema, aquilo que estiver aberto pode ser perdido.
logbufs = diz o número de buffers que devem ser guardados na memória, esse número varia de 2 a 8. Nos kerneis mais recentes o 8 já é padrão. Essa opção ajuda muito o XFS a lidar com arquivos pequenos e aumenta o consumo de RAM. Use 8 e seja feliz!
logbsize = Especifica o tamanho de cada buffer na memória! Você pode especificar o tamanho em bytes ou kilobytes, o padrão é 32k nas versões mais recentes do kernel. Você pode aumentar esse valor para 64k, 128k até o máximo de 256k! Essa opção ajuda muito o XFS a lidar com arquivos pequenos e aumenta o consumo de RAM. Use 256k e seja feliz!
allocsize = determina o tamanho final da pré-alocação do Buffer de I/O. Seu tamanho varia de 64Kib a 1Gib. Essa opção ajuda a diminuir a fragmentação do disco e aumenta a velocidade de transferência de arquivos grandes. No caso do disco rígido servir apenas para arquivos grandes como imagens ISO, use 512mb, no geral 64mb está de bom tamanho. Você não aumenta o risco de perda de dados com essa opção. Na prática notei que quanto maior esse número, melhor a taxa de transferência, mas também o sistema fica mais “preso” a essa transferência então não abuse.
delaylog = Atrasa a gravação das informações no journal do XFS o máximo possível. São parâmetros internos do XFS que determinarão quando as informações serão salvas. Essa opção acelera muito o XFS mas aumenta o risco de perda de dados no caso de uma queda de energia ou travamento do sistema. Note que você não está desativando o Journal, apenas atrasando a gravação dos dados nele. A opção delaylog não funciona em versões antigas do XFS ou do kernel linux.
osynciosync = Essa aqui é complicada, mas resumindo, essa opção tem haver com uma espécie de garantia de que as gravações dos dados e metadados ocorram em sincronia com o cache do disco. Entendeu? Eu também não! :) Para piorar ainda mais, dizem que essa opção é obsoleta e não faz mais “efeito”. Na prática o que notei é que o XFS fica muito mais ágil com essa opção no fstab do que sem ela! Faça os seus testes e observe se ela ajuda mais que prejudica seu sistema. Há sim, ela não é indicada para quem vai ter grandes bancos de dados no disco rígido e também não funciona em versões antigas do XFS e do Kernel Linux. Na prática já tive um sistema meu que deixou de reconhecer os dados da partição /home com essa opção ativa com o kernel 2.6.32! Foi só retirar a mesma do fstab que tudo voltou ao normal!
inode64 = indica que o XFS pode criar inodes em qualquer lugar do sistema de arquivos, essa opção pode criar problemas em aplicações de backup que não podem lidar com grande número de inodes. Essa opção é sempre indicada em servidores de arquivos quando fui estudar para fazer esse artigo. Na prática achei que aumenta a latência em geral. Também notei o seguinte, ou você usa o inode64 ou usa o allocsize para melhor desempenho. Os dois juntos atrasaram o sistema! Eu prefiro o allocsize para desktop e servidor de arquivos. Faça os seus testes e verifique se ele é bom pra você.
Use o seu editor preferido e como root abra o fstab para colocar alguma das opções acima:
Fstab para os que gostam de desempenho e fortes emoções :)
/dev/disk/by-id/ata-TOSHIBA_MK6465GSXN_31F8B103B-part5 / xfs
noatime,nodiratime,nobarrier,logbufs=8,logbsize=256k,allocsize=64m,delaylog,osynciosync 1 1
/dev/disk/by-id/ata-TOSHIBA_MK6465GSXN_31F8B103B-part6 swap swap defaults 0 0
Fstab para os que gostam de desempenho dentro dos limites de segurança
/dev/disk/by-id/ata-TOSHIBA_MK6465GSXN_31F8B103B-part5 / xfs
noatime,nodiratime,logbufs=8,logbsize=256k,allocsize=64m 1 1
/dev/disk/by-id/ata-TOSHIBA_MK6465GSXN_31F8B103B-part6 swap swap defaults 0 0
4) Desfragmentando e Reorganiznado o XFS
Esta é uma grande vantagem frente a outros sistemas de arquivos que sua distro pode usar. O XFS é capaz de ser desfragmentado com suas partições montadas e ativas sem risco de perda de dados. Contudo, eu sugiro que o ideal seja fazer isso com todos os programas e arquivos fechados. O motivo é simples, se for detectado que um arquivo está em uso este arquivo em particular não é desfragmentado. Quanto mais potente for o seu processador mais rápida será a sua desfragmentação. A primeira desfragmentação/reorganização é bastante demorada. O comando para desfragmentar é o xfs_fsr e deve ser dado como root. Ele vai reorganizar o sistema de arquivos um arquivo por vez, procurando compactar e melhorar a disposição das extensões dos arquivos junto aos blocos e inodes, ele também desfragmenta os 10% de arquivos mais fragmentados por vez que é executado. Como root você pode fazer:
xfs_fsr -t 8000 /dev/sdxy -v
Onde o -t é o tempo máximo que ele pode levar para desfragmentar/reorganizar em segundos. Se não colocar o -t o valor padrão é 7200 ou 2 horas. O -v é o modo verbose, ou seja, ele vai te mostrar o que está fazendo, muito bom para saber se ele pulou algum arquivo que estava aberto.
Você também pode saber o quão desfragmentado o seu disco rígido está antes de executar uma desfragmentação. O comando é:
xfs_db -c frag -r /dev/sdxy
Exemplo da saída do comando:
linux-tl2k:~ # xfs_db -c frag -r /dev/sda5
actual 232989, ideal 232230, fragmentation factor 0.33%
Eu recomendo que você faça uso do xfs_fsr todas as vezes em que uma quantidade grande de programas forem instalados ou removidos, assim como se os seus dados forem alterados de disco ou deletados. Eu não espero a desfragmentação aumentar, como ele reorganiza os inodes o sistema fica sempre ágil com a execução frequente do xfs_fsr.
-
5) Reparando o XFS
Vamos pensar o pior, seu sistema de arquivos “deu pau”! Como reparar o seu sistema corrompido ou danificado? Tá na mão, com sua partição desmontada e como root faça:
xfs_repair -v /dev/sdxy
O -v é para ver o que ele está fazendo, sete etapas serão realizadas com um relato ao final de cada uma delas como no exemplo abaixo:
root@lana-server:/home/lana-server# xfs_repair /dev/sda1
Phase 1 - find and verify superblock...
Fase 2 - usando um log interno
- log zero...
- scaneia espaço livre no sistema de arquivos e mapeia estrutura de dados...
- encontrada maior parte da estrutura de dados do super usuário.
Fase 3 - para cada AG...
- scaneia e limpa lista de agi deslincados...
- processa a estrutura de dados conhecidos e apresenta estrutura de dados descobertas...
- agno =0
- agno =1
- agno =2
- agno =3
- processa novas estrutura de dados descobertas...
Phase 4 - check for duplicate blocks...
- setting up duplicate extent list...
- check for inodes claiming duplicate blocks...
- agno =0
- agno =1
- agno =2
- agno =3
Phase 5 - rebuild AG headers and trees...
- reset superblock...
Phase 6 - check inode connectivity...
- resetting contents of realtime bitmap and summary inodes
- traversing filesystem ...
- traversal finished ...
- moving disconnected inodes to lost+found ...
Fase 7 - verificar and corrigir contagem de links...
pronto
Se o XFS foi desmontado incorretamente, você não poderá usar o comando de reparação sem risco de perda do Journal! Ele avisa isso para você caso isso aconteça. A solução é simples, tente montar a partição XFS para que ele reorganize o journal, desmonte a partição e execute o comando de reparação!
6) Considerações gerais
Na prática e no uso diário do XFS o que eu pude observar foi o seguinte:
1) Na instalação de programas ele é nitidamente mais lento que o ext4. E isso fica evidente ao se estudar um pouco sua organização interna, o XFS foi feito para ser grande, ele lida bem com arquivos grandes, instalar um pacote binário consiste basicamente em descompactar um grande número de arquivos pequenos para depois instalar os mesmos. Portanto ele também é mais lento para descompactar ou compactar arquivos do que o ext4.
2) Ele carrega muito mais rapidamente arquivos PDF que o ext4, quanto maior o arquivo melhor o seu carregamento. Se vocês prestaram atenção, quando vamos abrir um arquivo PDF ele demora para ser carregado e mais ainda para mostrar todas as figuras e textos dentro dele, principalmente em arquivos cheios de fotos. No ext4 isso é ainda mais marcante, no XFS ele mostra tudo muito mais rapidamente.
3) Imbatível na hora de executar vídeos em alta definição! Alguém aqui já conseguiu executar dois vídeos em HD no ext4 em um Atom sem engasgar o sistema e ao mesmo tempo em que faz tantas outras coisas como no vídeo a seguir? http://www.youtube.com/watch?v=9Or_rZDLbbY&feature=youtu.be
4) Mantém taxas de transferências de arquivos pela rede mais altas e constantes que o ext4.
5) Verifica muito mais rapidamente sua coleção de mp3 pelo Rhythmbox. Aquela barrinha de progresso do Rhythmbox enche muito mais rápido no XFS, além de consumir menos recursos do sistema. Se alguém já notou, em coleções muito grandes, quando o Rhythmbox é chamado e verifica sua coleção, existe um momento em que você não consegue fazer nada no Rhythmbox e algumas vezes até mesmo no sistema em geral. Isso praticamente não acontece com o XFS.
6) Ele é mais lento para abrir e fechar programas que o ext4.
7) Adiciona mais rapidamente a coleção de fotos do Picasa, também consumindo menor recurso do sistema.
8 ) O sistema em geral pode responder um pouco mais lentamente do que com o ext4, mas você consegue fazer mais coisas ao mesmo tempo sem “engasgar” o sistema, principalmente quando faz transferências de arquivos e continua a fazer outras tarefas que exigem muito do disco. Isso também é explicado pela organização interna do XFS, ele possui um recurso de reserva de banda para garantir que todas as solicitações sejam atendidas.
9) Copia, recorta e cola arquivos grandes muito mais rapidamente do que o ext4. Vejam o vídeo a seguir com o meu Atom do trabalho:
http://www.youtube.com/watch?v=_gUVyXGcTRU&feature=youtu.be
10) É muito mais lento para apagar arquivos pequenos do que o ext4.
11) Executa muito mais rápido e consumindo menos recursos do sistema máquinas virtuais do VmWare ou do VirtualBox do que o ext4.
12) Pré visualiza fotos e principalmente filmes mais rápido do que o ext4.
13) Você deve estar se perguntando se ele é um sistema de arquivos seguro, e principalmente com todas aquelas opções no fstab. Nas versões antigas do XFS eu mesmo já perdi dados, só recomendava usá-lo com um NoBreak. Mas nessas versões recentes ele está muito seguro. Mesmo com todas as opções que podem perder dados ativas no meu fstab, e eu fiz questão de usá-lo em máquinas sem Nobreak, o que eu consegui foi: 1) O Gnome chegou a perder as configurações da minha área de trabalho toda personalizada voltando as suas opções padrão. 2) O Rhythmbox “esqueceu” a minha coleção de músicas do trabalho, como se eu nunca tivesse adicionado a coleção de músicas. Tive que mandar ele refazer a coleção, todas as músicas estavam intactas. 3) Arquivos abertos no Openoffice podem ser recuperados, ele os encontrou mesmo após uma queda de energia e me perguntava se queria recuperá-los. Então eu não “consegui” perder nenhum arquivo com essas novas versões do XFS mesmo usando ele em modo não seguro.
14) Lembram daquela minha dica do hdparm no tópico do ext4? Então, nunca, mas nunca use o -W1 com o XFS, tá lá na empresa que desenvolve o XFS. Numa queda de energia sua máquina virtual pode deixar de existir, entre outras coisas, depois não diga que eu não avisei!
15) O colega lotavio trouxe mais novidades ao tópico, um artigo mostrando como o XFS fica cada vez mais rápido a partir de 4 núcleos de processadores: http://rocha.forenaite.com.br/xfs-um-sistema-de-arquivos-eficiente/ e que a partir do Kernel 3.2.12, o uso do XFS com o escalonador CFQ acaba com muitas das vantagens do paralelismo do XFS. Façam seus testes pois em alguns casos o CFQ pode continuar sendo uma boa opção, pois a Red hat continua mantendo o CFQ como escalonador padrão do XFS em sua versão 7.
Todas essas observações foram feitas com o XFS e o ext4 tunados em seus fstabs, com o journal interno e apenas um disco rígido para o sistema inteiro. Para servidores a coisa pode ficar ainda melhor para o XFS, principalmente com mais de 32TB de dados e mais de 8 núcleos de processadores!
Era isso pessoal, espero ter ajudado mais do que prejudicado!
Bibliografia Consultada para este Artigo:
http://www.mythtv.org/wiki/XFS_Filesystem
http://www.mythtv.org/wiki/Optimizing_Performance
http://www.gridpp.ac.uk/wiki/Performance_and_Tuning
http://www.novell.com/coolsolutions/feature/15844.html
http://everything2.com/index.pl?node_id=1479435
http://www.ffnn.nl/pages/articles/linux/server-wide-performance-benchmarking.php
http://xfs.org/index.php/XFS_FAQ
http://old-wiki.flexion.org/LinuxFileSystems.html
http://linuxconfig.org/choosing-the-right-linux-file-system-layout-using-a-top-bottom-process
http://mindplusplus.wordpress.com/2008/07/27/scratching-an-i/
http://mindplusplus.wordpress.com/2011/02/02/finding-the-fastest-filesystem-2011-edition/
http://mindplusplus.wordpress.com/2008/07/14/finding-the-fas/
http://ciar.org/ttk/zfs-xfs-ext4.html
http://escovandobits.wordpress.com/2008/07/26/desfragmentanto-particoes-xfs/
http://www.infoblogs.com.br/view.action?contentId=34181&Desfragmentacao-de-arquivos.html
http://www.ibm.com/developerworks/br/library/l-journaling-filesystems/
http://searchenterpriselinux.techtarget.com/tip/How-to-use-XFS-management-tools
http://old.nabble.com/Optimal-XFS-formatting-options--to33140169.html#a33140169
http://searchenterpriselinux.techtarget.com/tip/Exploring-the-features-of-the-XFS-file-system-on-Linux
http://searchenterpriselinux.techtarget.com/tip/Settings-to-optimize-an-XFS-file-system
http://www.practicalsysadmin.com/wiki/index.php/Filesystem_optimisation
http://www.practicalsysadmin.com/wiki/index.php/XFS_optimisation
http://everything2.com/index.pl?node_id=1479435
-
Pelo que eu li ele deve ser indicado para quem trabalha com edição de vídeos, músicas e imagens e servidores em geral.
-
Pelo que eu li ele deve ser indicado para quem trabalha com edição de vídeos, músicas e imagens e servidores em geral.
De maneira geral sim! Principalmente em servidores de arquivos com mais de 32TB de dados. Mas ele pode ser usado em um desktop tranquilamente, por isso fiz esse artigo. Mas realmente, para quem lida com vídeos ele deveria ser a primeira escolha, a diferença de desempenho com arquivos grandes é nítida quando comparamos XFS e o ext4. Assim como com arquivos pequenos.
-
Será que faz diferença em utilizar em uma máquina virtual... ???
-
Será que faz diferença em utilizar em uma máquina virtual... ???
Demais! Lembra que a imagem da máquina virtual é grande? Deu uma olhada no primeiro vídeo que postei acima? É um Atom rodando o XP e mostro outras coisas também.
-
Vou experimentar instalar o Ubuntu 12.04 no Win_7 e ver o que pode acontecer... já tenho um que acabei de instalar, mas vamos brincar um pouco.
Depois eu posto minhas impressões... :D
-
Vou experimentar instalar o Ubuntu 12.04 no Win_7 e ver o que pode acontecer... já tenho um que acabei de instalar, mas vamos brincar um pouco.
Depois eu posto minhas impressões... :D
Bom, você vai fazer o inverso do que seria indicado! Sua máquina virtual vai funcionar dentro do NTFS do Windows! E não dentro do XFS!
-
Bom, você vai fazer o inverso do que seria indicado! Sua máquina virtual vai funcionar dentro do NTFS do Windows! E não dentro do XFS!
Eu se... como falei, vou brincar um pouco... feriadão... sabe como é... ;)
-
Jovem, eu tava lendo aqui e vi que o XFS não pode ser diminuido. confere? E entre ele e BTRFS, qual tu recomendaria, pra uso na raiz do sistema, com /home separada (home em reiserfs).
-
Jovem, eu tava lendo aqui e vi que o XFS não pode ser diminuido. confere? E entre ele e BTRFS, qual tu recomendaria, pra uso na raiz do sistema, com /home separada (home em reiserfs).
No momento, de longe o XFS!
O BTRFS ainda está praticamente sem ferramentas para checagem do sistema de arquivos.
-
Aproveitando a deixa....pra que serve e como faz checagem do sistema de arquivos? ::)
-
Mas e quanto a diminuir uma partição xfs? Comofaz? ??? ou é normal, de boa? É que li num artigo do viva o linux que não pode ser diminuido, somente aumentado @_@
-
Leram a mensagem titulo do Galactus inteira? Acho que não! Aqui mesmo ele diz:
Como desvantagens eu poderia
listar:
1) Ele pode ser expandido mas não
diminuído. Isso mesmo, depois de
definido o seu tamanho inicial não
há mais volta se quiser diminuir o
tamanho dessa partição. Então muito
cuidado no planejamento do
tamanho das partições do XFS.
E diz também, leia todo o tutorial antes de se aventurar.
T+
-
Eu já tinha lido isso, só queria confirmar, vai que algo mudou ;-; enfim, tchau xfs ;--;
-
Aproveitando a deixa....pra que serve e como faz checagem do sistema de arquivos? ::)
Oi Renan. Vamos dizer que ocorreu aquela corriqueira queda de energia enquanto você usava o seu PC e você não usa Nobreak, como a maioria absoluta das pessoas. O seu sistema de arquivos não é desligado corretamente e é marcado como "não limpo" , afinal você poderia estar fazendo várias coisas naquela momento, navegando na internet, ouvindo música, algum documento em aberto no Office. Tudo isso que estava aberto ou em uso, que estava no cache da memória RAM ou do disco rígido pode ser corrompido ou perdido. Como você não "esvaziou" corretamente esse dados da RAM e do cache do disco rígido tudo isso pode estar perdido. Então existem algumas ferramentas para tentar evitar o pior. Uma é o arquivo de "log" do sistema de arquivos. E a outra maneira são utilitários do sistema de arquivos que verificam a integridade dos dados, sua organização interna e problemas físicos no disco rígido.
Então após uma queda de energia acidental, seus dados podem estar uma bagunça ou perdidos. Pelo menos os que estavam abertos no momento da queda, então você usa o utilitário do sistema de arquivos em questão para tentar corrigir o problema. Ele geralmente faz uma verificação completa (ou não dependendo do comando) de tudo o que está gravado em disco, se encontra "inconsistências" sejam lógicas ou físicas, ele tenta corrigir e emite um relatório ao final do processo. Isso deve ser feito com o sistema de arquivos desmontado! Senão todos os seus dados podem acabar partindo dessa para melhor! Esse processo de verificação lógica e física dos dados e do disco rígido é que chamamos de checagem do sistema de arquivos.
No caso do XFS ela é feita com o comando xfs_repair + nome do volume a ser checado. Existe uma checagem mais completa com o comando xfs_repair -n . Mas esse último comando não pode ser usado em XFS que usa atributos extendidos. Os dois comandos só devem ser executados em partições desmontadas e limpas! É isso mesmo, o xfs_repair só pode ser usado após você remontar uma partição suja! Vai entender esses desenvolvedores do XFS.
Quanto ao BRTFS, ele tá muito novo e os seus desenvolvedores no momento, estão mais preocupados em melhorar seus desempenho que a segurança dos dados. Sua ferramenta para checagem foi criada apenas em Maio de 2012, o sistema foi criado em 2007! E seus desenvolvedores afirmam que essa ferramenta pode causar mais danos ainda durante a checagem do sistema de arquivos, além da evidente falta de testes em ambientes de produção em várias situações de uso! Então, se o próprio desenvolvedor afirma isso, eu é que não vou usar no meu sistema principal um sistema de arquivos que pode detonar meus dados!
Espero ter explicado mais que complicado!
-
Obrigado pelos esclarecimentos creto! ;D
pylm69, não precisa dizer tchau para o XFS. Você pode fazer um teste para ver como é. Não precisa ser no seu sistema principal se estiver com medo.
-
Só o fato de não poder diminuir já me quebra as pernas >:( enfim, precisa de alguma macumba pro grub inicia com JFS? Eu tentei umas vezes, com o arch e com o elementary, mas o grub não iniciava, dizia que faltava alguns modulos mas os benditos estavam lá!
-
Só o fato de não poder diminuir já me quebra as pernas >:( enfim, precisa de alguma macumba pro grub inicia com JFS? Eu tentei umas vezes, com o arch e com o elementary, mas o grub não iniciava, dizia que faltava alguns modulos mas os benditos estavam lá!
O JFS não deve ser usado para partição /boot . É que nas compilações padrões do kernel ele (JFS), assim como os outros sistemas de arquivos, são compilados como módulos e não dentro do kernel. Daí na hora do boot dá pau! Usa ext3 ou ext2 na /boot e JFS para as outras partições. Eu sempre coloquei todos os sistemas de arquivos que uso dentro do kernel na hora de compilar. Fica até um pouco mais rápido.
Você quis dizer JFS mesmo, certo?
-
Sim, JFS mesmo ;D bem interessante isso, vou é separar a /boot então, deixar ela em ext4, raiz em JFS e /home em reiserfs, de boa assim?
-
Sim, JFS mesmo ;D bem interessante isso, vou é separar a /boot então, deixar ela em ext4, raiz em JFS e /home em reiserfs, de boa assim?
Sim, você pode fazer isso. Seria interessante se você pudesse testar com apenas um sistema de arquivos também. Só o JFS ou só o Reiserfs.
-
Eu sei que posso, só não sei se devo ;D ;-;
Quero usar reiserfs na home pq ele bem resistente quanto a queda de energia e jfs na raiz pq ele é rápido, ext4 no boot pra não ficar de viadagem com o grub e vou deixar uns 6 GB em ext4, só pra testes ;D
-
Eu sei que posso, só não sei se devo ;D ;-;
Quero usar reiserfs na home pq ele bem resistente quanto a queda de energia e jfs na raiz pq ele é rápido, ext4 no boot pra não ficar de viadagem com o grub e vou deixar uns 6 GB em ext4, só pra testes ;D
Baum o Reiserfs é rápido com arquivos pequenos, mas consome bastante do processador. O JFS não é o mais rápido, em muito testes ele se mostra lento, principalmente com arquivos pequenos. Ele não foi feito para ser rápido, mas para não consumir recursos do processador, ser seguro e lida bem com arquivos grandes.
-
Eu sei que posso, só não sei se devo ;D ;-;
Quero usar reiserfs na home pq ele bem resistente quanto a queda de energia e jfs na raiz pq ele é rápido, ext4 no boot pra não ficar de viadagem com o grub e vou deixar uns 6 GB em ext4, só pra testes ;D
Acho que seria melhor você fazer o inverso, utilizar reiserfs na raíz, pois numa queda de energia a raíz sofre mais que /home
e pelo fato do reiserfs lidar melhor com arquivos pequenos esta é a vantagem de tê-lo na raiz que só tem arquivos pequenos
programas, bibliotecas etc...
A única distro que não tenho Reiserfs na raiz é o Fedora pois me faltou saco para ver como habilitar na instalaçao, antigamente era muito fácil bastava digitar linux reiserfs na tela de boot.
-
Eu to olhando pra home é meus que arquivos que estão lá, se eu perder o sistema, de boa, isso é o de menos, mas a home é a home :3 mas acho que vou é deixar reiserfs na home e raiz então @_@
-
Gostei muito do seu artigo falando sobre o XFS. Me deixou bastante otimista para sua utilização,porém qual que é melhor para tunagem o ext4 ou XFS ?
Em outro artigo seu vi que você ainda não tinha utilizado o nr_request e o read_ahead_kb! no XFS e hoje em dia já fez este teste e se fez qual foi o resultado ?
;D
-
Gostei muito do seu artigo falando sobre o XFS. Me deixou bastante otimista para sua utilização,porém qual que é melhor para tunagem o ext4 ou XFS ?
Em outro artigo seu vi que você ainda não tinha utilizado o nr_request e o read_ahead_kb! no XFS e hoje em dia já fez este teste e se fez qual foi o resultado ?
;D
Depende do tipo de arquivo que você usa. Se for usar muitos vídeos e muito acesso ao disco é melhor o XFS. Se for arquivos pequenos e sem muito acesso ao disco o ext4.
Dá pra usar o nr_request e o read_ahead_kb numa boa no XFS, não deixa o sistema tão preso quanto o ext4.
-
Depois que o criador do reiserfs foi preso, ainda dão suporte a essa partição?
Tenho um Celeron 64 Bits monocore e queria saber se em um HD de 320GB ele roda de boa. Tenho muitas músicas e vídeos mas uso ultimamente pra arquivos pequenos. Mas tenho muitos vídeos e músicas no HD.
-
Olha o Reiserfs 3 não é mais desenvolvido faz tempo. Ele ainda funciona nos kerneis atuais, mas suporte quanto a correções de bugs e de segurança não tem mais. O último suspiro foi em 2008, quando a empresa que o mantinha também fechou. Então tudo é uma escolha, se para você faz sentido usar esse sistema de arquivos, não é uma partição, tudo bem. Eu não usaria. Ext4, XFS e Brtfs estão em ativo desenvolvimento e a Red Hat vai tornar o XFS seu sistema de arquivos padrão na sua versão 7 do Red Hat enterprise. Pra mim é mais futuro investir em algo que vai se tornar padrão num líder de mercado . Mas você decide.
-
Olha o Reiserfs 3 não é mais desenvolvido faz tempo. Ele ainda funciona nos kerneis atuais, mas suporte quanto a correções de bugs e de segurança não tem mais. O último suspiro foi em 2008, quando a empresa que o mantinha também fechou. Então tudo é uma escolha, se para você faz sentido usar esse sistema de arquivos, não é uma partição, tudo bem. Eu não usaria. Ext4, XFS e Brtfs estão em ativo desenvolvimento e a Red Hat vai tornar o XFS seu sistema de arquivos padrão na sua versão 7 do Red Hat enterprise. Pra mim é mais futuro investir em algo que vai se tornar padrão num líder de mercado . Mas você decide.
Ah cara, desculpe se eu não falei do XFS a partir da segunda linha. Estava me referindo a ele no meu HD de 320Gb.
-
Eu nunca usei XFS no meu computador, mas participo ativamente noutro forum Ubuntu (em Russo), e já tinha visto várias queixas deste sistema de ficheiros. Trabalha perfeitamente com ficheiros grandes e partições grandes, mas quando há necessidade de copiar muitos ficheiros pequenos (estamos a falar de milhares), velocidade cai quase até a zero.
-
[...] mas participo ativamente noutro forum Ubuntu (em Russo) [...]
[Off Topic] Caixinha de fósforo e rebimboca... em russo...?!?!?[/Off Topic]
Podia compartinhar seu tempo para ajudar aqui no fórum brasileiro também... :D ;)
-
Podia compartinhar seu tempo para ajudar aqui no fórum brasileiro também... :D ;)
É isso que estou a fazer. Sobre fósforos - não entendi...
-
Sim o XFS é lento com arquivos pequenos. Eu deixo isso bem claro no tutorial. O XFS foi feito para ser grande.
-
Olá Galactus, admiro sua dedicação em conseguir o melhor no teu Linux.
Estou com projeto de montar um servidor de arquivos para armazenar os backup's daqui, e desejo compactar esses arquivos e jogar no servidor, somente para armazenar (geralmente imagens do Clonezilla, arquivos compactados e etc).
Como você mesmo disse, o XFS foi feito para ser grande e lento com arquivos pequenos, no caso de eu ter os dois (arquivos pequenos e arquivos grandes), o que recomenda? Uma partição em EXT4 e outra em XFS ou dois discos?
É recomendável usar LVM ou uso sem mesmo?
Estou pensando em Debian ou CentOS para esse servidor, o que considera melhor?
---------------------------------
Outra coisa: Seria interessante colocar o comando de desfragmentação do XFS no "cron"?
-
Olá Arthur, realmente um cenário interessante. Você pode deixar uma partição, ou HD, com ext4 para arquivos pequenos e que serão compactados e outra partição, ou HD, com XFS para as imagens do clonezilla e outros arquivos grandes. Se tiver que usar os dois sistemas de arquivos no mesmo HD acho que vai te complicar o LVM, se não ficar inviável.
Eu posso dizer o que eu e alguns colegas estamos fazendo. Se o crescimento dos dados não é assim tão grande e rápida, nem de forma exponencial, Heheheheheh , não usamos LVM. Tenho colegas com storage da Dell e da HP que já tem tudo arrumado via hardware, o que facilita um monte né. Infelizmente não é o meu caso, mas como tenho vários HDs e não cresce tanto assim o volume dos meus dados, optei por deixar tudo com XFS, sejam os arquivos grandes ou pequenos. O XFS não é o mais rápido, mas aguenta maior quantidade de requisições nas transferências de arquivos. Então conseguimos fazer um maior número de transferências com taxas constantes ao mesmo tempo com o XFS. Usamos CentOs, um amigo usa Opensuse, nenhum dos meus colegas, e nem eu, usamos Debian. O motivo? Na hora em que o calo aperta, e eu quero dizer com muitas requisições e um monte de gente acessando os dados ao mesmo tempo, o CentOs se mostrou mais robusto, aguentou mais carga e manteve mais alta e constante as taxas de transferências dos arquivos. Não temos nada contra o Debian, só não a se mostrou o melhor para o nosso uso. Instalamos o sistema em ext4 e todos os dados estão em XFS, sejam eles grandes ou pequenos no meu caso. A maioria dos colegas trabalham com banco de dados enormes.
Eu só colocaria o comando de desfragmentar no cron se as alterações fossem constantes, senão eu mesmo executaria o comando de tempos em tempos, agora eu tenho tempo pra isso né Arthur. Se tiver ocupado demais, melhor colocar no cron mesmo.
Espero ter ajudado mais que complicado, e Arthur, se puder, faça os seus testes, afinal, o que é bom pra mim pode não ser pra você!
-
Olá Galactus, com certeza vou testar sim e seguir suas recomendações.
Será gostoso eu aprender um novo sistema (CentOS ou Suse), e vou usar dois discos diferentes mesmo (um para o sistema em ext4 e outro para dados em XFS), à questão do LVM ainda vou estudar para o ver que mais inviável, mas penso em usar RAID não.
Obrigado pela disposição e vou postar aqui sim os testes, muito obrigado!
-
Um adicional para o topico http://rocha.forenaite.com.br/xfs-um-sistema-de-arquivos-eficiente/ (http://rocha.forenaite.com.br/xfs-um-sistema-de-arquivos-eficiente/) e para quem tem 8 ou mais cores.
De uma olhada Galactus.
-
Um adicional para o topico http://rocha.forenaite.com.br/xfs-um-sistema-de-arquivos-eficiente/ (http://rocha.forenaite.com.br/xfs-um-sistema-de-arquivos-eficiente/) e para quem tem 8 ou mais cores.
De uma olhada Galactus.
Obrigado pelo texto! Por isso que um amigo meu adora XFS num servidor de banco de dados DELL com dois Xeons e muitos threads!
-
Galactus você já otimizou o Dirty_ratio e o dirty_background_ratio a favor do XFS ?
Se sim,como foi feito ?
Nas minhas pesquisas quando coloca a porcentagem do Dirty_ratio alto o pdflush inicia menos porém grava arquivos maiores,como o XFS é excelente com arquivos grandes não terá problemas de gravações com o hd contanto dirty_background_ratio tem que estar em porcentagem pequenas.
Meu objetivo com isso é ter um bom relacionamento entre swap,XFS e RAM. Penso ainda analisar vms como min_free_kbytes,pagecache para otimizar ainda mais o objetivo que tenho. :D
-
Galactus, o que acha de eu manter XFS para arquivos pesados e o EXT4 para arquivos leves e pra raiz?
-
Galactus você já otimizou o Dirty_ratio e o dirty_background_ratio a favor do XFS ?
Se sim,como foi feito ?
Nas minhas pesquisas quando coloca a porcentagem do Dirty_ratio alto o pdflush inicia menos porém grava arquivos maiores,como o XFS é excelente com arquivos grandes não terá problemas de gravações com o hd contanto dirty_background_ratio tem que estar em porcentagem pequenas.
Meu objetivo com isso é ter um bom relacionamento entre swap,XFS e RAM. Penso ainda analisar vms como min_free_kbytes,pagecache para otimizar ainda mais o objetivo que tenho. :D
Mexo neles para melhorar o desktop em geral, não pensando no XFS. Eu altero é o FSTAB ou a formatação para melhorar o XFS em geral.
-
Galactus, o que acha de eu manter XFS para arquivos pesados e o EXT4 para arquivos leves e pra raiz?
Faço isso também. Meu servidor de arquivos tem o raiz "/" com ext4 e as partições dos dados todas em XFS. Meu PC em casa também está mesclado. Tenho HDs em ext4, XFS e NTFS.
-
Olha que eu encontrei no xfs.org
As of kernel 3.2.12, the default i/o scheduler, CFQ, will defeat much of the parallelization in XFS.
Apartir do kernel 3.2.12 com CFQ a paralelização do XFS vai pra cuia, ou seja BFQ em alta eheheh ;D
É só uma chamada para atualização do tutorial. O seu tutorial é o melhor do google português qualquer coisa que
eu procure sobre XFS em português vem indicado para vir aqui no seu tutorial parabéns.Qualidade 1010
-
Olha que eu encontrei no xfs.org
As of kernel 3.2.12, the default i/o scheduler, CFQ, will defeat much of the parallelization in XFS.
Apartir do kernel 3.2.12 com CFQ a paralelização do XFS vai pra cuia, ou seja BFQ em alta eheheh ;D
É só uma chamada para atualização do tutorial. O seu tutorial é o melhor do google português qualquer coisa que
eu procure sobre XFS em português vem indicado para vir aqui no seu tutorial parabéns.Qualidade 1010
Obrigado.
Sim é verdade. No meu tutorial de acelerar o sistema sem compilações eu aviso que usar o CFQ no XFS não é bom. Mas atenda que não é tão ruim assim. Eu explico. Você já deve saber que o a Red Hat usa o XFS como sistema de arquivos padrão na sua versão 7. Assim o faz o Centos 7 também. Adivinha o escalonador de disco padrão para eles? CFQ!
E um dos principais desenvolvedores do XFS hoje é da Red Hat. Portanto eles também melhoraram as coisas para ele. Para servidores eles querem que o sistema continue respondendo mesmo com altas cargas no sistema. Seja no disco ou no processador. Então encher demais o sistema com paralelismo de disco pode não ser o ideal para uma série de coisas. Vou te dar outro exemplo do motivo de usar o CFQ. Eu uso o XFS no meu Notebook com BFS + BFQ. Fica rápido? Fica. Mas tudo tem um custo. Se eu fizer muitas transferências de arquivos o sistema fica muito "preso" nas transferências de arquivos e demora "pra burro" para responder a outras coisas de primeira. Isso num core i7! Como fica em processadores fracos? Pelo menos pra mim me parece que a dupla BFS + BFQ foi feita para o ext4. Usar o "deadline" pode ser uma boa escolha entre "custo/benefício" no XFS. Há sim, eu não mexo no escalonador do meu servidor de arquivos Centos 7, deixo no CFQ e sou feliz assim.
Outra coisa, a partir do kernel 3.16 ( pra mim a versão mais rápida dessas últimas versões), foram colocadas coisas novas para acelerar o XFS e será padrão na formatação com o xfsprogs 3.3. Até o Phoronix já testou o ext4 com os três escalonadores mais conhecidos: Deadline / Noop / CFQ. Pode ver nos testes que dependendo do que você faz o CFQ perde, ganha ou empata:
http://www.phoronix.com/scan.php?page=article&item=linux_316_iosched&num=1
Então vai depender muito do uso do sistema. Por isso muitos estão optando pelo ZFS. Ele é muito "customizável". São muitas opções que você pode usar dependendo do que você vai fazer com seu sistema de arquivos.
Obrigado pela dica de que em qual kernel a coisa piorou com o CFQ + XFS. Vou adicionar ao tuto.
-
Galactus eu quero fazer uma integração melhor com memoria->xfs->hd claro pensando em desktop.
Retendo a maior parte dos dados na memoria para conseguir velocidades maiores.
Como seria feito: para quem tem o tamanho de memoria 4GB pode reter até 60%
e para quem tem memorias de 8GB e 16GB pode reter até 80% sobrando
mais ou menos 1.6GB para o kernel,zsh e um desktop ou wm, e ainda sobrará
bastante memoria.
O problema de se fazer esse procedimento é quando luz cai perdendo os dados na memoria, fazendo
com que o tempo de escrita seja atualizada mais vezes(acaba tendo que intensificar a escrita no HD)
As vantagem são velocidade da memoria para com os dados contido nelas, como o XFS tem a
vantagem de escrever com velocidade com arquivos grandes juntando ao BFS que dará um suporte
bom para com a ideia.
Eu preciso da configuração que você fez no /proc as entradas que você modificou essas coisas até
para eu poder procurar e ver no que eu posso ajustar para esse ideia.(vai que eu consigo fazer um
atom 330 v6 ehehhe)
Obs: não tinha notado no seu vídeo com o atom 330 a velocidade que o virtual box chegou com o XP,
pensei aqui é melhor o windows colocar XFS eheheh
-
por mais que eu não queira me apaixonei pelo XFS e aqui está uma perola que demonstra isso https://lkml.org/lkml/2015/4/30/149 (https://lkml.org/lkml/2015/4/30/149)
-
lotavio, a maioria dos tutoriais para desktop usando o XFS resumem-se a pequenas alterações já mostradas durante a formatação do XFS neste tutorial, outra dica muito mostrada é aumentar o journal interno padrão do XFS. Novamente em caso de "pane" do sistema de arquivos o tempo de recuperação será muito maior! Depois da formatação, a medida principal escolhida para tunar o XFS em Desktop é o fstab! E só! Como ele é feito para ser grande, existem muitas outras opções de 'tunagem" para servidores principalmente usando RAID e alterações no sysctl.conf para melhorar transferência de arquivos. Aí vai depender do uso do sistema (arquivos grandes ou pequenos, muitos ou poucos diretórios), envolvendo a quantidade de memória a que você se referiu.
Você pode brincar ainda com o nr-requests e o read_ahead_kb ( http://ubuntuforum-br.org/index.php?topic=87597.0 ) e os escalonadores do disco rígido ou SSD. Para o XFS eles recomendam o deadline.
Esta pérola do lkml.org a que você se refere só serve para corroborar outros textos que já li e de depoimentos do desenvolvedor do ext4 e do XFS. Você vai saber se o sistema de arquivos presta mesmo com ele em uso intenso e com muito tempo de uso onde os dados estão sendo gravados e apagados, sem formatação seguida de testes sintéticos!
-
Pessoal,acabei de comprar um ssd da Kingston de 120g,é melhor ir de xfs ou ext4 ?
-
Pessoal,acabei de comprar um ssd da Kingston de 120g,é melhor ir de xfs ou ext4 ?
Ext4!
-
# /etc/fstab: static file system information.
#
# <file system> <mount point> <type> <options> <dump> <pass>
proc /proc proc nodev,noexec,nosuid 0 0
#Entry for /dev/sda1 :
UUID=c0e3e4ca-a78a-4e29-a8f2-69c970d77730 / ext4 discard,noatime,nodiratime,errors=remount-ro 0 1
#Move /tmp to RAM
tmpfs /tmp tmpfs defaults,noexec,nosuid 0 0
Galactus, eu estou usando ainda os parametros discard,noatime,nodiratime no meu fstab no ubuntu 14.04 com kernel 4.0. Ainda e necessario adicionar esses parametros ou nao e mais necessario? aqui sempre funcionou bem no meu SSD 120g da kingston, vc sua quais parametros ai no seu ssd?
-
Obrigado ,fiz a instalação em ext4.
-
# /etc/fstab: static file system information.
#
# <file system> <mount point> <type> <options> <dump> <pass>
proc /proc proc nodev,noexec,nosuid 0 0
#Entry for /dev/sda1 :
UUID=c0e3e4ca-a78a-4e29-a8f2-69c970d77730 / ext4 discard,noatime,nodiratime,errors=remount-ro 0 1
#Move /tmp to RAM
tmpfs /tmp tmpfs defaults,noexec,nosuid 0 0
Galactus, eu estou usando ainda os parametros discard,noatime,nodiratime no meu fstab no ubuntu 14.04 com kernel 4.0. Ainda e necessario adicionar esses parametros ou nao e mais necessario? aqui sempre funcionou bem no meu SSD 120g da kingston, vc sua quais parametros ai no seu ssd?
platao, meu fstab está assim:
# / was on /dev/sda5 during installation
UUID=621fb413-7368-4868-88ea-e2b12cdaaaf9 / ext4 noatime,barrier=0,data=writeback,nobh,commit=120 0 1
# /mnt/Dados was on /dev/sdb1 during installation
UUID=609475db-f6d3-4ed3-9cf1-8a1d0313c92b /mnt/Dados xfs noatime,logbufs=8,logbsize=256k,allocsize=64m 0 2
# swap was on /dev/sda6 during installation
UUID=9e1c09c5-6036-4831-a2ba-65a106026521 none swap sw 0 0
Fiz também um journal interno aumentado para 400MB e usei o tune2fs para poder usar o data=writeback no fstab! Veja que os meus dados estão em outro disco formatado em XFS! Eu uso a opção fstrim no rc.local! Há sim, lembre-se de deixar 8-10% do SSD sem formatar!
E sim, é preciso usar o discard ou fstrim no SSD!
-
Obrigado ,fiz a instalação em ext4.
De nada!
-
Entao, o recomendado pelo que vi e colocar na cron como um serviço a ser agendado e executado. Colocar no rc local o comando tem o mesmo efeito praticamente, nao e Galactus? toda vez que vc iniciar a maquina ele vai executar o comando.
Pelo que li, o descarte on-line como estou fazendo diminui um pouco a vida util do SSD, mas esta tao bom aqui que eu nem sei se vou mexer nisso!
Como eu tenho 2 SSDs da kimgston um de 60 e um de 120 estou pensando em deixar um com o descarte online e o outro pelo rc local ou pela cron e ver qual deles vai durar mais tempo....vamos ver...
-
Sim, o efeito é o mesmo se eu coloco o fstrim no rc.local. Você não vai ter maiores problemas quanto a vida útil do SSD por causa do discard. Li vários testes em revistas especializadas de informática quanto a durabilidade dos SSDs e a coisa está ótima. Os SSDs da Samsung começam a apresentar erros de realocação com aproximadamente 764TiB de dados escritos! Ele morreu com 888TiB de dados escritos! Os caras fizeram uma conta de que um usuário comum grava 10GB de dados por dia! Faça as contas. Ele pode durar 94 anos neste passo. Eles analisaram os chips de memória NAND, contudo acredito que outras coisas podem dar errado neste caminho. A Samsung é tão confiante nisso que dá 3 anos de garantia "sem limite de quilometragem" na série EVO de seus SSDs. O que se comenta é que o SSD deve funcionar de 4 a 5 anos sem esforço! Só o tempo dirá, mas to feliz demais com o meu Samsung EVO de 240GB!
Dá uma lida neste teste de 10 páginas e vários meses de testes: http://us.hardware.info/reviews/4178/10/hardwareinfo-tests-lifespan-of-samsung-ssd-840-250gb-tlc-ssd-updated-with-final-conclusion-final-update-20-6-2013
Aqui a Samsung vendendo o seu jabá, mostrando que seu SSD excede em muito as normas da JEDEC: http://www.samsung.com/global/business/semiconductor/minisite/SSD/global/html/why/MlcNandFlash.html
-
Interessante artigo Galactus, so ouço elogios sobre esses SSD Evo da sansung!
-
Galactus,tenho 2 ssds da kingston de 120 gb,um comprei agora para o linux o outro tem o windows instalado para os jogos,ele ja tem mais de 2 anos de uso e não notei perda de desempenho,continua muito rapido tanto no boot como transferencia de dados como nos jogos.
-
Estava lendo esse belíssimo tópico e me deparei uma dúvida.
Quanto ao fstrim e discard, estou usando um Crucial M4 120gb deve ter 2 anos já e percebi que não tenho nada disso habilitado. Provavelmente a vida útil dele poderia estar melhor habilitando essas opções correto?
Ok. Pelo o que percebi ext4 ou f2fs são as melhores opções para / (raiz).
E tem duas opções para adicionar, cron ou rc.local. Eu optei no caso pelo rc.local
Então após ter formatado em ext4 ou f2fs o que realmente devo acrescentar?
"fstrim -v /" no rc.local ou adicionar "noatime,discard" no fstab? Ou os dois?
É que vi o post acima do cara falando sobre colocar no rc.local ou no cron.daily acabei me confundindo.