Очень низкая скорость чтения с ленты LTO6 в Linux CentOS
Centos использует другое имя пакета. Имя пакета Debian/Ubuntu — libcurl4-openssl-dev. Однако libcurl-develв CentOS предоставляет те же файлы и даже больше. Попробуйте вместо этого:
sudo yum install libcurl-devel
Кроме того, вы можете искать доступные пакеты, как в этом примере:
yum search libcurl
Хорошо, наконец-то мне удалось добиться приличной скорости при сбросе ленты. Процедура, которую я сейчас использую, в основном основана на использовании блоков разного размера для разных частей ленты. В настоящее время я читаю первые 2 КБ ленты с размером блока 64 КБ, затем переключаюсь на 65 КБ (странно, я знаю )для пары блоков (, протестированных с 400 ). После этого переключитесь обратно на 64 КБ, пока эта команда не появится автоматически с dd: error reading '/dev/nst0': Cannot allocate memory. В этот момент читаются первые 4 ГБ ленты.
Для оставшейся части ленты я могу вернуться к размеру блока 65 КБ, и тогда скорости будут приличными (~100 МБ/с ). Когда я разбираю данные на ленте, я вижу, что каждый блок размером 64 КБ кажется «заполнением» в 1 КБ, поэтому размер блока 65 КБ может быть не таким уж странным в использовании.
[root@tapepoc TapeBlobExtractor]# dd if=/dev/nst0 of=/tape_dump/tape_1.dump bs=64k
dd: error reading '/dev/nst0': Cannot allocate memory
0+2 records in
0+2 records out
2048 bytes (2.0 kB, 2.0 KiB) copied, 3.28837 s, 0.6 kB/s
[root@tapepoc TapeBlobExtractor]# dd if=/dev/nst0 of=/tape_dump/tape_2.dump bs=65k count=400
dd: warning: partial read (7168 bytes); suggest iflag=fullblock
11+389 records in
11+389 records out
26167296 bytes (26 MB, 25 MiB) copied, 5.26119 s, 5.0 MB/s
[root@tapepoc TapeBlobExtractor]# dd if=/dev/nst0 of=/tape_dump/tape_3.dump bs=64k
dd: error reading '/dev/nst0': Cannot allocate memory
60413+4 records in
60413+4 records out
3959387136 bytes (4.0 GB, 3.7 GiB) copied, 17.4649 s, 227 MB/s
[root@tapepoc TapeBlobExtractor]# dd if=/dev/nst0 of=/tape_dump/tape_4.dump bs=65k
^C1024568+19746 records in
1024568+19746 records out
68377951232 bytes (68 GB, 64 GiB) copied, 641.83 s, 107 MB/s
Прежде чем предпринимать какие-либо действия, я бы порекомендовал несколько диагностических тестов, чтобы выявить проблемы.
Ленточный накопитель замедляется из-за проблем, связанных с приводом -, таких как износ -головки, проблемы с направляющими роликами и проблемы с двигателем. Причина в том, что накопитель повторяет процесс чтения при высокой частоте ошибок. Ленточный накопитель также замедляет работу из-за проблем, связанных с носителем -, таких как дефекты, повреждение краев и мусор на поверхности. Узкое место вокруг вашей системы, такое как диск, PCIe, HBA и кабели, также может быть причиной. Таким образом, вы должны изолировать проблему, чтобы сделать правильное действие.
IBM ITDT позволяет нам провести соответствующий диагностический тест. Особенно в этом случае будет полезен «Тест системы». Системный тест представляет собой короткий диагностический тест и показывает скорость передачи в результате с различным размером блока и с/без аппаратного сжатия. Для этого теста следует использовать совершенно новый носитель, так как он стирает данные.
Если скорость передачи без сжатия -не соответствует спецификации (= 160 МБ/с ), причиной является проблема с накопителем, так как вы использовали совершенно новую ленту. Кроме того, сжатая скорость передачи выявляет ограничения полосы пропускания, вызванные системой, кабелем или HBA.
Этот тест включает в себя очень короткую ленту, и если вы хотите протестировать весь носитель, существует еще один тест, называемый тестом «Полная запись». Он выполняет запись полного объема, для чего требуется несколько часов. После завершения теста вы увидите написанную емкость и скорость передачи. Если они не соответствуют 2,5 ТБ и 160 МБ/с соответственно, основной причиной является проблема, связанная с диском -.