Mostrando postagens classificadas por relevância para a consulta ext4. Classificar por data Mostrar todas as postagens
Mostrando postagens classificadas por relevância para a consulta ext4. Classificar por data Mostrar todas as postagens

Experimentando HD Hitachi

 Um habito que eu tenho é de tempos em tempos comprar um novo HD para fazer backup dos meus dados. A ultima vez que eu comprei um HD foi (pelo o que eu me lembre) em 2012. Então esse ano eu resolvi comprar um novo para garantir que meu HD não vai morrer.
Dica SysAdmin: Peque sempre pelo excesso, nunca pela falta*.
* Claro que essa dica fica dentro do limite do orçamento.

 Existem vários fabricantes de HDs: SeaGate, Maxtor (que se tornou uma divisão da Seagate em 2.006), Samsung, Western Digital, me lembro que vi um Mitsichita uma vez no MacBook White do meu irmão, Toshiba e Hitachi. Os dois últimos mencionados são um dos melhores fabricantes de HDs que eu conheço.
 A Hitachi é uma forte aliada ao Linux sendo membro ouro bem ao lado da Google. Outra forte fabricante de HD e também aliada ao Linux, é a Toshiba (que ambas podem ser conferidas mesta imagem):



  Em 2.011, a divisão de HDs da Hitachi foi adquirida pela Western Digital. Não somente isso, mas a Sandisk também é uma corporação da Western Digital (cé bichão mesmo hein Western Digital). A Western Digital é outra que também é aliada ao Linux sendo membro prata (não tanto quanto a Hitachi, mas já está de bom tamanho):


 E por que não comprar um novo SSD? Por questão de confiabilidade. Eu possuo um SSD; ele é muito bom, ocupa menos espaço, a temperatura de um SSD é bem mais baixa (ele é quase frio mesmo em atividade), mas o que mais me atrai em um SSD (e acho que a todo mundo) é o desempenho. Outra coisa que me atrai é ter a maior chance de não perdê-lo em uma queda de energia. Eu já tinha perdido dois HDs com queda de energia e foi aí que então decidi comprar um SSD. Se ocorrer queda de energia novamente, tenho maior probabilidade de não perdê-lo devido não ser um dispositivo mecânico girando um disco com uma agulha gravando em cima.


 Mas tratando-se de backup, SSDs não são confiáveis. Pode-se fazer backups em SSDs, não é esse o problema e o problema não é visto de imediato;  o problema é que os SSDs possuem tempo de vida indeterminado e eles param de funcionar de uma hora para outra (inesperadamente). Não é como a outros dispositivos que vão apresentando falhas ao longo do tempo e aos poucos vão morrendo. Quando eles param de funcionar, param de uma vez só. Outro problema é que os SSDs começam a perder dados com a ausência de energia. Portanto, nessas condições, ainda prefiro confiar nos HDs para os meus backups.

Eu possuo dois HDs da Seagate de 500GBs para fazer meus backups; um com ext4 e outro com XFS.  De tempos em tempos compor um novo HD como prevenção. Quando fui pesquisar sobre HDs para que eu pudesse comprar um novo esse ano, vi um benchmark da empresa Back Blaze, uma das melhores empresas de armazenamento de dados do mundo. Mencionei essa empresa no vídeo "Não viva de boatos (Quebrando paradígmas 2ª parte - Linux VS FreeBSD)" que pode ser conferido logo abaixo se ainda não assistiu:



 E outros gráficos da empresa me convenceram a comprar HD da Hitachi:


 Beleza; então, foi o que eu fiz. Comprei um HD da Hitachi. Primeiro que foi difícil de encontrar; quando encontrei, os caras me enrolaram mais ou menos 10 dias para depois me oferecer um da Western Digital pelo mesmo valor de um da Hitachi (AH, VÃO SE...)

Bom, pedi reembolso e comprei em outro lugar (que foram ninjas na hora de entregar). Chegado em casa, fiquei parecendo criança quando ganha presente novo. O HD é lindão, todo fechado, apesar de ser SATA ele possui dois tipos de portas para alimentação (sendo do novo modelo SATA e do anti IDE, que preferi usar o IDE por ter apresentado melhor desempenho):


Reparem a placa lógica da bagaça
Coloquei dois HDs para comparar a espessura da bagaça. O de baixo é o Hitachi e o de cima o SeaGate.
Se repararem na sua parte traseira, ele possui cabo de alimentação do modelo SATA e do IDE:



