Работа с блочными специальными файлами / устройствами для реализации файловой системы

Question

Я реализовал базовую файловую систему с использованием FUSE, со всеми реализованными функциями POSIX [естественно, я даже еще не профилировал;)].В настоящее время я могу запустить файловую систему на обычном файле (st_mode & S_IFREG), но следующий шаг в разработке - разместить ее на реальном блочном устройстве.При запуске моего кода как есть, сразу же происходит сбой при чтении st_size после вызова fstat на устройстве.Конечно, я не ожидаю, что проблемы на этом остановятся, поэтому:

• Какие изменения необходимы для работы на блочных устройствах в отличие от обычных файлов?
• Какие особые соображения ячто нужно сделать в отношении производительности, ограничений, специальных функций и тому подобного?
• Существуют ли какие-либо учебные пособия и справочные материалы по работе с блочными специальными файлами?Поиск в Google оказался очень полезным;У меня есть только базовые знания (по иронии судьбы от MSDN в моем темном прошлом) и немного скудной информации на страницах руководства.

Update0

• Я указал, что я имею в виду под"обычный файл".
• Я не хочу концентрироваться на получении размера устройства, мне нужны общие рекомендации по различиям между обычными файлами и файлами устройств в отношении производительности и использования.

Answer 1

В настоящее время я могу регулярно запускать файловую систему для файла, но следующий шаг в разработке - разместить ее на реальном блочном устройстве

Я не совсем понимаючто вы имеете в виду - я предполагаю, что вы говорите, что «вы в настоящее время сохраняете данные своей файловой системы в виде обычного файла на нормально смонтированной файловой системе - но теперь хотите использовать необработанное блочное устройство для хранения данных».

Если так- проделав это несколько раз - я бы посоветовал следующее:

• Никогда не используйте «фактическое» блочное устройство для вашей файловой системы.Всегда используйте раздел.Существует несколько редко используемых типов разделов, которые можно использовать для обозначения того, что такая файловая система может быть типом вашей файловой системы, и что ваша файловая система может проверить и смонтировать ее, если она таковая.Таким образом, вы никогда не будете работать с чем-то вроде "/ dev / sdb", а скорее будете хранить ваши данные на одном, таком как / dev / sdb1, и назначать ему какой-то тип раздела.Это имеет очевидные преимущества, например, позволяет вашей файловой системе быть одновременно размещенной на одном физическом диске в качестве другого и т. Д.
• Если вы внедряете какое-либо кэширование в своей файловой системе (как это делает Linux с Page Cache), выполнитевсе операции ввода-вывода для блочных устройств с O_DIRECT.Это требует, чтобы вы передавали память с выравниванием страницы для выполнения всех операций ввода-вывода, и требует, чтобы запросы были выровнены по секторам / блокам, но удаляла копию данных, которая в противном случае потребовалась бы при перемещении данных с блочного устройства в кэш страницызатем из страничного кеша в ваше читательское пространство [fileystem].

Что вы имеете в виду, что fstat "терпит неудачу"?Это fstat пытается определить длину блока устройства?Вы получаете ошибку?Что это?

Answer 2

блочные устройства ведут себя очень похоже на файлы - такие инструменты, как dd, могут работать с ними без какой-либо специальной обработки.fstat, тем не менее, возвращает информацию об узле специального файла, а не о блокдеве, на который он ссылается.Вы, вероятно, хотите использовать ioctl BLKGETSIZE64 для чтения размера.

нет особой причины использовать раздел поверх необработанного устройства, хотя blockdev - это blockdev.O_DIRECT также хорош, если предположить, что ваша рабочая нагрузка не будет генерировать повторный доступ.не путайте его с реальным протоколом для обеспечения постоянства и атомарности вашей файловой системы (fsync, барьеры и т. д.).