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.

Comente com o Facebook:

Nenhum comentário:

Postar um comentário

Viu algum erro e quer compartilhar seu conhecimento? então comente aí.

Observação: somente um membro deste blog pode postar um comentário.

Marcadores

A pior história sobre Linux que já ouvi (5) A.I (2) ambiente gráfico (19) AMD (14) analise (10) Andriod (16) android (7) Apple (1) arm (5) artigo (5) aws (1) bc (23) benchmark (6) BetrFS (1) blackhat (1) BSDs (30) btrfs (32) bugs (2) Caixa de Ferramentas do UNIX (19) canto do Diego Lins (2) certificações Linux (7) Código Fonte (54) comandos (31) comp (1) compressores (5) container (7) CPU (19) cracker (1) criptografia (5) crowdfunding (9) cursos (24) daemons (13) Debian (31) desempenho (1) desenvolvimento (90) desktop (19) DevOps (3) DevSecOps (4) dic (1) Dica de leitura (90) dica DLins (2) dicas do Flávio (27) Dicas TechWarn (1) diet libc (3) diocast (1) dioliunx (3) distribuições Linux (14) Docker (12) DragonflyBSD (22) driver (1) ead Diolinux (2) edição de vídeo (5) embarcados (1) EMMI Linux (4) emuladores (9) endless (5) English interview (3) Enless OS (2) entrevista (17) espaço aberto (82) evento (6) facebook (1) Fedora (11) filesystem (82) financiamento coletivo (2) fork (4) fox n forests (4) FreeBSD (20) Funtoo Linux (13) games (94) gerenciadores de pacotes (4) glaucus (3) GOG (3) google (9) gpu (3) hacker (2) hardware (104) hash (1) helenos (3) I.A (1) init system (11) Intel (15) inteligencia artificial (2) IoT (1) ispconfig (1) jogos (38) kde (1) kernel (138) lançamento (64) leis (1) LFCS (1) libs (2) licenças (8) Linus (16) linus torvalds (2) Linux (194) linux foundation (3) linux para leigos (1) live (5) LPI (8) LTS (1) Mac (1) machine learning (1) matemática (9) mesa redonda (27) microcontroladores (1) microsoft (6) microst (1) muito além do GNU (165) musl (3) não viva de boatos (9) navegadores (5) NetBSD (7) newlib (1) nim (1) nintendo (1) novatec (17) novidades (1) nuvem (1) o meu ambiente de trabalho (3) off-topic (12) open source (84) OpenBSD (7) OpenShift (1) oracle (1) os vários sabores de Linux (43) padrim (2) palestras e eventos (5) partições (6) pentest (8) performance (1) pipewire (1) plan9 (1) playstation (1) processadores (30) professor Augusto Manzano (11) Programação (64) promoção (1) propagandas com Linux (8) ps4 (1) real-time. (1) Red Hat (23) redes (4) resenha nerd (4) Resumo da Semana do Dlins (2) resumo do Tux (19) retrospectiva Linux (1) risc-V (14) RISCV (13) rtos (1) runlevel (2) rust (12) segurança digital (24) servidor web (2) servidores (2) shell (9) shell script (8) sistema operacional (25) skarnet (1) smartphones (3) Software livre e de código aberto (151) sorteio (3) Steam (10) Steam no Linux (8) supercomputadores (4) suse (6) systemd (7) terminal (89) terminal de comandos (18) toca do tux (1) toybox (27) tutorial (6) Tux (3) unboxing (7) UNIX (17) UNIX Toolbox (14) vartroy (1) vga (1) virtualização (2) vulnerabilidade (6) wayland (5) web (1) whatsapp (1) whitehat (1) Windows Subsystem for Linux (2) wine (14) WoT (1) yash (1) ZFS (15) zsh (3)