utilizei o cabo de alimentação do padrão IDE

 Beleza, conferi no BIOS do meu PC e tudo OK, foi reconhecido.



 Beleza, o próximo passo é fazer ele funcionar no Linux. Bora para o arrebento então (se bem que foi simples, nada de anormal).

 A princípio pode parecer estranho o HD não ter sido reconhecido pelo comando "blkid". A questão é que o comando blkid consulta essas informações no superbloco (bloco que contem informações de tipo de filesystem, tamanho, blocos de dados, blocos livres, inodes e dentre outras coisas); e como o HD ainda não havia sido formatado, logo ele não possuía partições e onde o comando blkid consultar e me retornar informações. Foi onde apliquei o comando "dmesg" com e filtrei para encontrar os dispositivos SATA (e descobrir se o HD havia sido detectado pelo sistema):
blkid exibindo somente um dispositivo
Comando  "dmesg" exibindo dispositivos SATA durante o processo de boot
Dispositivos sendo exibido através do "ls /dev/sd?"
 Sabendo qual o dispositivo, então, bora formatá-lo. Eu não tenho o hábito de usar o fdisk; geralmente quando formato um dispositivo, eu utilizo o cfdisk:







Esse HD possui suporte a GPT; então aqui vamos nós utilizar GPT.



 Ok. Feito o trabalho de criar as partições em 0x83 (partição Linux), bora formatar:

Desta vez eu resolvi utilizar o BTRFS como filesystem padrão nesse novo dispositivo.


 Beleza; feito isso, é só alegria. Bora fazer backup dos outros HDs para o novo Para eu ter as minhas cópias idênticas.


Exibindo espaço disponível dos dispositivo na ultima linha com o comando df -h
 Tenho que mencionar que achei estranho a principio o fato de HD, além de ser rápido, ser mais silencioso que os HDs convencionais (o que é show de bola).

Uma características do BTRFS é que o filesystem realiza verificação no momento do boot.


 Fiz um teste básico copiando 100 arquivos com tamanhos variados sendo o menor com coisa de 6KBs e o maior, em torno de 80MBs. No primeiro teste, copiei os arquivos do pendrive para o SSD com ext4 e o resultado foi o seguinte:

Levou pouco mais 7 segundos para os arquivos serem copiados

 Em seguida copiei os mesmos arquivos do pendrive para o HD Hitachi com o BTRFS:

O resultado foi surpreendente levando pouco mais de um segundo.

 Testei também com um vídeo que tenho do ZedOS (uma distribuição que é feita por um amigo de Portugal que vou fazer vídeo ainda no canal para ajudar a divulgar) salvo no pendrive:

Esse foi o resultado no HD Hitachi com o BTRFS

Esse foi o resultado no SSD com o Ext4
 Claro que nesse caso o filesystem também tem que ser avaliado. O teste mais correto seria ter testado os dois dispositivos com o mesmo filesystem ou os diferentes filesystems no novo dispositivo, mas pela lógica, o SSD favoreceria o Ext4 pelo fato de HD ser um dispositivo que fica em constante movimento e o SSD um dispositivo solido; mesmo assim o BTRFS mostrou ter desempenho surpreendente bom.

 Sendo franco, eu poderia ter feito isso graficamente, mas não é um hábito que tenho. Não é que fazer isso pelo terminal seja melhor ou pior, é porque basicamente já estou condicionado a fazer pela linha de comando. Qualquer dia desses eu paro para ver como fazer isso pela GUI. Saber tal coisa também é importante para no caso estar preparado para um dia atender um cliente.

Como analisei o ext4 do Linux e do HelenOS?

Resultado de imagem para ext4
Sistema de arquivos ext2/4 está presente no HelenOS também
 No vídeo "Que distribuição é essa?" onde debato sobre o sistema operacional micro-kernel HelenOS (já se tocaram de que não se trata de Linux, não é?) e que venho mencionando desde o artigo 5 diferentes modelos de kernels, tratei de desmistificar que o sistema de arquivos ext4 que também é utilizado pelo sistema, não é o mesmo utilizado pelo Linux. Cheguei a utilizar a frase de Dennis Ritchie após ter analisado o sistema operacional Coherent da Mark Williams Company:
É um Unix, mas não é o Unix da AT&T/Bell Labs. Esse é um clone.
Basicamente isso que foi dito. 


