ReadyNAS Duo v2 tem desempenho lento de leitura e gravação

Question

Meu ReadyNAS Duo v2 tem velocidade lenta de leitura e gravação, apesar de estar em uma LAN gigabit. Estou usando discos 2 x 2TB Western Digital Green. Estou vendo velocidades de leitura de 3MB / seg e gravando velocidades de 1MB / seg.

Qualquer sugestão ou sugestão seria muito apreciada.

    

Answer 1

Sabe-se que as unidades Western Digital Green são afetadas por um problema chamado IDLE3, que é uma configuração de firmware que informa a unidade a estacionar a cabeça com muita frequência. Eu mudei essa configuração e notei uma melhora no meu ReadyNAS Duo v2. A velocidade de leitura aumentou de 3 MB / seg para 30 MB / seg e a velocidade de gravação de 1 MB / seg para 20 MB / seg.

Existe um programa chamado idle3ctl que pode ser usado para alterar a configuração. O mais fácil é tirar as unidades do NAS e colocá-las em um computador com Linux e alterar as configurações usando os seguintes comandos:

sudo apt-get idle3

./idle3ctl -d /dev/sda

./idle3ctl -d /dev/sdb

e desligue o NAS e ligue-o novamente.

Se você quiser alterar a configuração diretamente de dentro do próprio NAS, é um pouco mais complicado. No passado, era possível ajustar o valor IDLE3 usando estes passos . No entanto, agora que o Debian parou de suportar a versão 'Squeeze', são necessárias mais algumas etapas:

1. Ative o SSH instalando o aplicativo chamado Ativar acesso SSH raiz, disponível no site da netgear
2. SSH no seu NAS (se estiver usando o Windows, você pode usar o Putty). O nome de usuário e a senha são os mesmos que você usa para efetuar login na página da Web.

3. Verifique quantas vezes as cabeças da unidade foram estacionadas. Se é na casa dos milhares, é provável que as cabeças estão sendo estacionadas com muita freqüência (Meus valores eram em torno de 2,2 milhões).

   smartctl -A /dev/sda | grep Load_Cycle_Count

   smartctl -A /dev/sdb | grep Load_Cycle_Count

4. O NAS roda o Debian 6, chamado squeeze. Essa versão está desatualizada, então você precisa dizer ao apt-get de onde obter atualizações. Use os seguintes passos para adicionar novos valores ao /etc/apt/sources.list

   vi /etc/apt/sources.list

   press 'i' to go into insert mode, then add the following lines:

   deb http://archive.debian.org/debian squeeze main

   deb http://archive.debian.org/debian squeeze-lts main

   now press 'escape' to exit insert mode, and type ':wq' to save the file and quit vi

   Os URLs vieram de aqui

5. Instale o Aptitude, que ajuda a resolver dependências e conflitos ausentes:

   apt-get install aptitude

6. Diga ao apt-get para confiar nos pacotes de arquivo (obteve estes comandos de aqui ):

   sudo apt-get update -o Acquire::Check-Valid-Until=false

   aptitude install debian-archive-keyring

7. Atualize o apt-get

   update apt-get

8. Execute o seguinte comando para instalar o gcc. Importante - não aceite a primeira solução fornecida. O segundo é melhor porque realiza o downgrade necessário.

   aptitude install build-essential

9. Finalmente, podemos instalar o programa chamado idle3, que nos permite alterar o valor no firmware.

   cd ~

   wget https://downloads.sourceforge.net/project/idle3-tools/idle3-tools-0.9.1.tgz

10. As instruções gerais sobre como usá-lo podem ser encontradas aqui

11. Depois de baixar o tarball, por exemplo, a versão 0.9.1, descompacte:

    tar xzvf idle3-tools-0.9.1.tar.gz

12. Mude para o diretório de origem e compile a ferramenta:

    cd idle3-tools-0.9.1

    make

13. Agora você deve ter o executável idle3ctl.

    ls idle3ctl

14. Verifique a versão

    ./idle3ctl -V

15. Saiba em qual unidade aplicá-lo a:

    cat /proc/partitions

16. Se você tem duas unidades WD Green, elas provavelmente serão:

    /dev/sda

    /dev/sdb

17. Leia o valor IDLE3 usando o seguinte comando. Isso informa quantos segundos a unidade espera antes de estacionar as cabeças:

    ./idle3ctl -g105 /dev/sda

18. Para configurá-lo para 5 minutos (300 segundos), use os seguintes comandos:

    sudo ./idle3ctl -s 138 /dev/sda

    sudo ./idle3ctl -s 138 /dev/sdb

19. Na verdade, pode valer a pena desativá-lo completamente (como declarado aqui por Daniel Mauerhofer, que é funcionário da WD)

    ./idle3ctl -d /dev/sda

    ./idle3ctl -d /dev/sdb

    Eu desativei o cenário no meu e as coisas funcionam muito bem. As unidades agora são desligadas pelo software ReadyNAS, e não pela própria unidade.

