Что такое dev loop
Что такое dev loop
Другой пример смотрите в losetup(8).
Для шифрования и расшифровки каждому закольцованному устройству может быть назначена функция обмена.
Для закольцованного блочного устройства доступны следующие операции ioctl(2):
LOOP_SET_FD Связывает закольцованное устройство с открытым файлом, чей файловый дескриптор передаётся в третьем аргументе ioctl(2). LOOP_CLR_FD Отвязывает закольцованное устройство от файлового дескриптора. LOOP_SET_STATUS Назначает состояние (передаваемое в третьем аргументе ioctl(2)) закольцованному устройству. Данный аргумент представляет собой указатель на структуру loop_info, определённую в следующим образом:
Типом шифрования (lo_encrypt_type) должно быть одно из значений: LO_CRYPT_NONE, LO_CRYPT_XOR, LO_CRYPT_DES, LO_CRYPT_FISH2, LO_CRYPT_BLOW, LO_CRYPT_CAST128, LO_CRYPT_IDEA, LO_CRYPT_DUMMY, LO_CRYPT_SKIPJACK или LO_CRYPT_CRYPTOAPI (начиная с Linux 2.6.0).
Поле lo_flags представляет собой битовую маску, в которой может быть ноль или несколько следующих значений:
LO_FLAGS_READ_ONLY Закольцованное устройство доступно только для чтения. LO_FLAGS_AUTOCLEAR (начиная с Linux 2.6.25) Закольцованное устройство автоматически уничтожится после закрытия. LO_FLAGS_PARTSCAN (начиная с Linux 3.2) Разрешено автоматическое сканирования разделов. LOOP_GET_STATUS Получить состояние закольцованного устройства. В третьем аргументе ioctl(2) должен быть задан указатель на структуру struct loop_info. LOOP_CHANGE_FD (начиная с Linux 2.6.5) Поменять источник данных (backing store) закольцованного устройства на новый файл, определяемый файловым дескриптором, указанным в третьем аргументе ioctl(2), представленный целым числом. Данная операция допустима только, если закольцованное устройство доступно только на чтение и новый источник данных имеет тот же размер и тип, использованный ранее. LOOP_SET_CAPACITY (начиная с Linux 2.6.30) Изменить размер используемого (live) закольцованного устройства. Можно изменить размер используемого источника данных, а затем применить эту операцию для того, чтобы драйвер закольцованных устройств учёл новый размер. У этой операции нет аргументов.
Начиная с Linux 2.6, появилось две новые операции ioctl(2):
LOOP_SET_STATUS64, LOOP_GET_STATUS64 Они подобны описанным выше LOOP_SET_STATUS и LOOP_GET_STATUS, но используют структуру loop_info64, в которой есть несколько дополнительных полей, а некоторым другим полям назначены типы с большим диапазоном значений:
Gentoo: настройка и подключение через /dev/loop файловой системы с компрессией на примере Reiser4
Есть у меня несколько VPS’ок с Gentoo, бегущих под VMWare, для которых я, пожадничав, выделил всего по 7G дискового пространства. Как-то раз, после выхода очередной версии gcc, на одной из них закончилось место. Покопавшись, я обнаружил, что главными потребителями были директории /usr/src и /usr/portage. Тут же родилась мысль переместить их на файловую систему с компрессией (ага, на NTFS) и выбор пал на Reiser4, так как эти данные идеально подходят для неё — очень много файлов и они все маленькие.
Про эту файловую систему в сети имеется множество противоречивой информации (2013), но, пожалуй, стоит почитать статью (2010) ведущего разработчика.
Цитата из статьи:
за последние четыре года я не помню, чтобы кто-то терял данные на reiser4 разделе при исправно работающем железе. Ко мне обращалось несколько человек с жалобой на работу fsck. В конечном итоге все они получали и свои данные и работающий fsck.
Не надо её бояться…
Хочу особо подчеркнуть, так как их часто путают между собой, Reiser4 это не то же самое, что ReiserFS. Это две разных файловых системы! ReiserFS давно уже живет в основном транке ядра, а вот для Reiser4, хотя и появилась она на свет в далеком 2004 году, придется применять патч, который, надо заметить, регулярно обновляется для новых версий ядра.
Качаем и применяем патч в соответствии с вашей версией ядра (у меня в системе linux-3.10.25-gentoo) с этой страницы
Скажем, это можно сделать вот так:
Вот пример реальной последовательности команд и действий, которые я выполнял на своем сервере, вдруг, кому-то пригодится:
Так как я ставлю совсем новое ядро, то нужно подправить настройки загрузчика, я пользуюсь GRUB:
Рабочая запись для нового ядра выглядит так (просто для примера, у вас может быть всё совсем по-другому):
Не стоит пока что делать её конфигурацией по умолчанию, для начала перезапустим сервер и убедимся, что все хорошо.
Делаем контрольный замер свободного места на дисках:
Запасаемся попкорном с валидолом и…
Не забываем ручками выбрать новую конфигурацию ядра для загрузки: 
Надеюсь, ваш сервер всё ещё с вами…
Первое и второе мы уже съели, переходим к десерту — созданию loop устройства и монтированием на него образа диска с Reiser4:
Наконец, монтируем наш новый «диск»:
Перемещаем требуемые директории на новое место жительства (тут можно выпить чашечку кофе и поделать другие дела)
Всё, можно сделать контрольный и подсчитывать профит:
Итого: наши исходники занимали 3.9G, после упаковки это значение уменьшилось до 1.8G, или 46% (сжались больше, чем в два раза!) от исходного размера. Мелочь, конечно, но приятно.
Цитата из статьи, ссылка на которую дана в начале поста:
The Reiser4 performance results were mixed but overall its performance was decent compared to EXT4/XFS/Btrfs given the limited manpower devoted to this out-of-tree file-system and its unfortunate history. Beyond porting the file-system to newer versions of the Linux kernel and fixing bugs, there’s been no major development progress on Reiser4 in months. At this time, however, it appears there are still no formal plans for merging Reiser4 into the mainline Linux kernel anytime soon.
Немного обо всем и все о немногом, или практический опыт системного администратора.
| Пн | Вт | Ср | Чт | Пт | Сб | Вс |
|---|---|---|---|---|---|---|
| « Окт | Дек » | |||||
| 1 | ||||||
| 2 | 3 | 4 | 5 | 6 | 7 | 8 |
| 9 | 10 | 11 | 12 | 13 | 14 | 15 |
| 16 | 17 | 18 | 19 | 20 | 21 | 22 |
| 23 | 24 | 25 | 26 | 27 | 28 | 29 |
| 30 | ||||||
На предыдущих лекциях уже несколько раз затрагивалась тема монтирования файловых систем. Сегодня (и на следующей лекции) мы более подробно остановимся на этом вопросе. В современных дистрибутивах монтирование файловых систем в большинстве случаев происходит автоматически. Когда вы вставляете флешку в USB-разъем компьютера, у вас в каталоге /media появляется каталог с именем флешки и вы можете сразу работать с устройством (читать записывать файлы). Раньше (до появления подсистемы udev), прежде чем работать с флешкой (и любым другим блочным устройством) нужно было выполнить операцию монтирования. Когда подключается флешка (будем использовать флешку в качестве примера подразумеваю любое блочное устройство) в системе появляется физическое устройство (в каталоге /dev) с которым можно работать как с блочным устройством. Например, считать информацию с помощью команды dd. Но нам необходимо получить доступ к файловой системе этого устройства, а не к самому устройству и поэтому необходимо выполнить операцию монтирования.
Размонтирование файловой системы системы выполняется при помощи команды umount точка монтирования | устройство. Из нашего примера с флешкой umount /media/fleshka или umount /dev/sdc1. Команда umount не сможет размонтировать устройство если оно занято какой либо программой. Например, если зайти в одной консоли в каталог на смонтированном CD-ROM-диске, а затем в другой консоли попытаться выполнить команду umount, то получим ошибку:
/linux$ umount /media/cdrom0
umount: /media/cdrom0: device is busy.
(In some cases useful info about processes that use
the device is found by lsof(8) or fuser(1))
Команда lsof /media/cdrom0 покажет какие файлы открыты из каталога /media/cdrom0 и кем:
/linux$ lsof /media/cdrom0
COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME
bash 4908 igor cwd DIR 11,0 2048 1664 /media/cdrom0
less 19323 igor cwd DIR 11,0 2048 1664 /media/cdrom0
less 19323 igor 4r REG 11,0 32 1669 /media/cdrom0/config.txt
В связи с этим часто встречается следующая ситуация у начинающих linux-пользователей. Вставляется CD-диск в CD-привод и идет работа с файлами диска. Затем пользователь нажимает на кнопку привода, чтобы извлечь диск и ничего не происходит. Некоторое даже перегружают компьютер так как не понимают в чем дело. А дело все в том, что диск не может быть извлечен пока не будет размонтирован, а размонтирован он не может быть потому, что с него открыты файлы (он используется). Стоит только закрыть все файлы выйти из всех каталогов и привод “отдаст” диск при нажатии на кнопку извлечения. Если диск не извлекается, значит нужно выполнить команду umount для диска и после этого нажать на кнопку извлечения.
Хочу отметить, что команды mount/umount не производят никаких изменений в процессе своей работы с файловыми системами устройств и не могут их повредить. Сбои чаще всего бывают в результате нештатных попыток размонтирования файловой системы, например нажатие на кнопку reset системного блока. Старайтесь избегать этого действия и применять его только в самых крайних случаях. Если доступна командная строка, то перед тем как перегрузить компьютер с помощью кнопки reset, выполните команду sync. Данная команда говорит ядру, что необходимо немедленно записать всю информацию находящуюся в буферной памяти на соответствующие физические устройства. Это позволит уменьшить риск потерять информацию.
Команда mount умеет монтировать не только устройства, но и файлы. Для этого используется такое устройство как /dev/loop. Как правило в системе есть несколько подобных блочных псевдоустройств:
Для чего нам может понадобится монтировать файлы? Самый наглядный пример это, когда у нас есть образ диска в формате iso. Так как напрямую примонтировать файл к директории нельзя, то поступают следующим образом: монтируют файл к блочному устройству /dev/loop, а затем уже блочное устройство /dev/loop монтируется к точке монтирования. Для этого команду mount необходимо выполнить с ключом -o через который передать параметр loop:
Таким образом мы примонтировали файл Ubuntu_DocsPack_9.04.2.iso и можем теперь обращаться к нему как к диску.
Диск /dev/sda: 250.1 ГБ, 250059350016 байт
255 heads, 63 sectors/track, 30401 cylinders
Units = цилиндры of 16065 * 512 = 8225280 bytes
Disk identifier: 0xd4b146b8
Устр-во Загр Начало Конец Блоки Id Система
/dev/sda1 * 1 2304 18506848+ 7 HPFS/NTFS
/dev/sda2 2305 2472 1349460 e W95 FAT16 (LBA)
/dev/sda3 2473 10263 62581207+ 7 HPFS/NTFS
/dev/sda4 10264 30401 161758485 f W95 расшир. (LBA)
/dev/sda5 10264 12826 20587266 83 Linux
/dev/sda6 12827 12947 971901 82 Linux своп / Solaris
/dev/sda7 12948 18184 42066171 7 HPFS/NTFS
/dev/sda8 18185 27967 78581916 7 HPFS/NTFS
/dev/sda9 27968 30401 19551073+ 7 HPFS/NTFS
Диск /dev/sdb: 40.0 ГБ, 40020664320 байт
255 heads, 63 sectors/track, 4865 cylinders
Units = цилиндры of 16065 * 512 = 8225280 bytes
Disk identifier: 0xb292b292
Устр-во Загр Начало Конец Блоки Id Система
/dev/sdb1 1 4660 37431418+ 83 Linux
/dev/sdb2 4661 4865 1646662+ 5 Расширенный
/dev/sdb5 4661 4850 1526143+ 82 Linux своп / Solaris
/dev/sdb6 4851 4865 120456 83 Linux
Диск /dev/sdc: 4016 МБ, 4016046080 байт
90 heads, 25 sectors/track, 3486 cylinders
Units = цилиндры of 2250 * 512 = 1152000 bytes
Disk identifier: 0×00000000
Устр-во Загр Начало Конец Блоки Id Система
/dev/sdc1 4 3487 3917824 b W95 FAT32