Cheguei a mencionar no vídeo que não sabia qual teste foi realizado por Dennis Ritchie; mas  depois do vídeo, encontrei um texto onde Dennis relata o que foi feito:
O que eu fiz na verdade foi brincar com o Coherente e procurar por peculiaridades, bugs, etc que eu sabia da existência nas distribuições Unix do tempo. Seja qual for a coisa legal que havia sido conversado a respeito nas cartas entre a MWC e a AT&T não me autorizaram a olha em seu código fonte.
Eu fiz algumas anotações sobre coisas que eu procurei.

Eu concluí duas coisas:

Primeiro, que era difícil de acreditar que o Coherent e suas aplicações básicas não foram criadas sem considerável estudo do código do OSe detalhes de suas aplicações.
Segundo, que olhando em vários cantos me conevneceram de que eu não consegui encontrar qualquer coisas que foi copiada. Pode ter sido que algumas partes foram escritas com nossa fonte próxima, mas ao menos o esforço foi feito para reescrever. Se eu viesse, eu nunca poderia honestamente testificar que minha opinião fosse de que o que eles geraram fosse irreproduzível a partir do manual.

O texto pode ser conferido na integra aqui

NÃO SE ESQUEÇA DE SE INSCREVER NO MEU CURSO DE MIGRAÇÃO PARA LINUX.
NÃO SE ESQUEÇA DE SE INSCREVER NO MEU CURSO DE MIGRAÇÃO PARA LINUX.

As 5 Ultimas Notícias Da Semana Sobre Linux

Com o lançamento do kernel Linux 4.1 e a Linux Foundation anunciando o projeto Open Container, achei interessante publicar a noticia aqui também.


Lançado o kernel linux 4.1; CryEngine da Crytek Adota Linux; CII Financia Três Projetos OpenSource; Patch de Correção para o Adobe flash Player; A Linux Foundation anuncia projeto Open Container Project

 1) Kernel Linux 4.1 é lançado: No dia 22 de Junho foi lançado o kernel Linux 4.1. Além das versões 3.10.X, 3.14.X e o 4.0.X, a versão 4.1 possui LTS (Long Time Support). Recentemente foi encontrado um bug no kernel 4.0.2 na questão de uso do uso de RAID com o sistema de arquivos EXT4. É dito que esse bug que afeta diretamente todas as principais distribuições, que além de estar presente também no kernel 4.1, ainda não possui previsão para correção. Dentre seus novos recurso, podemos encontrar:
  • Novo driver Nouveau DRM driver que traz suporte a NVIDIA Geforce GTX 750.
  • O sistema de arquivo EXT4 file agora possui suporte a file-system level encryption.
  • Melhor suporte aos processadores Intel Atom (Bay Trail).
  • Suporte ao novo Intel Skylake.
  • Algumas melhoras ao sistema de arquivo Btrfs.
Linus afirma que obviamente o merge window para a versão 4.2 está aberta (merge window é o processo de desenvolvimento de software que é utilizado para grandes projetos), o que significa que provavelmente teremos um RC pronto em algumas semanas.

2)CryEngine da Crytek adota Linux; isso significa suporte ao SteamOS. Pois é, o bagúiu tá ficando louco para o lado do Linux no mundo dos games.

O Dionatan do canal e blog Diolinux já havia publicado dois artigos sobre o CryEngine para Linux, sendo um em Março desse ano e outro em 2.012 que podem ser conferidos abaixo para mais detalhes (por que convenhamos, sou péssimo para jogos):


3) A Iniciativa de Infra estrutura núcleo da Linux Foundation (The Linux Foundation's Core Infrastructure Initiative, também chamada CII que foi criada em abril de 2.014 devido as noticias da vulnerabilidade heartbleed do OpenSSL) anuncia o financiamento de 452 mil dólares para três novos projetos de segurança open source. Esses três projetos são:

  • O projeto Reproducible Builds (recebeu $200,000) que é uma ferramenta em que o usuário final pode comparar o que obtêm de uma distribuição com o que os desenvolvedores ou o gerenciador de pacotes cria.
  • Outro é o Fuzzing Project ($60,000) que é uma ferramenta common code testing approach que analisa o que acontece com as inputs de programas.
  • O terceiro ($192,000) é o False-Positive-Free Testing que tem suas raízes em código fechado. O maior objetivo desse projeto é fornecer à comunidade ferramenta novos bugs criticos para a segurança em projetos open source. Nos próximos 10 meses, a equipe de Pascal Cuoq (líder do projeto) estará trabalhando em várias comunidades oper-source para alcançar esse objetivo.
A CII continuar a focar em identificar projetos que precisam de ajuda.

4) Lançado patch de correção de emergência a vulnerabilidade Zero-day no Adobe Flahs Player que podia permitir a hackers executar códigos remotos e assumir controle da máquina infectada. Esse patch está disponível para download no próprio site da Adobe.

