Как буферизировать записи на внешний диск с помощью внутреннего SSD

443
Zyra

Этот вопрос немного странный, я постараюсь быть максимально подробным.

Я переназначаю старый компьютер в качестве решения для резервного копирования в домашних условиях. Последним местом отдыха для данных является внешний G-Drive, подключенный через USB 2.0 (я говорил вам, что это старый компьютер). Я хотел бы выяснить, как использовать свободное место на новом блестящем SSD-диске компьютера для буферизации записей на диск. внешний диск. Я использую OpenSUSE Leap 15, с установкой сервера.

До сих пор я нашел bcache, который я мог установить в режим обратной записи и получить что-то похожее на то, что я ищу. Проблема в том, что раздел, который я буду буферизовать, использует btrfs (прозрачное сжатие), и были проблемы, сообщенные при их использовании вместе . Арк вика говорит, что это было зафиксировано в 3.9, но я не считаю, что где - нибудь в связанном источнике.

Там также lvmcache . Единственная ссылка на обратную запись, которую я вижу, - это краткое сообщение на странице руководства, без каких-либо дополнительных объяснений. Я также уже использую lvm для разделения SSD на различные разделы с тонкими пулами, поэтому я был бы обеспокоен тем, что использование lvmcache потребует от меня либо создания нового выделенного lvm-vg для двух дисков, чтобы предотвратить утечку тонких пулов. распространяясь на внешний. Кроме того, в вики BTRFS есть примечания, что использование BTRFS поверх всего, что связано с уровнем блоков, может вызвать проблемы.

DM-Cache - это еще один настраиваемый вариант, который я все еще изучаю. Поскольку он работает на уровне блоков, все еще возможно, что он может конфликтовать с btrfs.

Последний вариант - установка ZIL на основе SLOG с помощью zfs. Этот источник говорит, что при соединении 1 Гбит / с самый большой SLOG должен быть 0,625 ГБ, потому что он будет сбрасываться каждые 5 секунд. Тем не менее, исходя из всестороннего тестирования, самая высокая поддерживаемая скорость записи, которую я могу получить на этом диске, составляет 30 МБ / с. Это будет означать, что потребуется 20 секунд, чтобы сбросить нагрузку 0,625 ГБ на диск ZFS. (Обновление: на основе этого источника и этого источника устройство SLOG не предназначено для повышения пропускной способности, просто для уменьшения задержки.) (Обновление до обновления: в комментариях Дэн пояснил, что подразумевается под этим. Вполне вероятно, что ZIL может быть использован в этом сценарии.)

Я знаю, что большие записи неизбежно будут ограничены внешним подключением. Я полагаю, что все, что порядка десятков ГБ, будет иметь скорость 30 МБ / с. Моя цель не решить эту проблему. Скорее всего, я буду использовать rsync для отправки данных на внешние устройства, поэтому я бы хотел ускорить большинство операций передачи менее 10 ГБ.

Мне в основном любопытно, сделал ли кто-то еще что-то похожее на это, и есть ли у него рекомендации, или он может указать на конкретный вариант, который лучше других. В настоящий момент я считаю вариант ZFS / SLOG лучшим вариантом с использованием слог-накопителя 10 ГБ, но я не представляю, как этот большой диск будет играть с 5-секундным сбросом.

tl; dr: Каков наилучший способ (хотя я знаю, что не все это точно рекомендуется ) для буферизации данных объемом около 10 ГБ на внутреннем диске, который затем будет перенесен на внешний диск?

