Из-за бюджетных проблем мы внедряем файловый сервер-слэш контроллера домена Active Directory в небольшой неправительственной организации, используя Ubuntu Server / Samba и обычный жесткий диск.
Я обеспокоен мрачной случайной скоростью доступа 4K обычных вращающихся дисков, когда дело доходит до загрузки и выгрузки перемещаемых профилей Windows. Итак, я подумываю получить очень маленький SSD для кеширования Пропускная способность сети составляет 1 ГБ, поэтому все, что находится за пределами ~ 100 МБ / с, тратится впустую, поэтому файлы большего размера (к которым осуществляется более последовательный доступ) должны быть исключены из кэша SSD.
Можем ли мы настроить dm-кеш для кэширования только файлов ниже определенного размера на кеширующем SSD?
Так, для ответа на мой собственный вопрос: Я нашел запрошенную информацию в документации dm-кэша, более точно в cache-policies.txt
.
Согласно документации, dm-кэш дифференцируется между случайными и последовательными передачами прямо из поля . Процитировать cache-policies.txt
:
сообщение и пары аргумента конструктора:
- ' sequential_threshold < #nr_sequential_ios>'
- ' random_threshold < #nr_random_ios>'
- 'read_promote_adjustment'
- 'write_promote_adjustment'
- 'discard_promote_adjustment'
, последовательный порог указывает на количество непрерывного I/Os, требуемого перед потоком, рассматривают как последовательный. Случайный порог является количеством прошедшего I/Os, состоящего из нескольких несмежных участков, который должен быть замечен, прежде чем поток рассматривают как случайный снова.
последовательное и случайное пороговое значение по умолчанию к 512 и 4 соответственно.
Большую, последовательную iOS, вероятно, лучше оставляют на устройстве источника, так как шпиндели имеют тенденцию иметь хорошую пропускную способность. io_tracker считает непрерывный I/Os, чтобы попытаться определить, когда io находится в одном из этих последовательных режимов.
Это отличается от дифференцирования уровня файла (который исходный вопрос, который задают для) , так как, по-видимому, случайным образом блоки чтения из фрагментированных больших файлов будут также кэшироваться. Но это - столь же выполнимое (и действительно, намного более устойчивое) решение проблемы. Так, исходный вопрос неправильно предположил, что кэширующееся решение работает с файлы ; на самом деле это работает на уровне файловой системы блоки .