5) A Linux Foundation anuncia projeto Open Container Project que é feito pela união dos projetos Docker e CoreOS para padronizar runtime e formato de imagens.
O Docker ajudou muito a popularizar o uso do Linux containers como uma alternativa lightweight (peso leve) para máquinas virtuais que muitas empresa utilizam para executar múltiplas aplicações em seus servidores físicos.
Foi aí que essas duas startups deixaram de lado suas diferenças e passaram a concordar em alguns padrões. Outras empresas estão participando do projeto, como: Amazon Web Services, Apcera, Cisco, CoreOS, Docker, EMC, Fujitsu Limited, Goldman Sachs, Google, HP, Huawei, IBM, Intel, Joyent, Linux Foundation, Mesosphere, Microsoft, Pivotal, Rancher Labs, Red Hat, and VMware.
Essa é a página oficial do projeto e no Github:
Espero que gostem :-)

Benchmark de Filesystems

No meu vídeo "Filesystem (vale a pena saber?)" mencionei que iria disponibilizar uma lista de alguns teste básicos que podem ser realizados na escolha de um sistema de arquivo. Então, vamos para o arrebento e verificar o resultado do benchmark realizado.


Benchmark de sistema de arquivos


 Tudo beleza galera?
 No meu antigo blog eu cheguei a escrever um artigo sobre filesystems com o título de "Qual O Melhor Sistema de Arquivos?", tenho até uma foto com Ted T'so lá, porém acho que é um artigo que ficou incompleto e por fim desta vez fiz o vídeo para melhor abordar o assunto (ou abortar como um cara me falou semanas atras kkkkkk. Está certo que meu português não é lá essas coisas, mas convenhamos né).
 Caso ainda não tenha assistido o vídeo, ele pode ser verificado logo abaixo:





















 Como havia prometido no meu vídeo sobre "Filesystem (vale a pena saber?)" realizei alguns testes comparativos com alguns filesystems mais presentes em desktop para que todos possam saber o que cada um desses tem a oferecer. Vale repetir que realizei esses testes somente com alguns que são populares em desktop (populares não somente em desktop, mas fica entendido), mas eles podem muito bem ser realizado com qualquer filesystem (além de verificar quais resursos cada sistema de arquivo proporciona).


Para que tais testes sejam realizados, deve-se levar em consideração tudo: Seu hardware, distribuição que está sendo utilizada (não estou tratando aqui que uma é melhor do que a outra, mas tais coisas devem ser levadas em consideração).

 Então, levando tal em consideração, utilizei o seguinte:
  •  Intel Core2Duo E8400 de 3.0GHz
  •  8 Gigabytes de RAM
  •  Placa mãe ASUS (barramento 1333)
  •  Pendrive Kingston Technology DataTraveler 101 II de 8 Gigabytes.
  •  Distribuição Debian 8.1 (codenome Jessie), versão de 64 bits e a interface Mate.
  •  Os sistemas de arquivo que foram utilizados neste teste foram: Ext2/3/4, XFS, FAT e o NTFS.
  •  Utilizei dois tipos de arquivos, um grande e um pequeno. Sendo que considero aqui o arquivo grande uma imagem iso (a mesma que utilizei no vídeo) e o arquivo pequeno um arquivo odt de 188 kilobytes (padrão ODF que é um XML zipado como menciono no meu artigo "A Ameaça Que Os Arquivos Fechados Podem Causar").
  • Os comandos utilizados aqui no teste foram: wipefs (em alguns momentos para limpar a assinatura do dispositivo e evitar problemas), cfdisk ou fdisk para criação de partição no dispositivo, mkfs (para criar o sistema de arquivo a ser testado), df (para verificar o tamanho final de armazenamento da mídia removível), tune2fs -l ou dumpe2fs (para verificar a  quantidade de inodes disponíveis e o tamanhos dos blocos dos filesystems. Com esses dois comandos você pode verificar tudo sobre o sistema de arquivo), time seguido dos comandos cp/rm (para medir o tempo de gravação ou exclusão do arquivo), du (para verificar tomando do arquivo após gravação do arquivo em mídia).

 Todo os testes aqui realizados foram feitos não havendo mais nada em execução no sistema, somente um pts (um Pseudo Terminal de comandos que é invocado através da interface gráfica. Tudo deve ser levado em consideração durante um teste).

 Realizados os testes, gerei em uma planilha os seguintes resultados obtidos:

os resultados podem ser verificados a seguir.

 Podemos verificar nos resultados que cada um ofereceu uma certa vantagem em algum momento.
 Na ocupação em mídia após formatação do XFS que ficou em segundo lugar por pouco mais de 10 Mega Bytes (10236 para ser mais específico). Esses são resultados do tamanho total; ainda devemos considerar a parte do que o sistema de arquivo ocupa por sim devido aos seus recursos, como o EXT4 que ocupou pouco mais de 17 megabytes enquanto que o XFS ocupou pouco mais de 33 Megabytes.

Na parte de tamanho de blocos todos tiveram o mesmo resultado, porém essa foi uma formatação padrão. Na quantidade de inodes disponíveis todos também empataram.

No questão de tempo de gravação de arquivo (grande) em mídia (relevando que considerei um arquivo de 4.4GB como um arquivo grande nessa ocasião), o EXT4 foi o melhor, vindo a ganhar do XFS em pouco mais de 18 segundos. Ja se notarem o NTFS, ele levou absurdos (pasmem) quase 54 minutos para gravar o mesmo arquivo. Não estou brincando não e não estou tentando boicotar a Microsoft. Eu printei a tela para que possam conferir:

Esse foi o resultado do tempo de gravação do arquivo grande com o NTFS.

Fora isso, filmei o vídeo onde o pendrive estava em execução o tempo todo sendo que não havia nada em operação):





No tamanho final de arquivo o FAT foi o que apresentou menor tamanho de arquivo no final, porém isso não conta pois o FAT grava no máximo quase 4.2GB. Hoje em dia existe o ExFAT que não possui suporte a journaling, mas que permite gravação de arquivos maiores. O XFS e o NTFS foram os que apresentaram melhor aproveitamento nesta ocasião (mas mínima coisa em comparação ao EXT4. Coisa de 4K).

Na questão Tempo de remoção de arquivo (grande), o NTFS apresentou o melhor resultado que não foi lá assim grande coisa comparado ao XFS).

Passando para a o teste realizado com um arquivo pequeno (considero aqui um arquivo de 188K pequeno). No tempo de gravação de arquivo, o EXT3 apresentou o melhor resultado. No tamanho final em mídia, quase todos apresentaram o mesmo resultado (menos o EXT2 e o 3 que tiveram o arquivo do tamanho de 192K). No tempo de remoção do arquivo, todos apresentaram empate.

 A parte de remoção de arquivo em um sistema funciona da seguinte forma, quando excluímos um arquivo, o que acontece na verdade é que o sistema exclui somente seu cabeçalho. Logo o arquivo ainda está lá, porém ele fica ilegível (inacessível).
 Existe o comando lsattr em que podemos verificar os atributos dos arquivos e o comando chattr que podemos alterar esses atributos. Se alterarmos o atributo de um arquivo com opção -s no comando chattr, o comportamento de exclusão do arquivo se torna diferente, pois não é excluído somente seu cabeçalho. O que ocorre nessa ocasião é que o sistema enche o arquivo de zeros; logo ele é literalmente excluído.
 É possível ainda sim recuperar o arquivo por alguns meios, mas isso é outro assunto; o que quero notar aqui é o sistema de arquivo precisa ter esse recurso disponível para que isso seja realizado.

 Eu espero que tenham gostado e aprendido bastante. Não deixem de verificar o manual online do chattr e do lsattr:

man chattr
man lsattr

 Até a próxima. :-)

Comando fdisk do Busybox não consegue lidar com dispositivos de 8TB

Comando fdisk do Busybox não consegue lidar com dispositivos de 8TB
Comando fdisk do Busybox não consegue lidar com dispositivos de 8TB
 Em outubro de 2019 eu postei que a distribuição Puppy quirky passará a utilizar toybox, musl e clang. Com isso Barry Kauler , o criador do projeto, passou a contribuir com os projetos para que também possa beneficiar seu próprio projeto (é assim que tem que ser).

 Graças a isso, Barry e reportou a comunidade toybox para darem atenção ao seu comando fdisk pois descobriu o fdisk do Busybox não consegue lidar com dispositivos de 8TB.

 A descoberta aconteceu quando havia instalado o EasyOS em um desktop Lenovo que possui um HD do tamanho especificado e criando uma partição com sistema de arquivos ext4 de aproximadamente 6.3TB, uma fat32 de 1.3G, swap e outras pequenas ext4.

 No artigo que você pode ler na descrição, Barry explica porque particionou desta forma. Quando Barry bootou seu sistema, o comando fdisk retornou a seguinte mensagem de erro:
fdisk: Device has more than 2^32 sectors, can't use all of them
  Ao executar o comando "fdisk -l /dev/sda" é exibido informações irrelevantes e a solução foi utilizar o fidsk completo de forma estática no initrd até quue os desenvolvedores do busybox solucionem o problema (lembrando quue o fdisk completo, que vem do pacote util-linux, é do tamanho do busybox).

 Rob Landley retornou a Barry informando que o comando fdisk ainda está como pendente. Então, poderão concentrar-se nesta parte para que o fdisk do toybox não venha a ter o mesmo problema.
Mais sobre o Busybox

HAMMER 2 é melhor que o ZFS, Btrfs ou Ext4?

AqueleQueEmpunharEsteMarteloSeForDignoPossuiraOpoderDoDragonflyBSD
“Aquele que empunhar este martelo, se for digno, possuirá o poder do DragonflyBSD”.
 Durante o vídeo sobre FreeBSD ser melhor que Linux, surgiu a pergunta se o HAMMER 2 é um sistema de arquivos melhor que o ZFS, o Btrfs e o Ext4. Respondendo a essa pergunta, decidi elaborar um vídeo que assistirão aqui mesmo neste artigo.

 No Capitulo 1 Introduction - Em "What Can DragonFly Do?" é dito que:
"O HAMMER filesystem, padrão do DragonFly BSD, é o sistema de arquivos mais poderoso e mais confiável disponível em qualquer sistema operacional. Ele pode lidar com arquivos acima de um exabyte (ou 104876 tebibytes) e pode automaticamente se recuperar sem a necessidade da execução do fsck."
 Apesar de um sistema de arquivos realmente muito bom, desenvolvido e implementado em um perídio de tempo muito curto e com tamanha quantidade de recursos interessantes, eu honestamente não teria tamanha ousadia em dizer o mais poderoso e mais confiável. Apesar disso, não posso deixar de dizer que, sim, é muito poderoso e muito confiável.

 Prova disso é que há um link no próprio site do projeto intitulado Comercial que exibe seis empresas de países como Estados Unidos, Canada, Áustria, Alemanha, Itália e Reino Unido que utilizam o DragnflyBSD em ambientes de produção e para propósitos diferentes. Além das já citadas  no link do próprio site, há também um link que ficou (digamos) oculto dentro de Docs intitulado "Servidor de Backup em tempo real para clientes Microsoft Windows, Linux, Bsd  e Mac Os X" que poderia ter sido vinculado ao link anterior expondo assim melhor esse caso de sucesso.

 Trata-se de casos das empresas HIFX IT and Media Services PVT.LTD, Virtual Training Company e IPLOTZ que fazem uso do DragonflyBSD como servidor de arquivos Samba para realizar os backups de seus snapshots. Nesse link é possível conferir o cenário das empresas, o planejamento, a implantação e o resultado final que é o print abaixo:
Servidor de Backup em tempo real para cliente Microsoft Windows, Linux, Bsd e Mac Os X
Resultado da implantação do servidor de Backup em tempo real para cliente Microsoft Windows, Linux, Bsd e Mac Os X.
 Além de todos esses casos de sucesso do DragonflyBSD e do HAMMER/2 em ambientes de produção, podemos destacar também o compressor LZ4 que menciona o HAMMER como um de seus portifólios (e convenhamos, estar nessa lista ao lado do ZFS não é pouca coisa).
HAMMER 2 no site do LZ4
HAMMER 2 no site do LZ4
 OK, mostrado o máximo de qualidade e de sucesso do HAMMER /2, agora vamos ao cerne da questão. Para isso, elaborei um vídeo com informações interessantes. Confiram aí:

Lançado kernel 4.13 mesmo Linus tendo pedra nos rins

Lancado-kernel-4-13
Lançado kernel 4.13
Mesmo Linus estando com pedras no rins, isso não o impediu de lançar o kernel 4.13 alguns meses depois do lançamento do 4.12.  Linus até afirma nas notas de lançamento não ver motivos para atraso no lançamento mesmo depois deste evento passando sete horas de pura agonia que, de acordo com Linus, pareciam mais do que sete horas.

uma das mais importantes melhorias está na segurança de protocolo genérico relacionado ao comportamento do cifs.