3
У вас самые странные проблемы, самые причудливые решения и хорошо проработанные идеи. Я люблю это! Ricardo S. 5 лет назад 1
Я раньше не сталкивался с этой проблемой, но вы смотрели на dm-cache? (Https://en.m.wikipedia.org/wiki/Dm-cache) davidgo 5 лет назад 1
@RicardoS. Хахаха, спасибо, я делаю что могу. Zyra 5 лет назад 0
@davidgo LVMCache [основан на] (http://strugglers.net/~andy/blog/2017/07/19/bcache-and-lvmcache/) dm-кеш, который потенциально может открыть те же проблемы, вызванные блокировкой решения уровня + btrfs. При этом, похоже, что в dm-кеше имеется ** много ** настроек, включая регулирование передачи данных между кешем и источником. Это означает, что если я смогу решить проблему прозрачного сжатия, dm-cache может быть лучшим устройством блочного уровня, чем два других. Спасибо за вклад! :) Zyra 5 лет назад 0

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

2
Dan

Я считаю, что любое из упомянутых вами решений будет работать нормально (за исключением взаимодействий между bcache/ LVM и BtrFS - я не знаю больше, чем вы там). Выбор, вероятно, сводится к тому, что вам проще всего понять, настроить и поддерживать.

Лично я бы выбрал ZFS, потому что:

  1. У меня большой опыт с этим.
  2. Он предоставляет решение «все в одном» для этого варианта использования (сжатие плюс использование SSD для кэширования операций чтения и / или записи).
  3. Он предоставляет множество других полезных функций (снимки и клоны, дедупликация, RAID-Z, репликация с zfs sendшифрованием, сжатый кэш ОЗУ и т. Д.), Которые могут оказаться полезными в будущем, даже если вы не используете их сейчас. Есть также здоровое сообщество с открытым исходным кодом, которое постоянно добавляет новые функции.
Как вы думаете, расширение размера SLOG поможет предотвратить узкие места? Единственное, что меня беспокоит с ZFS, это то, что ZIL будет сбрасываться каждые 5 секунд. Я не уверен, означает ли это, что записи _halted_ во время сброса, или что происходит. Я должен буду читать больше в это. ZFS был тем, к чему я тоже склонялся. Zyra 5 лет назад 0
Я провел еще какое-то исследование, и похоже, что ZIL SLOG может оказаться не лучшим способом. [Эта статья] (https://pthree.org/2012/12/06/zfs-administration-part-iii-the-zfs-intent-log/) предполагает, что SLOG улучшит задержку, но не пропускную способность. Поскольку доступ к устройству будет осуществляться через сеть, задержка не является большой проблемой. [Этот] (https://www.45drives.com/wiki/index.php?title=FreeNAS_-_What_is_ZIL_%26_L2ARC), похоже, согласен. ууу ууу :( Zyra 5 лет назад 0
@Zyra: Правильно - использование слога (или любого кэша записи) ускорит запись до тех пор, пока вы не заполните его, тогда все будет замедляться до скорости основного пула, пока что-то выталкивается из кэша. Это ** улучшает ** пропускную способность, когда требуемая пропускная способность превышает пропускную способность, которую может предложить основной пул, но если вашей рабочей нагрузке постоянно требуется более высокая пропускная способность, чем у основного пула, единственный способ использовать более быстрый основной пул. Что касается вашего другого вопроса, записи не блокируются при очистке буфера, они блокируются только при более ранних записях в ZIL / slog. Dan 5 лет назад 1
Ой! Ну тогда. ZFS может быть просто победителем в этой ситуации. Я отредактирую только что внесенное мной изменение, и если я не получу никаких дополнительных ответов, я выберу ваш ответ. Большое спасибо за разъяснения. Zyra 5 лет назад 0
Может быть, к этому приближаются не с того конца. Как я понимаю, вы оба обсуждаете, как ускорить и стабилизировать кэш, выбирая, какой fs лучше всего подходит для предполагаемой цели, хотя у вас все еще есть явное ограничение соединения USB 2.0. Упомянутые 30 МБ / с. Возможно, стоит добавить второй USB-накопитель и установить для обоих дисков extDrive значение RAID 0 .. или Stripe. Википедия утверждает, что это увеличивает производительность. Я не думаю, что это слишком большой скачок, чтобы думать, что наличие двух дисков, на которые может разгрузиться кеш, увеличит производительность. Ricardo S. 5 лет назад 1
@RicardoS. Определенно - добавление дополнительных дисков и помещение их в чередующийся zpool или использование внутреннего жесткого диска вместо диска, подключенного через USB, может помочь в производительности основного пула. Пропускная способность записи масштабируется приблизительно линейно с количеством дисков в ZFS (либо для чередования, либо для более сложных конфигураций, таких как RAID-Z, которые имеют большую избыточность для защиты от сбоев дисков), а также, вероятно, для большинства других решений чередования. Dan 5 лет назад 2
@ Дэн Чередование сделано через Vdevs правильно? Насколько я понимаю, все диски должны быть помещены в vdev во время создания (хотя над этим и ведутся работы) (https://twitter.com/OpenZFS/status/921042446275944448?s=09) (В комментарии, но я уверен, что вы видели это). В настоящее время у меня нет планов добавлять что-либо еще к этой настройке (кажется, более разумно пропустить расширение неработающей идеи и просто получить подержанный сервер xeon из ebay или чего-то еще), но в будущем было бы неплохо знать если я смогу перебраться через vdevs против _within_ vdevs. Имеет ли это смысл? лол Zyra 5 лет назад 0
@Zyra Правильно, чередование настраивается через конфигурацию, которую вы задаете для `zpool create`. Вы также можете добавить дополнительные диски в пул с помощью `zpool add` сегодня ([пример] (https://docs.oracle.com/cd/E53394_01/html/E54801/gayrd.html)), но вы не сможете добавлять диски в RAID-Z до тех пор, пока не будет выпущен упомянутый вами проект. Dan 5 лет назад 1