LusoRobótica - Robótica em Português
Sistemas específicos => ARM => Raspberry Pi => Tópico iniciado por: Tayeb em 05 de Junho de 2015, 11:52
-
Já teve a má experiência (e uma dor de cabeça!) de corrupção do cartão SD do seu Raspberry Pi. A solução é simples, deve clonar o cartão SD e ter uma imagem de reserva. O link seguinte mostra como se faz:
http://lifehacker.com/how-to-clone-your-raspberry-pi-sd-card-for-super-easy-r-1261113524 (http://lifehacker.com/how-to-clone-your-raspberry-pi-sd-card-for-super-easy-r-1261113524)
Penso que deve interessar esta simples informação.
-
sudo dd if=/dev/sdd of=./sdcard.img
Mais simples que isto é dificil. :P
-
Assumindo que o cartão é lido em OS Windows uma das soluções é a que apresentei.
Um melhor comando para OSX será:
backup:
dd if=/dev/sdb of=sdcard.img bs=4M
restauração:
dd if=sdcard.img of=/dev/sdb bs=4M
Isto para ser mais rápida a criação da imagem e a restauração
-
@Tayeb: Porque tera ficado o cartao corrumpido? Excesso de escritas?
-
@Tayeb: Porque tera ficado o cartao corrumpido? Excesso de escritas?
Várias razões. Desligar enquanto se está a efetuar escrita, extremo overclock (executar o processador acima da frequência) e é claro a qualidade do cartão SD.
-
Assumindo que o cartão é lido em OS Windows uma das soluções é a que apresentei.
Um melhor comando para OSX será:
backup:
dd if=/dev/sdb of=sdcard.img bs=4M
restauração:
dd if=sdcard.img of=/dev/sdb bs=4M
Isto para ser mais rápida a criação da imagem e a restauração
Quando estás a efectuar o backup precisas mesmo do, bs=4M ?
Custumo usar bs=4M quando escrevo .iso para pen USB, mas pensei que para o backup do SD card para o disco não seria preciso,
podes confirmar ?
-
O tamanho do bloco é importante porque a transferência é mais rápida. Tem efeito somente sobre o tamanho de transferência.
-
Os cartões de memória "vão-se embora" porque basicamente não têm qualquer mecanismo de wear leveling como as drives SSD.
A maioria das escritas ainda por cima concentram-se nos inodes dos ficheiros e diretorias o que significa que de repente certas diretorias ou ficheiros deixam de estar acessíveis.
Sei disto porque tenho (ainda) um servidor NSLU2 que usou durante muito tempo um cartão de memória, e mesmo com o file-system "mounted" com a opção noatime, que desliga a opção de update dos inodes em relação á data e hora de acesso, e mesmo assim foi-se a directoria /etc e /var/log....
É claro o cartão que tem de ir para o lixo....
Agora está o NSLU2 está com uma PEN USB recente, que potencialmente pode ter internamente algum mecanismo de wear leveling. Garantidamente só um SSD tem essa opção, e já há SSD's na casa dos 16GB/20G na ordem dos 40€, mas é o mesmo preço que o Rpi....
Por isso backups, backups e mais backups.
-
Têm wear leveling sim, é feito internamente pelo micro que está no cartão, simplesmente deixas de ter blocos para re-alocar e acabou-se o wear leveling, tipicamente os controladores trancam os cartões e ficam em modo só de leitura.
Uma Flash eMMC era mil vezes melhor que um cartão SD, ou então meter um SSD iCache de 24-32GB que andam nos 10€, só que falam SATA..
-
Em relação aos emmc, um dos motivos pelo qual tenho um Odroid e não um Rpi é esse. É que os Odroid suportam emmc, quee é o que tenho neste momento, exatamente pela má experiência com sd cards.
-
Em relação aos emmc, um dos motivos pelo qual tenho um Odroid e não um Rpi é esse. É que os Odroid suportam emmc, quee é o que tenho neste momento, exatamente pela má experiência com sd cards.
Então se "wear level" é a causa como é que a Sandisk dá garantia de 5 anos nos seus cartões e até "lifetime"?
https://www.sandisk.com/about/legal/warranty/warranty-table (https://www.sandisk.com/about/legal/warranty/warranty-table)
Os cartões não ficam danificados. O que acontece é que os dados ficam corrompidos, incluindo o fato de não deixarem arrancar o OS. Basta reformatar o cartão e repôr os dados para que fique a funcionar.
-
Potque não são feitos para serem martelados por um SO a correr neles.
-
Tenho 2 amigos a usar RasPI.
Um teve imensos problemas com cartões corrompidos, acontece (ou pode acontecer) se desligares o power ao PI sem fazer o shutdown do Linux. Acabou por ter que fazer o filesystem read-only. Aparentemente é um problema conhecido com o RasPI.
O outro nunca teve um único problema com isso, e desliga o power à bruta.
-
Mas todos os sdcards podem ser recuperados bastando formatá-los ou é só os da scan disc(ou alguns)?
-
Em relação aos emmc, um dos motivos pelo qual tenho um Odroid e não um Rpi é esse. É que os Odroid suportam emmc, quee é o que tenho neste momento, exatamente pela má experiência com sd cards.
Então se "wear level" é a causa como é que a Sandisk dá garantia de 5 anos nos seus cartões e até "lifetime"?
https://www.sandisk.com/about/legal/warranty/warranty-table (https://www.sandisk.com/about/legal/warranty/warranty-table)
Os cartões não ficam danificados. O que acontece é que os dados ficam corrompidos, incluindo o fato de não deixarem arrancar o OS. Basta reformatar o cartão e repôr os dados para que fique a funcionar.
Mas nesse caso já será corrupção do file-system e não problemas do hardware, digo eu.
Em relação às garantias, é a tal coisa, eles garantem que por exemplo podes escrever e ler sem problemas, vamos supor, 2TB, o que num cartão de 16GB para uso normal, como uma máquina fotográfica é uma vida....
Agora com um sistema operativo a "matraquear" o cartão, em princípio não dura uma vida, mas ainda se aguenta uns anos valentes. O cartão que eu tinha morreu ao fim de 4 e num sistema praticamente sem uso... (só rsync para disco rigido normal).
Um artigo interessante: http://techreport.com/review/27909/the-ssd-endurance-experiment-theyre-all-dead (http://techreport.com/review/27909/the-ssd-endurance-experiment-theyre-all-dead)
-
Mas todos os sdcards podem ser recuperados bastando formatá-los ou é só os da scan disc(ou alguns)?
Depende do tipo de falha. Se for lógica, tipo file system corrompido, um e2fsck ou um chkdsk (lol) pode resolver o problema.
Agora se for mesmo o hardware do cartão, esquece. Como o Senso referiu, quando acabarem os sectores de re alocação, mesmo formatando que assinala os "bad sectors", é mais do que provável que apareçam mais nesse estado.
-
O problema conhecido do RasPI com os cartões corrompidos ao desligar o power é só dados, o filesystem fica incoerente. Para recuperar é voltar a instalar um sistema novo no cartão, não é avaria de hardware.
-
O meu unico problema tem sido com o restore para cartões de marcas e mesmo modelos diferentes...
As imagens têm tamanhos diferentes e as coisas ja não funcionam...
Assumindo que o cartão é lido em OS Windows uma das soluções é a que apresentei.
Um melhor comando para OSX será:
backup:
dd if=/dev/sdb of=sdcard.img bs=4M
restauração:
dd if=sdcard.img of=/dev/sdb bs=4M
Isto para ser mais rápida a criação da imagem e a restauração
o parametro bs=4M funciona com vocês?
Aqui dá erro.
Mac-Chris:Home HD Cristiano$ sudo dd if=RaspberryPi.img of=/dev/rdisk3 bs=4M
dd: bs: illegal numeric value
Se for bs=5m já funciona!
-
Estranho. E funciona?
A opção bs=4M significa que o backup se faz em blocos de 4M isto é 4096. Normalmente quando isso dá erro muda-se o valor para 1M isto é 1024. Parece que o valor 5 é errado. Com 1M o tempo de backup será maior devido ao tamanho do bloco.
-
Funciona, com o 5m. De resto experimentei com 1M e 4M e não me o erro em o mesmo.
Estou a usar Mac.
É a dica do campo 5m vi aqui: http://computers.tutsplus.com/articles/how-to-clone-raspberry-pi-sd-cards-using-the-command-line-in-os-x--mac-59911
(Nos comentários)
Agora também ando aqui na luta com o tamanho da partição. Queria fazer um resize para diminuir o tamanho dela. Tendo e, conta que dá maneira como está, não consigo copiar esta imagem para lado nenhum.
-
Continuei a procurar e não encontro grande explicação para a diferença entre o 4M 4m 5M e 5m...
Cenas :/
-
mas os sdcards nao tem todas a mm base quer sejam duma marca ou doutra? (isto sem diferenciar cartoes de classes diferentes)
agora tb tem aparecido a informação de UHS-I (1) que nomenclatura é esta e o que significa?