Zálohování na pásku - pomalé LTO-2

[Petr]

Mam tu starsi server Dell PE2800 s paskovou jednotkou IBM Ultrium-TD2 na LTO-2 pasky. Chtel bych ten server vyuzit k tomu, ze by zalohoval data z NASu na pasky. Poridil jsem tedy nejake nove pasky, ale zarazila mne mizerna rychlost zapisu i cteni a to i pri prenosu dat mezi paskou a lokalnim diskem. Paska se toci jen obcas, jako kdyby prenos dat vaznul nekde na sbernici.

Paska ma davat kolem 40MB/s. V realu je to ale jen kolem 0,7MB/s. Server ma radic SCSI Ultra 360. A disky (v RAID 5), ktere jsou na nem taky, maji realnou prenosovou rychlost pres 100MB/s.

Zkousel jsem ted rychlost pomoci dd a u disku to je takto:

Kód: [Vybrat]

dd if=/dev/sdc of=/dev/null bs=64k count=50000
50000+0 records in
50000+0 records out
3276800000 bytes (3.3 GB) copied, 23.2847 s, 141 MB/s

Uplne stejny priklad s paskou:

Kód: [Vybrat]

dd if=/dev/st0 of=/dev/null bs=64k count=50000
0+50000 records in
0+50000 records out
512000000 bytes (512 MB) copied, 652.731 s, 784 kB/s

Zarazil mne ten pocet prectenych bytu. Tak jsem zkusil toto:

Kód: [Vybrat]

dd if=/dev/st0 of=/dev/null bs=10240 count=50000
50000+0 records in
50000+0 records out
512000000 bytes (512 MB) copied, 274.737 s, 1.9 MB/s
Rychlost vic nez dvojnasobna, paska se casteji toci, pocet prectenych bytu tentokrat sedi.  Ale furt to neni ani zdaleka ono.

Davam jeste vypis z lsscsi:

Kód: [Vybrat]

lsscsi -l
[0:0:6:0]    process PE/PV    1x8 SCSI BP      1.0   -       
  state=running queue_depth=64 scsi_level=3 type=3 device_blocked=0 timeout=0
[0:1:6:0]    tape    IBM      ULTRIUM-TD2      3AYC  /dev/st0
  state=running queue_depth=64 scsi_level=4 type=1 device_blocked=0 timeout=900
[0:2:0:0]    disk    MegaRAID LD 0 RAID5  139G 5B2D  /dev/sda
  state=running queue_depth=64 scsi_level=3 type=0 device_blocked=0 timeout=30
[0:2:1:0]    disk    MegaRAID LD 1 RAID5  279G 5B2D  /dev/sdb
  state=running queue_depth=64 scsi_level=3 type=0 device_blocked=0 timeout=30
[0:2:2:0]    disk    MegaRAID LD 2 RAID0  286G 5B2D  /dev/sdc
  state=running queue_depth=64 scsi_level=3 type=0 device_blocked=0 timeout=30
[1:0:0:0]    cd/dvd  HL-DT-ST RW/DVD GCC-4243N A102  /dev/sr0
  state=running queue_depth=1 scsi_level=6 type=5 device_blocked=0 timeout=30


Netusite nekdo, v cem by mohl byt problem?

[Reklama]

[Petr]

Tak jsem s tím trochu pohnul nastavením větších bloků.
Při kopírování 1.6GB souboru tarem na pásku s parametrem "-b 128" se rychlost pohybuje kolem 11MB/s. Větší než 64kB bloky už nastavit nejdou. Páska teď jede tak 70% času. Ale ještě by to mělo jít nějak zrychlit, aby se páska nezastavovala.

Zálohujete ještě na pásky?

[khum]

.. nielenze neporadim, este si aj rypnem.

Nie su tie pasky drahe? Ja som sa pri LTO4 vzdy dostal na uroven ceny za GB, za ktoru si kupim pouzity HDD. Lepsie pomery boli hadam len u 2.5TB pasky, ale tam zasa bola cena mechaniky v nebeskych vysinach.

