Fórum Root.cz
Hlavní témata => Hardware => Téma založeno: Petr 26. 02. 2017, 13:10:37
-
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:
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:
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:
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:
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?
-
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?
-
.. 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.
-
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áž.
-
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...
-
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.
-
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.
-
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.
-
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.
-
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.
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
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í.
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í:
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:
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:
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á:
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.
-
A zkousel jste, jakou mate ryclost, kdyz zalohujete /dev/random?
-
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.
-
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
[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.
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ř.:
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í:
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:
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ů.
-
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).
-
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í:
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í:
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č?
-
Nejen u taru, ale i u dd páska prostě odmítá pracovat s blokem větším než 64kB.
Udělal jsem si archiv na disku s tím, že ho pak hodím na pásku přes dd. Postupoval jsme takto:
1. Vytvoření archivu:
# tar --totals -b 512 -cf /tmp/zaloha.tar ./TrueOS-Desktop-2016-08-24-x64-PC_BSD.iso
Total bytes written: 1694760960 (1.6GiB, 120MiB/s)
2. nastavení pásky na začátek a nastavení bloku na 256kB:
# mt -f /dev/nst0 rewind
# mt -f /dev/nst0 setblk 256kb
3. Ověření, že se vše správne nastavilo:
# mt -f /dev/nst0 status
SCSI 2 tape drive:
File number=0, block number=0, partition=0.
Tape block size 262144 bytes. Density code 0x42 (LTO-2).
Soft error count since last status=0
General status bits on (41010000):
BOT ONLINE IM_REP_EN
4. Pokus zapsat na pásku po 256kB blocích přes dd se nezdaří:
# dd if=/tmp/zaloha.tar of=/dev/nst0 bs=256k
dd: writing `/dev/nst0': Device or resource busy
1+0 records in
0+0 records out
0 bytes (0 B) copied, 4.90658 s, 0.0 kB/s
5. Přítom po 64kB blocích to jde:
# dd if=/tmp/zaloha.tar of=/dev/nst0 bs=64k
25860+0 records in
25860+0 records out
1694760960 bytes (1.7 GB) copied, 144.778 s, 11.7 MB/s
Někde tedy musí být nastavena maximální velikost bloku pro zařízení /dev/nst0
Netušíte kde?
-
A co kdybyste tedy preci jenom zkusil napaskovat kus /dev/random a zjistil rychlost a jestli paska porad zastavuje?
-
A co kdybyste tedy preci jenom zkusil napaskovat kus /dev/random a zjistil rychlost a jestli paska porad zastavuje?
/dev/random bude zastavovat. Mne dava po vycerpani maleho poolu niekde okolo 5B/s. To rychlejsie napise na klavesnici.
/dev/urandom mi dava 160MiB/s, to mam docela slusny CPU. To uz by mohlo stacit na vytazenie pasky, aj ked pri horsom CPU nikto nevie.
/dev/zero mi dava okolo 4.5GB/s, takze to by som skusil. Zase je problem s tym, ze sa to lahko komprimuje.
-
1. radic se s paskou dohodl na dostatecne rychlosti?
2. zkusil jste pouzit primo tar pro ukladani na pasku s parametrem -b, napr. -b 1024?
-
1. radic se s paskou dohodl na dostatecne rychlosti?
2. zkusil jste pouzit primo tar pro ukladani na pasku s parametrem -b, napr. -b 1024?
Omlouvam se, koukam, ze uz jste to zkousel...
-
Rychlost /dev/random je opravdu bídná. Rychlejší je /dev/urandom které dává 5,2MB/s
# dd if=/dev/urandom of=/tmp/smaz.txt count=1000000
1000000+0 records in
1000000+0 records out
512000000 bytes (512 MB) copied, 98.3409 s, 5.2 MB/s
Pro test pásky je to ale málo.
Nejrychlejší /dev/zero už na test stačí. Do /dev/null dává 539MB/s:
# dd if=/dev/zero of=/dev/null count=1000000
1000000+0 records in
1000000+0 records out
512000000 bytes (512 MB) copied, 0.949387 s, 539 MB/s
Jenže když to pošlu na pásku, tak to v podstatě ignoruje a netočí se, zřejmě protože komprese. Až nakonec na chvilku zavrčí. Výsledná rychlost rychlost je stejná, tedy kolem 11MB/s:
dd if=/dev/zero of=/dev/nst0 bs=65536 count=10000
10000+0 records in
10000+0 records out
655360000 bytes (655 MB) copied, 55.6942 s, 11.8 MB/s
Při vypnutí komprese se už páska točí, ale pořád stejně, tedy 7 vteřin jede, pak 3 vteřiny stojí a tak pořád dokola:
# mt -f /dev/st0 defcompression -1
# mt -f /dev/st0 compression off
# dd if=/dev/zero of=/dev/nst0 bs=65536 count=10000
10000+0 records in
10000+0 records out
655360000 bytes (655 MB) copied, 55.5325 s, 11.8 MB/s
Když čtu z pásky regulerní tar soubor s daty a výstup dám do /dev/null, tak páska zastavuje:
# dd if=/dev/nst0 of=/dev/null bs=65536
25859+0 records in
25859+0 records out
1694695424 bytes (1.7 GB) copied, 138.143 s, 12.3 MB/s
Když chci použít větší bloky než 64kB, tak to hodí chybu:
# dd if=/dev/nst0 of=/dev/null bs=131072
dd: reading `/dev/nst0': Device or resource busy
0+0 records in
0+0 records out
0 bytes (0 B) copied, 0.000500041 s, 0.0 kB/s
Zkusil jsem nainstalovat ovladač lin_tape od IBM, výsledek je však pořád stejný. Démon lin_taped vytvoří zařízení /dev/IBMtape0. Chování je ale identické jako u původního /dev/st0, tady neumožní větší bloky jak 64kB a páska zastavuje.
Všechno to ukazuje na omezenou rychlost sběrnice.
Zarazilo mne taky to "SCSI 2 tape drive" ve statusu mt:
# mt -f /dev/st0 status
SCSI 2 tape drive:
File number=0, block number=0, partition=0.
Tape block size 0 bytes. Density code 0x42 (LTO-2).
Soft error count since last status=0
General status bits on (41010000):
BOT ONLINE IM_REP_EN
Díval jsem se do zdrojáku mt a pokud jsem to dobře pochopil, neznamená to přímo, že by se jednalo o pomalé rozhraní SCSI 2 s propustností 10MB/s. Ono ve zdrojáku mt je jen pár možností, které to umí vypsat ("SCSI 1", "SCSI 2", "OnStream SC-, DI-, DP-, or USB", "qic-117 drive type", "IDE-Tape" a "Unknown tape drive type").
-
1. radic se s paskou dohodl na dostatecne rychlosti?
Když si při bootu přes ctrl-m vlezu do setupu raid řadiče, tak disky jsou na kanálu 0 a páska na kanálu 1. Oba kanály mají v parametru "SCSI Transfer rate" uvedeno 320M. Když si u pásky otevřu "Device identification", tak v parametru "SCSI Standard" je uvedeno SCSI-3. U disků je ve stejné položce navíc "SCSI-3 (320MB/s)". Předpokládm tedy, že řadič s mechanikou komunikuje stejně jako s disky plnou rychlostí rozhraní Ultra-320 SCSI, tedy 320MB/s. Jde to nějak ověřit v linuxu?
-
SCSI 2je v pohodě, na FC ULTRIUM LTO-5 to taky píše SCSI 2 a rychlost je OK (přes 100MB/s).