Suporte inicial ao Intel Cannonlake e Coffeelake, correções no suporte a Vega e AMD Raven Ridge, melhorias no Thunderbolt, melhorias na integração a cpu_cooling com CPUFreq e POWER. Melhorias no F2FS que agora possui suporte a statx para aprimorar informação de arquivo. O EXT4 também possui suporte a recurso  “largedir” que lhe permite em torno de dois bilhões de entrada em um diretório comparado a dez milhões na versão anterior (caramba, os caras estão trabalhando muito do EXT4 :). XFS recebeu também aprimorações no suporte a SEEK_HOLE e SEEK_DATA.

É isso aí, por hora é só =)




Lançado Fedora 33 com o sistema de arquivos Btrfs

Lançado Fedora 33 com o sistema de arquivos Btrfs

 Hoje é um dia muito importante, o dia tão esperado do lançamento do Fedora 33 pois trata-se de um lançamento histórico onde o Fedora migrou do sistema de arquivos Ext4 para o Btrfs. Muitos novos recursos surgiram no Btrfs para atender a necessidade do Fedora (o que influenciará também no Red Hat Enterprise linux e no CentOS caso ambos também o adotem). Então acompanhe a gente hoje às 20:30 pois tenho algumas surpresas para vocês lá no canal ;)


Falar mais sobre o ext2? Por que não?

Falar mais sobre o ext2? Por que não?

 Às vésperas do lançamento do Fedora 33 tendo como a maior novidade a sua migração do sistema de arquivos ext4 para o Btrfs, eu resolvo tratar mais uma vez do ext2. Mas trata-se de um assunto  interessante e complementar ao meu vídeo anterior "" em que pediram para que eu debatesse sobre o sistema de arquivos e sobre o fato de ele utilizá-lo no /var/log.

 Então eu tratei do assunto dentro desta live. Há algumas imagens e links logo abaixo do vídeo que eu utilizei para melhor ilustrar as informações. Eu vou deixar descrito o momento exato de cada imagem e de cada link para que possa ir acompanhando ao longo do vídeo.



e2fsprogs - o pacote de ferramentas do ext2/3/4

e2fsprogs - o pacote de ferramentas do ext2/3/4
e2fsprogs - o pacote de ferramentas do ext2/3/4
 Duas coisas me motivaram a escrever este artigo. A primeira foi que esses dias eu estava analisando um comando do toybox comparando-o com outro (e que inclusive irei ensiná-lo em vídeo aulas exclusivas para patronos Toca do Tux). A segunda é que acabei descobrindo que não há nada em português sobre o pacote e2fsprogs (no máximo o que encontrei foi no site do Debian), nem mesmo a wikipedia disponibiliza o assunto em nosso idioma.

 Essa não é a primeira vez que explico vários pacotes que utilizamos nas distribuições Linux. Comecei com o artigo e vídeo  "Quatro pacotes de comandos que usamos diariamente que não são do GNU" que, como o próprio nome sugere, são pacotes com uma série de comandos que utilizamos no dia a dia e que não tem nenhuma relação com o projeto GNU (e que mesmo assim creditamos ao GNU os méritos de todos os projetos). É possível conferir neste mesmo artigo é possível conferir duas tabelas de comandos sendo uma do pacote core utils (esse sim é do GNU e passível de fácil substituição) e o outro do UtilLinux que é do próprio Linux.


 Depois disso escrevi mais um artigo mostrando o pacote Procps que é a fonte de comandos como top e ps. E por ultimo fiz mais um vídeo apresentando mais dois pacotes:


 Dado o motivo porque quero escrever este artigo, bora para o arrebento falar sobre o e2fsprogs (Ext2 Filesystem Utilities) que fornece as ferramentas necessárias para criar, corrigir, configurar e debugar os sistemas de arquivos ext2/3/4. Foi escrito (ao menos grande parte dele) por Ted T'so, criador da primeira distribuição Linux, primeiro desenvolvedor norte americano do Linux e responsável pela parte de sistema de arquivos no kernel.

 Esse pacote fornece comandos como o dumpe2fs para exibir informações sobre blocos e super blocos no sistema de arquivos, o tune2fs para modificar parametros no sistema de arquivos, o filefrag para realizar desfragmentação (pois é, se você se escandalizou com o brtfs possuir ferramenta para desfragmentar, aqui fica a dica. O ext4 possui a sua própria chamada e4defrag que foi desenvolvido por funcionários na empresa Nec),  o debugfs (o próprio nome já diz tudo e que apesar que foi desenvolvido pelo Ted, não tenho real certeza que faz parte do e2fsprogs), o badblocks para procurar por blocos defeituosos, o resize2fs para redefinir o tamanho do sistema de arquivos (também não tenho real certeza, mas pelo fato de ser escrito pelo Ted, acredito que sim) entre outros.

 Alguns comando são considerados como parte do pacte e2fsprogs, mas isso não é verdade. Os comandos blkid e findfs por exemplo fazem parte do pacote UtilLinux.

 Então, não, as ferramentas que utilizamos no Linux não são unicamente do GNU e sim de uma variedade de fontes (inclusive do próprio Linux). E não, Linux não é somente o kernel do sistema operacional (uma vez que o kernel possui carregador de boot, init system, bibliotecas como a muls, dietlibc e newlibterminal de comandos e comandos separados do terminal como viram aqui nos vários artigos, então já não se trata unicamente de um kernel).

 Aos que veemente defendem o termo "GNU/Linux" sob o argumento de que as ferramentas que utilizamos são do GNU,  Eu duvido que consigam somente com ferramentas GNU criar partições, formatá-las (e não estou falando do Gparted, pois o Gparted é apenas um frontend para os pacotes que mencionei. Link da FAQ do projeto para mais informações), montá-las, reparar o sistema de arquivos quando corromper, configurar a rede, gerenciar processos e carregar drivers modulares  (e fica aí até um desafio ;)