A pochybujem ze v datacentrach vyhadzuju pasky (alebo predaju výhodne), to radsej znicia aj s datami.

Pasky vyzeraju cool, ale ked som si to spocital a porovnal s HDD, tak som to nechal tak.

[Petr]

Zálohuju aktuálně 75 GB nekomprimovaných dat (smlouvy, účetnictví, zdrojáky, e-maily atd.). Po kompresi to má něco přes 34GB.

Páska má kapacitu 200GB, takže na tato nejdůležitější data (vzniklá během 8 let) je zatím dostatečně velká i s nějakým výhledem do budoucna .

Točit budu 4 pásky denní (pondělí až čtvrtek) a 4 týdenní (pátky). Celkem tedy 8 pásek. Pásky mám nové, 10 kusů (tedy 2 rezervní) a cena byla 3500,- Kč za celou sadu 10 pásek. U disků by to vyšlo asi dráž.

[aaa]

Pokud ma paska nejakou nominalni rychlost cteni/zapisu, jedna se o situaci kdy se paska nezastavuje. Pri zastaveni se musi paska pretocit kousek zpatky, nez muze pokracovat ve cteni/zapisu - coz dovede snizit rychlost prenosu o klidne rad az dva. Aby se paska nezastavovala, je potreba ji krmit dostatecne rychlym zdrojem dat/konzumovat prectena data dostatecne rychle...

[Reklama]

[Beňo]

Pokial si spominam, tak pri LTO2 bolo odporucane mat na pasku osobitny SCSI radic. Ty mas pasku na radici spolu s ostatnymi diskami, dokonca v RAID5.

Skus niekde splasit este jeden SCSI radic a dat paskovu mechaniku nan.

[pc2005]

Nepřetáčí se ta páska po zápisu? To by pak bylo jasný, kde to zdržuje (no rewind je /dev/nst0 viz devices.txt).

Jinak páska taky má taky velikost bloků někde v nastavení (mt-st asi?) a když se použije blok jiné velikosti tak to vadí mnohem víc než u disku.

[Ivan]

Zkus si o tom neco precist. Block size na pasce neni to same jako block size u partisny. Jestli k te pasce jeste existuje dokumentace, tak si zjisti jaka je doporucena block size udavana vyrobcem.

[khum]

Pásky mám nové, 10 kusů (tedy 2 rezervní) a cena byla 3500,- Kč za celou sadu 10 pásek. U disků by to vyšlo asi dráž.

Za 2200Kc mate 2TB a okamzity pristup k datam. Disk ako medium viete vlozit vsade. Ale musim priznat, ze sa na vec stale pozeram optikou "cena za GB". https://www.alza.cz/wd-blue-2000gb-64mb-cache-d2922067.htm?catid=18851840

Otazka: kde ste kupily kazety? Ja som nasiel minimalne za 600Kc.

[Petr]

Při zápisu na /dev/st0 se automaticky po jakékoli operaci přetočí na začátek (autorewind). Zařízení /dev/nst0 nepřetáčí na začátek.

Když dám třeba:
tar -b 128 -cvf /dev/nst0  dvdimage_velke_1GB.iso
tak to zapíše tou rychlostí 11MB/s, kdy páska vždy 7 vteřin jede, pak se na 3 vteřiny zastaví a tak pořád dokola, dokud se soubor neuloží.

Když nastavím přes mt velikost bloku na 64kB:
mt -f /dev/nst0 setblk 64k
není tam žádný rozdíl v rychlosti oproti výchozí automatické (nastavené na nulu).

Zkoušel jsem různé kombinace parametru -b u taru, ale je to jen pomalejší. Pří 64kB (128 bloků) je to nejrychlejší. Zkoušel jsem i kombinace různých velikostí bloku nastavených přes mt a přes tar, ale bez většího úspěchu.

Rychlost disků a řadiče doufám není problém. Mezi sebou svazky kopírují rychlostí kolem 80 MB/s.