20. Importante - desligue a unidade usando a página de administração normal e NÃO reinicie. Quando iniciado, o desempenho deve ser melhor.

PS. Western Digital fornece uma ferramenta para o Windows chamado wdidle3.exe que pode ser usado para alterar a configuração no Windows.

    

Answer 2

As unidades Western Digital Green não são feitas para serem usadas em um NAS. Além da configuração IDLE3, há também um recurso chamado TLER, que controla quanto tempo a unidade pode gastar para reparar erros. Em unidades NAS adequadas, essa duração é mantida baixa. O motivo é que, se uma unidade demorar muito para responder (porque está consertando um erro), o RAID pode decidir se o disco está funcionando mal e retirá-lo do RAID ou iniciar a reconstrução. Sultana faz um bom trabalho ao descrever o assunto:

As I've recently come across this very subject I can attempt to explain what most people mean by "RAID Capable".

All of Western Digital's hard drives can be placed in a RAID array, but not all of them support the features that the RE (RAID Edition) drives are capable and somewhat-better-suited for when connected to RAID controllers, whether they be full-hardware add-in cards (Adaptec, LSI, Areca, Intel PCIe and higher-end HighPoint) or onboard firmware controllers (like Intel ICHxR, SiliconImage and Marvell controllers), like Error Recovery Control and double motor head drivers.

TLER is Time-Limited Error Recovery, WD's version of Error Recovery Control (Seagates and Samsung's is called CCLT), which only really comes into play when a drive in the array comes across an error when attempting to read or write to a sector/block/page/etc. For drives on a hardware RAID controller, the controller has its own level of error recovery when attempting to rectify conflicts between the same file/block/page/sector that's supposed to be mirrored (in RAID 1) or stored in parity (in RAID 5).

When a normal desktop drive comes across a read or write error it will retry as many times as possible to read from or write to, recover and remap a bad sector/page/block/etc, sometimes taking up to a few minutes to do so. In that span of time, the RAID controller would see the harddrive as unresponsive, and conflict with the RAID controller's error recovery method and usually will drop an "unresponsive" drive from a RAID array if it takes more than the time set in the card's firmware (usually 10 seconds), even if the drive itself is still in "good health". In a simple RAID mirror, the array will go through a rebuild process which is pretty much just copying data from the undropped drive to the dropped drive to maintain a full mirror, which, when you factor in both the rebuild and reverifcation process, can take a few hours -- depending on the amount of data and the size of the drives that are mirrored. In a RAID 5 array, it can take significantly longer to rebuild.

RAID eition drives (WD's RE2/3/4s and Seagate's Constellation drives) in addition to the hardware and warranty differences, have a setting in the firmware to stop a read or write recovery operation attempt after 7 to 10 seconds, and let the RAID controller just recovery by copying the data from the other drive (in RAID 1) or from parity information (RAID 5). Even on firmware RAID controllers like Intel's onboard ICHxR ROM, the ERC timeout is 10-14 seconds, if I'm not mistaken.

That being said, certain desktop class hard drives can have error recovery control enabled using certain tools in Linux or Windows (SmartMonTools as an example) and make them better suited to use in a RAID array -- matter of fact, WD had a tool available called "TLER.exe" that actually allowed one to change the ERC setting in the drive firmware (however, it would apply the change to every WD drive the tool detected at once), but most WD Green drives (made after 2008/2009) no longer support the function in its firmware, and Seagate Barracuda drives can support enabling CCTL, but will revert back to factory firmware settings if the drives are powered down (in other words, if the system is warm restarted, the settings stick, but if one shuts down and cold-boots, then CCTL goes back to disabled -- the setting is volatile in firmware).

That said, it's the TLER/CCTL Error Recovery Control settings that sometimes make RAID edition drives not really suited for single desktop use on their own, because if they ever come across a similar read/write error, the drive will simply stop the attempt after 7 to 10 seconds, rather than keep attempting as many times as it can like regular desktop drives do.

Phrased another way, desktop drives are fine as in RAID arrays as Enterprise drives, as long as the desktop drives never encounter a read/write error or bad sector, which is an unrealistic expectation. The only instance in which it wouldn't be a problem is using the software RAID natively in Windows, as the OS is natively aware of Dynamic Disks and the mirror/stripe-with-parity configuration information as it's stored on the disk, rather than in firmware ROM or on a hardware BIOS.

Your mileage may vary, in the end, as there are people who've made RAID 5 arrays on their onboard RAID controllers (firmware-RAID) and have had no issues using regular desktop drives, and those who've created RAID 5 arrays on an LSI PCIe card with battery-backup and 256MBs onboard cache using WD RE4 drives and have had issues. RE drives fail and can take out an entire array just as easily as desktop drives in the same place depending on the type of RAID array they're configured in. In the end, it's not recommended to use desktop class drives in any array other than a simple mirror, and not supported in any case, from any known drive manufacturer.

If I'm missing anything, please feel free to chime in