Ferramenta utilizadas pelo Gpaterd e que podem ser conferidas no README do seu GiLab




CLIQUE AQUI, VENHA APRENDER LINUX COMIGO E TORNE-SE UM VERDADEIRO PROFISSIONAL.
MAS TAMBÉM NÃO DEIXE DE CONFERIR O MEU CURSO DE MIGRAÇÃO PARA LINUX E TORNE-SE UM VERDADEIRO PROFISSIONAL.

Marcadores

A pior história sobre Linux que já ouvi (5) A.I (1) ambiente gráfico (15) AMD (14) analise (9) Andriod (8) artigo (5) benchmark (3) BSDs (20) btrfs (12) Caixa de Ferramentas do UNIX (19) canto do Diego Lins (2) certificações Linux (6) Código Fonte (50) comandos (17) comp (1) compressores (4) container (1) CPU (18) criptografia (2) crowdfunding (9) cursos (21) daemons (13) Debian (29) desenvolvimento (55) desktop (17) DevOps (1) DevSecOps (1) dic (1) Dica de leitura (52) dica DLins (2) dicas do Flávio (27) Dicas TechWarn (1) diocast (1) dioliunx (3) distribuições Linux (13) Docker (7) DragonflyBSD (15) ead Diolinux (2) edição de vídeo (4) EMMI Linux (4) emuladores (5) endless (5) English interview (2) Enless OS (2) entrevista (16) espaço aberto (83) evento (4) facebook (1) Fedora (4) filesystem (59) financiamento coletivo (2) fork (3) fox n forests (4) FreeBSD (12) Funtoo Linux (13) games (87) gerenciadores de pacotes (2) GOG (3) google (8) gpu (3) hardware (99) I.A (1) init system (7) Intel (15) IoT (1) ispconfig (1) jogos (33) kernel (114) lançamento (43) leis (1) LFCS (1) licenças (7) Linus (15) linus torvalds (1) Linux (188) linux foundation (3) linux para leigos (1) live (4) LPI (8) LTS (1) machine learning (1) meetup (1) mesa redonda (27) microsoft (3) microst (1) muito além do GNU (120) não viva de boatos (9) navegadores (3) NetBSD (3) novatec (17) o meu ambiente de trabalho (3) off-topic (12) open source (79) OpenBSD (3) OpenShift (1) os vários sabores de Linux (39) padrim (2) palestras e eventos (3) partições (6) pentest (6) processadores (26) professor Augusto Manzano (11) Programação (40) propagandas com Linux (8) Red Hat (13) redes (2) resenha nerd (4) Resumo da Semana do Dlins (2) resumo do Tux (19) retrospectiva Linux (1) risc-V (1) runlevel (2) Secomp (1) segurança digital (14) servidores (1) shell (1) sistema operacional (18) Software livre e de código aberto (148) sorteio (3) Steam (8) Steam no Linux (6) supercomputadores (4) suse (5) systemd (7) terminal (73) toca do tux (1) toybox (15) tutorial (6) Tux (3) unboxing (7) UNIX (15) UNIX Toolbox (14) vartroy (1) vga (1) vulnerabilidade (3) wayland (2) whatsapp (1) Windows Subsystem for Linux (1) wine (12) WoT (1) ZFS (9)