Když přes dd pošlu větší nenakešovaný soubor z disku do /dev/null, je rychlost 119 MB/s.

Kód: [Vybrat]

dd if=TrueOS-Desktop-2016-08-24-x64-PC_BSD.iso of=/dev/null
3309900+0 records in
3309900+0 records out
1694668800 bytes (1.7 GB) copied, 14.292 s, 119 MB/s

Když to udělám hned znovu, čte se jen z keše a rychlost dd do /dev/null je přes 420MB/s

Kód: [Vybrat]

dd if=TrueOS-Desktop-2016-08-24-x64-PC_BSD.iso of=/dev/null
3309900+0 records in
3309900+0 records out
1694668800 bytes (1.7 GB) copied, 4.02576 s, 421 MB/s

Pokud stejný soubor pošlu tarem na pásku (čte se zase z keše), tak se to vleče něco málo přes 11MB/s a páska 30% času stojí.

Kód: [Vybrat]

date; tar -b 128 -cf /dev/nst0 ./TrueOS-Desktop-2016-08-24-x64-PC_BSD.iso ; date
Mon Feb 27 11:00:04 CET 2017
Mon Feb 27 11:02:34 CET 2017

Během zápisu se ale systém nudí:

Kód: [Vybrat]

top - 11:01:35 up 15 min,  2 users,  load average: 0.82, 0.53, 0.39
Tasks: 266 total,   1 running, 265 sleeping,   0 stopped,   0 zombie
Cpu(s):  0.4%us,  1.2%sy,  0.0%ni, 98.3%id,  0.0%wa,  0.0%hi,  0.0%si,  0.0%st
Mem:   8058696k total,  2463000k used,  5595696k free,    42424k buffers
Swap:  2047992k total,        0k used,  2047992k free,  1910920k cached

  PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND           
   78 root      39  19     0    0    0 S  2.3  0.0   0:36.62 kipmi0             
 3412 root      20   0  113m 1176  944 D  1.3  0.0   0:00.98 tar               
 3099 petr      20   0  294m  12m 8988 S  0.7  0.2   0:01.25 gnome-terminal     
 2121 root      20   0  210m  17m 1080 S  0.3  0.2   0:02.70 xrdp               
 2710 petr      20   0  147m  50m 6256 S  0.3  0.6   0:03.56 Xvnc               
 3455 root      20   0 15168 1328  904 R  0.3  0.0   0:00.05 top               
    1 root      20   0 19356 1496 1188 S  0.0  0.0   0:01.75 init               
    2 root      20   0     0    0    0 S  0.0  0.0   0:00.01 kthreadd           
    3 root      RT   0     0    0    0 S  0.0  0.0   0:00.07 migration/0       
    4 root      20   0     0    0    0 S  0.0  0.0   0:00.00 ksoftirqd/0       
    5 root      RT   0     0    0    0 S  0.0  0.0   0:00.00 migration/0       
    6 root      RT   0     0    0    0 S  0.0  0.0   0:00.00 watchdog/0         
    7 root      RT   0     0    0    0 S  0.0  0.0   0:00.16 migration/1       
    8 root      RT   0     0    0    0 S  0.0  0.0   0:00.00 migration/1       
    9 root      20   0     0    0    0 S  0.0  0.0   0:00.00 ksoftirqd/1       
   10 root      RT   0     0    0    0 S  0.0  0.0   0:00.00 watchdog/1         
   11 root      RT   0     0    0    0 S  0.0  0.0   0:00.14 migration/2       

Nastavení velikosti bloku přes mt na 64k (což odpovídá -b 128 u taru) nemá vliv:

Kód: [Vybrat]

mt -f /dev/nst0 setblk 64k
date; tar -b 128 -cf /dev/nst0 ./TrueOS-Desktop-2016-08-24-x64-PC_BSD.iso ; date
Mon Feb 27 11:08:09 CET 2017
Mon Feb 27 11:10:35 CET 2017

Menší bloky to jen zhoršují. Viz zde nastaveno 32k:

Kód: [Vybrat]

