Медленное чтение снимков ZFS с ленты

458
chew socks

Я скопировал свой снимок zfs на ленту, используя

zfs send tank/vertex@2017-01-20 | pv -cCTrbB 1g | pigz -c | pv -cCTrbB 1g | dd of=/dev/nst0 bs=1M 

а затем прочитать его обратно, используя

dd if=/dev/nst0 bs=1M | pv -c | gzip -dc | ztreamdump 

и он развивается с максимальной скоростью 39 MiB/s, которая намного медленнее, чем та, на 77 MiB/sкоторой он писал.

РЕДАКТИРОВАТЬ: Я просто попытался заполнить ленту, dd if=/dev/urandom of=/dev/nst0 bs=1M count=1kа затем смог прочитать его обратно 99 MiB/s.

1
Что происходит, когда вы делаете только сырое чтение с ленты? (например, просто дд в файл). Если это быстро, что произойдет, если вы удалите `pv` из канала? И т.д. Просто чтобы разбить вещи на маленькие и проверяемые части. Hennes 7 лет назад 1
@Hennes Спасибо за предложение! Я просто попробовал оба способа (raw `dd` с` pv` и без него, и результаты были такими же, как в оригинальном случае. chew socks 7 лет назад 0
Я не знаю, так ли это, но вы используете `pigz` для сжатия и` gzip` для распаковки. Первый может использовать много процессорных ядер. `man pigz` говорит, что" декомпрессия не может быть распараллелена ". Может быть, это ваше узкое место. Проверьте использование процессора во время записи и чтения; сравните с первой командой, где `pigz` заменяется на` gzip`. Это не ответ (пока), потому что я только догадываюсь. Kamil Maciorowski 7 лет назад 2
@KamilMaciorowski Вы правы, что является потенциальным узким местом, за исключением того, что декомпрессия `gzip` намного быстрее, чем сжатие. Но, следуя совету Ханнеса, мы можем исключить программу сжатия из теста. chew socks 7 лет назад 0
Посмотрите мое редактирование выше, я просто попробовал тест снова со случайными входными данными вместо данных из файловой системы zfs и смог прочитать их на полной скорости. chew socks 7 лет назад 0
`gzip` распаковка намного быстрее, чем сжатие - верно. Однако при достаточном количестве процессоров сжатие pigz может выиграть при распаковке gzip, особенно если вы не используете `-9` или около того для сжатия. Я не знаю, сколько у вас ядер. Чтобы измерить скорость распаковки, поместите большой фрагмент (начало) вашего архива в память (например, `/ dev / shm`), затем` pv chunk | gzip -dc> / dev / null`. Kamil Maciorowski 7 лет назад 0
Какую скорость чтения вы получите, если в конце опустите ztreamdump? Просто добавьте распакованные данные в / dev / null и сообщите нам, какую скорость чтения вы получите. Это скажет нам, если ztreamdump нужно дополнительное время для обработки данных, которые он передает. a CVn 7 лет назад 0
@MichaelKjörling I have odd results. `dd if=/dev/nst0 bs=1M | pv > /dev/null` yielded 50 MiB/s at the beginning of the tape and 36 MiB/s on the area immediately after which was the same data but encrypted to make sure it wasn't compressible. chew socks 7 лет назад 1
I have a nagging feeling it could be a bad PCI card. That would explain the less than straightforward things that I've seen. chew socks 7 лет назад 0

1 ответ на вопрос

1
Riux

У меня были похожие проблемы. 1) Используете ли вы ту же ленту для обоих испытаний?

Я постараюсь дать длинный ответ, так как мне потребовалось время, чтобы найти эту информацию на лентах LTO. Это одна из хороших справок по запросу накопителя / ленты от IBM, размещенная в Oracle по имени GA32-0450-07 .

Мой ответ: Некоторые ленты LTO старые-новые (новые и изготовленные несколько лет назад, но никогда не использовавшиеся), уже использованные и помеченные как новые-переаттестованные или новые-плохие (новые, но не хранящиеся надлежащим образом во время транспортировки / хранения). Кроме того, некоторые поставщики могут не упоминать повторную сертификацию и просто рекламировать как новую ленту.

Fujitsu перепробовала 50 переаттестованных лент, 16 из них «имели недопустимо высокий уровень ошибок чтения, записи и ошибок сервоуправления, вероятно, из-за чрезмерного износа и повреждения краев в результате неправильного обращения или неправильной ориентации стримера».

Чтобы проверить, сколько операций чтения и загрузки на ленте было или ошибок чтения-записи, используйте sg_logs -a /dev/st0и посмотрите раздел 30h. Он выведет много полезной информации!

Я считаю, что можно переписать чип RFID на ленте, именно в нем вся информация записывается в журнал. Но если вы прожжете свой новый? лента (запись / чтение полной ленты) и проверьте ее, и она ( sg_logs) имеет ошибки, вы знаете, что ваша лента не в хорошем состоянии.

Совет для новых лент: создайте один большой случайный файл размером с ленту LTO и sha512проверьте его контрольную сумму, запишите его на ленту, прочитайте обратно с ленты, проверьте, все ли в порядке контрольная сумма, и посмотрите на скорость чтения / записи. Сравните журналы ошибок на диске / ленте до и после. Не забудьте использовать mbuffer! Если все хорошо, вы можете запустить свою ленту в производство. Запись используется на новом HD, проверьте blackblaze и их определение записи: «Это требует, чтобы каждый блок на каждом диске читался и проверялся».

Следите за этими числами (с sg_logs), и если на ленте есть большие ошибки, замените их общее количество записанных данных / размер ленты> 250 или число загрузок около 3000

Вы все еще можете оставить копию данных на нем, но некоторые старые мои ленты (used-ebay) будут считывать только со скоростью 5-30 МБ / с, потому что на диске слишком много ошибок, чтобы их исправить (запись по-прежнему на полной скорости). Но, эй, все еще работает, через 20-30 лет придется проверять их, чтобы узнать, читаемы ли они. Ленты LTO имеют кодировку reed solomon, поэтому возможен ремонт некоторого уровня ошибок. Некоторые используемые ленты поступают из широко используемых библиотек резервных копий и могут быть записаны раз в неделю или раз в день в течение нескольких лет, поэтому просто проверьте их, чтобы убедиться, что вы можете доверять им в своих данных. Если вы делаете критически важное резервное копирование, почему бы не получить их напрямую от HP или другого официального поставщика. Если это просто случайные вещи, и вы можете дублировать их несколько раз на разных недорогих лентах, использованные ленты LTO могут стоить того, чтобы сэкономить $$$. Тогда снова,настоящая новая лента.

Ожидаемая продолжительность жизни LTO от HPe : «Официальный текст гласит:« Носители Ultrium сертифицированы на 1 миллион проходов или 260 полных резервных копий и имеют 30-летний срок хранения в архиве ».

Тем не менее, может показаться, что вы сможете иметь одну ленту, которая прослужит почти полный год ежедневных резервных копий, прежде чем вы увидите ошибки носителя ».

Похожие вопросы