Schijven raar gedrag bij recovery na onder water

[bucovaina89]

Ik ben 2 schijven (mdadm RAID1) aan het restoren van een vriend die in een WD mirror nas hebben gestoken. Die hebben onder een waterlek gestaan met letterlijk een straal water over de NAS. Wonder boven wonder werken de schijven en heb ik volgens mij alle data op een externe schijf kunnen krijgen.

Nu was ik voor de fun nog alles op tape aan het schrijven om een echte backup te kunnen mee geven (tweaker zijnde) en nu merk ik plots erg raar gedrag, de backup gaat su-per traag. De drive staat meer stil dan wat anders en om de 2-3 seconden kan hij een jpeg tarren. Als ik naar de statistics van de schijven ga zien, zie ik 100% reads op beide schijven:



Er zit dus een enorme discrepantie op wat hij leest (300MB/s) en wat hij schrijft fluctueert het van 0-~10MB/s

De backup drive is een LTO-4 drive met LTO-3 tapes. Stel dat de tape de bottleneck was geweest, zag ik geen hoge reads hier. De theoretische max zou nu 80MB/s moeten zijn door LTO-3.

Volgens mij hebben de schijven toch een 'trek' gehad, maar wat is die 100% reads? Heeft iemand dit exacte gedrag ooit effectief gezien en weet wat hier gebeurt?

EDIT: kleine update, mdadm is de drive array aan het checken. Dat lijkt me al erg logisch dat die veel resources inneemt en dat de backup relatief traag gaat. Ik vermoed dat mdadm een hoge prioriteit gaat krijgen. Ik wacht ff tot die klaar is en probeer dan nog eens.

code:

root@tapews:~# mdadm -D /dev/md126
/dev/md126:
           Version : 1.0
     Creation Time : Thu Jun  4 23:15:38 2015
        Raid Level : raid1
        Array Size : 2926070648 (2790.52 GiB 2996.30 GB)
     Used Dev Size : 2926070648 (2790.52 GiB 2996.30 GB)
      Raid Devices : 2
     Total Devices : 2
       Persistence : Superblock is persistent

     Intent Bitmap : Internal

       Update Time : Sun Jun  6 07:15:09 2021
             State : clean, checking 
    Active Devices : 2
   Working Devices : 2
    Failed Devices : 0
     Spare Devices : 0

Consistency Policy : bitmap

      Check Status : 89% complete

              Name : 1
              UUID : b362427d:a0a687e5:45690c09:67dbadc7
            Events : 6

    Number   Major   Minor   RaidDevice State
       0       8       18        0      active sync   /dev/sdb2
       1       8       34        1      active sync   /dev/sdc2
root@tapews:~#

[ Voor 29% gewijzigd door bucovaina89 op 06-06-2021 07:17 ]

[sh4d0wman]

Hoe restore je? Normaal trek je alle data naar een disk of NAS. Wanneer dat klaar is trek je de defecte schijven er uit en test je of data allemaal leesbaar is. Daarna maak je eventueel een kopieslag naar tape dus vanaf een stel goede schijven of NAS.

Je beschrijving doet mij vermoeden dat je nu van de mogelijk defecte schijven gelijk naar tape gaat. En inderdaad als er nog andere acties lopen kan het traag gaan

[Thralas]

Doe de volgende keer ook 'echte' datarecovery door de disks eerst te imagen (met ddrescue) naar een betrouwbaar (random access) medium.

Misschien dat het nu goed gaat omdat de schijven fysiek in orde blijken, maar anders voorkom je daarmee dat een schijf bijvoorbeeld herhaaldelijk op dezelfde bad sectors hangt.

[DeBolle]

bucovaina89 schreef op zondag 6 juni 2021 @ 07:09:
De backup drive is een LTO-4 drive met LTO-3 tapes. Stel dat de tape de bottleneck was geweest, zag ik geen hoge reads hier. De theoretische max zou nu 80MB/s moeten zijn door LTO-3.

Pakweg twintig jaren geleden leverde dit al problemen op. In het kort: een LTO-4 drive kan zoveel data opslokken dat het hele storage subsystem wordt gemonopoliseert. Daarnaast zal de drive telkens moeten wachten tot er weer wat binnenkomt en gaan 'shoe-shinen' met de tape.

Zorg dat het hele path van disk tot en met de connector op de tapedrive de bandbreedte aan kan, wat in de praktijk neer komt op ongeveer 240 MB/sec (incl compressie op de drive).

Daar heb je een U320 SCSI verbinding voor nodig, of een > 4Gbit FC.
Deze praktijkcijfers (uit 2006) heb ik voor LTO-3 tapes gemeten in situaties bij toenmalige klanten, op een verscheidenheid van HP en IBM drives.

[bucovaina89]

Het was uiteindelijk wel degelijk de mdadm die een consistency check aan het doen was (die overigens 100% OK was). Na de consistency check, ging de tape plots wel naar de verwachte snelheid en waren de reads (van de schijven) en writes (naar tape) in balans

@Thralas : Uiteindelijk is het goed gekomen maar ie ddrescue had ik inderdaad beter als allereerste gedaan, dat ik daar niet aan gedacht had! Mocht er iets mis geweest zijn met de schijven had ik er waarschijnlijk toch iets meer af kunnen halen.

[Ben(V)]

Het is waarschijnlijk de combinatie van wat @DeBolle zei en mdadm die druk was.

Doordat mdadm nog druk was met zijn consistency check kon er niet snel genoeg data aangevoerd worden om die LTO in streaming mode te houden en valt die terug naar start-stop mode.
En start-stop mode van een LTO is rete traag.

[bucovaina89]

[b]Ben(V) in "Schijven raar gedrag bij recovery na onder water"
En start-stop mode van een LTO is rete traag.

Idd, met LTO ben ik bekend . Heb inderdaad lang moeten experimenteren om LTO in streaming mode te krijgen. Maar wat ik op momenten van shoe shining zag, was dat de reads van schijven ook in elkaar doken. Nu was dat niet het geval. mdadm gebruik ik zelden of nooit en was me niet bewust dat die wekelijks op zondag een consistency check ging doen.

Weer wat bij geleerd