mt -f /dev/nst0 setblk 32k
date; tar -b 64 -cf /dev/nst0 ./TrueOS-Desktop-2016-08-24-x64-PC_BSD.iso ; date
Mon Feb 27 11:12:01 CET 2017
Mon Feb 27 11:16:38 CET 2017

Zkoušeno až do nejmenšího možného 8kB bloku, kdy to zapisuje desetinovou rychlostí oproti 64kB.

Víc jak 64kB se nastavit nedá:

Kód: [Vybrat]

mt -f /dev/nst0 setblk 128k
date; tar -b 256 -cf /dev/nst0 ./TrueOS-Desktop-2016-08-24-x64-PC_BSD.iso ; date
Mon Feb 27 11:18:51 CET 2017
tar: /dev/nst0: Cannot write: Device or resource busy
tar: Error is not recoverable: exiting now
Mon Feb 27 11:18:57 CET 2017

Pořád si ale myslím, že dělám něco blbě, nebo mám někde něco blbě nastaveno. Takže budu rád za každou radu.

[JardaP .]

A zkousel jste, jakou mate ryclost, kdyz zalohujete /dev/random?

[Ivan]

A co /proc/scsi ? Nekde by melo byt napsano jakou "linkovou rychlost" si ta paska dohodla na urovni SCSI.

- LTO-* pasky maji buffer do ktereho se zapisuje. Pokud se ten buffer vyprazdni, paska se zastavi
- Prvni generace LTO se neumely zpomalit, pokud uzivatel posilal malo dat. Opakovane rozjizdeni a zastavovani ty mechaniky spolehlive zabilo. Tenhle problem dokonce dostal nejake vlastni jmeno
- Pokud data zazalohujete s urcitou block size, tak je s nejvetsi pravdepodobnosti neprectete s jinou block size. Tzn. neni to jako u disku. Nejlepe je pouzit block size udavanou vyrobcem.
- krome generickeho ovladace st pro pasky, je mozne nekde sehnat i closed-source ovladac primo od vyrobce LTO. K tomu existuji i nejake diagnosticke nastroje.

[Petr]

Ano, ten problém zastavování a rozjíždění pásky je označován jako "shoe shining".

Přes lscsci -lll dostanu tyto parametry

Kód: [Vybrat]

[0:1:6:0]    tape    IBM      ULTRIUM-TD2      3AYC  /dev/st0
  device_blocked=0
  iocounterbits=32
  iodone_cnt=0xf
  ioerr_cnt=0x4
  iorequest_cnt=0xf
  queue_depth=64
  queue_type=none
  scsi_level=4
  state=running
  timeout=900
  type=1

Na webu jsem našel, že optimální velikost bloku pro LTO2 je 16kB. Ale to u mě moc dobré výsledky nedává. Rychlost spadne zhruba na 3MB/s a páska se točí jen tak 20% času, možná ani ne. Kdežto u 64kb bloků je to těch dříve uváděných 11MB/s.

Kód: [Vybrat]

mt -f /dev/nst0 seod
mt -f /dev/nst0 setblk 16kb
date; tar -b 32 -cf /dev/nst0 ./TrueOS-Desktop-2016-08-24-x64-PC_BSD.iso ; date
Mon Feb 27 14:31:50 CET 2017
Mon Feb 27 14:40:54 CET 2017

Nutnost stejných bloků u zálohy a následného čtení chápu. Když bych tarem četl data vytvořená s jinou velikostí bloku, dostanu pochopitelně chybu "tar: /dev/nst0: Cannot read: Input/output error".

Když nastavím jinou velikost bloku přes mt, než pak dám taru přes parametr -b, vrátí chybu - např.:

Kód: [Vybrat]

mt -f /dev/nst0 setblk 64kb
tar -b 32 -cf /dev/nst0 ./TrueOS-Desktop-2016-08-24-x64-PC_BSD.iso
tar: /dev/nst0: Cannot write: Invalid argument
tar: Error is not recoverable: exiting now

