linux device mapper target for maintaining statistics of operations performed on the device
Device mapper - это обертка для блочных устройств, которая берет их логику и добаляет к ней свои функции. Таким образом, объединяет два устройства: исходное и device mapper target. Зачем это нужно, почему бы не создавать каждое новое устройство заново без этой прослойки? Это может быть удобно, если мы хотим применить определенный функционал к нескольким устройствам. Без этой прослойки нам надо было бы каждый раз копировать одинаковый код в наши драйвера, модули, тем самым усложняя его, и лишая модульности. Например ядро Линукс предоставляет нам набор страндатных таргетов, среди которых есть crypt - шифрование блочного утсройства, linear - сопоставление блоков одного устройтва на к блокам другого устройства, есть raid таргеты и другие. Как видно, эти стандартные таргеты может применить пользователь для своих нужд. Например LVM (LVM2) - сделана именно на основе device mapper. Если нам не достаточно стандартных таргетов, то мы можем создать свой новый таргет. Именно это и сделаем далее. Сделаем таргет, котырый ведет статистику о количестве операций на запись и чтение к нашим утсройствам. Посмотреть статистику сможем через нитерфейс sysfs.
Сначало реализуем device mapper target, а затем добавим к нему sysfs интерфейс.
Ключевые элементы device mapper - это конструктор, деструктор, основная map функция и структура target_type, которая связывает наши фукнции с sysfs. В dmp_ctr создаем устройство, выделяем под него память, парсим полученную команду и подключаем sysfs интерфейс через функцию kobject_init_and_add В dmp_map просто обновляем нашу статистику по чтению В dmp_dtr освобождаем ресурсы и удаляем устройства
В ходе реализации sysfs интерфейса я столкнулся с некоторыми сложностями, а именно: ипользование kobject_create_and_add или kobject_init_and_add. Изначально я реализовал всю логику через kobject_create_and_add - данной функции можно не передавать kobj_type в качестве параметра, потому что она может взять kobj_type по умолчанию. И все было бы хорошо, но только эта функция принимает указатель на kobject, а у меня kobject был вложенной структурой в private_dmp_target - структуре, которая хранит информацию о каждом устройстве. А указателем я его не мог сделать, потому что тогда бы не смог использовать макрос container_of, который требует, чтобы поле было не указателем. Таким образом, я отказался от функции kobject_create_and_add в пользу kobject init_and_add, которая требует немного другую реализацию. Для этой функции надо явно создать kobj_type структуру, и в ней задать необходимые свойства и атрибуты. При таком подходе нам уже не нужны макрос __ATTR и функция sysfs_create_file.
В итоге получаем такую структуру sysfs:
dm_attr_volumes -> *dm_attrs[] -> dm_attr_group -> *dm_groups[] - тут показана вложенность.
release вызывается при put объекта.
Все это связывается в структуре dm_ktype и отправляется в нашу фукнцию инициализации 'kobject_init_and_add'
Склонировать репозиторий. Выполнить команду make, у вас появится dm_proxy.ko . Далее создадим устройство zero1 на котором будем эсперементировать:
sudo dmsetup create zero1 --table "0 16 zero" - создаем виртуальное блочное утсройсво размером 16 секторов по 512байт, которое имеет функционал нулевого устройства - все поглащает, возвращает нули.
Оно появилось в папке /dev/mapper
Теперь выполним команду
sudo make insert - команда вставит наш драйвер и создаст устройсво dmp1
Найдем его тоже по пути /dev/mapper
Теперь попробуем в него что-нибудь записать с помощью dd.
Например dd if=/dev/random of=/dev/mapper/dmp1 bs=512 count=1
Теперь можем посмотреть информацию об устройстве (статистику):
cat /sys/kernel/dmp-0/volumes
dela@axe:~/impulse/task2/module$ cat /sys/kernel/dmp-0/volumes
read:
reqs: 24
avg size: 4096
write:
reqs: 4
avg size 4096
total:
reqs: 28
avg size 4096
- Это вывод после четырех записей. Стоит заметить, что хоть мы сделали всего 4 записи, у нас произошло 24 чтения. Это сделали сторонние процессы, такие как udev и другие.
конечно надо дописать makefile