S tím problém nemám a chápu, že velikost bloku nastavená mezi mt a tarem musí sedět, stejně jako zálohu uloženou s určitu velikosti bloku musím číst se stejným nastavením. Jinak to ani nejde.

Já spíš bojuju s tím, že čtení i zápis by měly být výrazně rychlejší než těch 11MB/s, kterých dosahuji teď. Navíc se "shoe shining" projevuje i u čtení:

Kód: [Vybrat]

mt -f /dev/nst0 setblk 64kb
mt -f /dev/nst0 rewind
date; tar -b 128 -cf /dev/nst0 ./TrueOS-Desktop-2016-08-24-x64-PC_BSD.iso ; date
Mon Feb 27 14:52:53 CET 2017
Mon Feb 27 14:55:22 CET 2017
cd /tmp
mt -f /dev/nst0 rewind
date; tar -b 128 -xf /dev/nst0 ; date
Mon Feb 27 15:05:48 CET 2017
Mon Feb 27 15:08:21 CET 2017

Na ukázce výše je vidět, že soubor se zapsal na pásku za 2:29 a čtení trvalo 2:33.
Čtení je stejně pomalé jako zápis. Při nastavení jiné velikosti bloku než 64kB (zápis i čtení, mt i tar) je to ještě horší. Takže rychlost plnění buferru při zápisu asi nebude problém.

Problém bude ve velikosti bloku. Potřeboval bych se dostat nad těch 64kB. Příkaz mt s tím nemá problém, ale tar zařve chybu:

Kód: [Vybrat]

mt -f /dev/nst0 rewind
mt -f /dev/nst0 setblk 128kb
tar -b 256 -cf /dev/nst0 ./TrueOS-Desktop-2016-08-24-x64-PC_BSD.iso
tar: /dev/nst0: Cannot write: Device or resource busy
tar: Error is not recoverable: exiting now

Příkaz mt nemá s větším blokem problém (nebo alespoň nepíše žádnou chybu ani při 1MB). Ale tar odmítá větší blocking-factor než 128 (*512b = 64kB). Takže zkusím zapátrat, jak donutit tar pracovat s větším počtem bloků.

[xxx]

LTO2 si uz presne nepamatuju, ale s LTO3,4,5 atd mam zkusenosti. Vzdy davame block size 256kB - pro NetBackup ale i jiny sw. Mene je pomalejsi a vice neni lepsi.

Zkuste si zalohu /dev/zero do LTO a taky vasi zalohu do /dev/null. Z toho uvidite , co vase zarizeni muze dosahnout. Pokud zalohujete i po siti, tak je dulezite mit dobre nastaveno flow control a taky buffer size u karty (Intel 1Gb nebo 10Gb adaptery).

[Petr]

Vyzkouším.

Ale ještě jsem narazil na jednu věc, kterou úplně nechápu. Přes mt nastavím velikost bloku třeba na 512kb, ale tar tam zapsat neumí:

Kód: [Vybrat]

mt -f /dev/nst0 setblk 512kb
mt -f /dev/nst0 status
SCSI 2 tape drive:
File number=0, block number=0, partition=0.
Tape block size 524288 bytes. Density code 0x42 (LTO-2).
Soft error count since last status=0
General status bits on (41010000):
 BOT ONLINE IM_REP_EN

tar --totals -b 1024 -cf /dev/nst0 TrueOS-Desktop-2016-08-24-x64-PC_BSD.iso
Total bytes written: 0 (0B, ?/s)
tar: /dev/nst0: Cannot write: Device or resource busy
tar: Error is not recoverable: exiting now

Přitom do normálního souboru tar s takto nastaveným blocking-factorem zapsat umí:

Kód: [Vybrat]

tar --totals -b 1024 -cf  /tmp/soubor.tar  ./TrueOS-Desktop-2016-08-24-x64-PC_BSD.iso
Total bytes written: 1695023104 (1.6GiB, 311MiB/s)

Problém bude tedy ten, že když se dá taru jako cílové zařízení pásková mechanika, zapisuje maximálně 128 bloků. Netušíte proč?