Файловая система

Эти заметки о программировании я пишу в необычной для себя манере: не буду обобщать, не буду точно формулировать свои мысли, хочу просто порассуждать о тех областях программирования, к которым профессионально имею отношение.
В последние 3-4 года я занялся несколько необычной деятельностью: стал выдумывать (естественно, с участием друзей и просматривая соответствующую литературу) новые варианты организации файловых систем. Периодически и в западной, и в советской печати появляются статьи о каких-нибудь новых разработках в области организации файловых систем. Что я подразумеваю под "организацией файловых систем"?
По моему убеждению, методы хранения данных на внешних носителях не слишком изменились за годы развития компьютеров Конечно, вначале данные хранились на устройствах последовательной записи (перфолентах, магнитных лентах), но такую форму хранения информации с некоторой псевдопараллельностью для магнитных лент вообще не хочется рассматривать. Это тема для отдельного разговора, тем более, что свойства ленты как носителя информации как- то пересекаются со свойствами WORM-устройств. WORM (Write Once, Read Many) - один из трех основных типов оптических дисков с однократной записью. Как и на магнитной ленте, данные дописываются в конце.
Корневой каталог на устройствах прямого доступа - дисках был придуман давно. Были придуманы и имена файлов: без массивов данных работать трудно.
Тогда же наметились два подхода. Один из них взваливал на плечи пользователя большой груз системных параметров, которые необходимо было задать для создания файлов и доступа к ним: размеры физической и логической записей, способ буферизации, режим доступа к файлу с возможностью доступа к этому же файлу из других программ, и другие параметры, смысла которых многие не представляют, но аккуратно переписывают из одной программы в другую. Большинство советских программистов прошли школу JCL - языка управления заданиями компьютеров ЕС. Однако указывать все эти немыслимые параметры заставляют пользователя!
Другой подход - в общем-то другая крайность - все решает система. Пользователю (программисту при написании программы) надо только указать, что он хочет считать из файла. Такой доступ был принят в ОС UNIX. Начисто "выметаются" методы доступа к данным. Программист все делает сам. В качестве инструмента имеются Open, Close, LSeek, Read, Write и в общем-то все. Кроме того, с появлением
UNIX повсюду внедрились подкаталоги и динамическое распределение пространства на диске. Это использовалось и до UNIX, но стало применяться все вместе как на уровне реализации, так и на уровне системного интерфейса, мне кажется, только с UNIX.
Конечно, какие-то методы доступа выполнялись в виде объектных библиотек. Но такой стиль в организации системы породил некоторую анархию в методах доступа к данным. Скорость базы данных во многом зависит от того, как организовано хранение самих данных, справочников, индексов и т. д. И, естественно, аккуратно выполняя базу данных, программист реализует и некоторый метод доступа к данным. Хороший программист с блеском разрешает эту задачу, иначе мы, скорее всего, не увидим написанную им программу. Но при этом программист затрачивает много сил на написание довольно общей части - собственно на метод доступа.
Современные файловые системы имеют обычно оригинальные (для пользователя) именования файлов. Это несколько букв и цифр, почему-то разделенных точкой. Размер имени файла обычно мал для достаточно полного указания его назначения, но велик для запоминания.
Очень часто буквы могут быть только латинскими и нашему пользователю приходится записывать, что имя ZAPIS1.TXT - это одно, а JFTRES14.DOC - это совсем другое. Причем ему еще нужно объяснить, что DOC - это не слово ДОС, а сокращение слова document. Программистам иногда кажутся смешными эти проблемы, они привыкли к английским буквам и к сокращениям типа CHKDSK. Мне лично произнести это имя трудно, но невольно приходится делать при вызове команды (из-за чего я ее переименовываю). Поэтому при недостаточном знании языка каталог напоминает текст международной телеграммы: русские названия - английскими буквами, что тяжело для пользователя.
Еще одна проблема: зачем программисту знать, что между компиляцией и получением готовой программы есть еще одна стадия - линковка. И вытекающая отсюда необходимость иметь .OBJ файл. Обычно при создании программы программист пишет .С, .Н (если на С) файлы. Затем вызывает пакетный файл и получает... .OBJ, .MAP, .SYM, .LST, иногда .ТМР и, наконец, .ЕХЕ файлы. После исправления ошибки он вдруг обнаруживает в каталоге .ВАК файлы, которые не просил создавать. Если же .Н и .С файлы имеют одинаковые имена, например, TEST.C и TEST.H, то трудно догадаться, что содержит TEST.BAK.
Программисты (в общей массе) любят не пользователя, а программирование. Но пользователя, как и пешехода, надо любить. Пользователи составляют большую часть человечества. Это пользователи изобрели компьютер и воспитали из себя программистов. И тут мирных пользователей стали "давить" (как пешеходов у Ильфа и Петрова). Если пользователя давить, то получается программирование ради программирования. За примерами далеко ходить не надо. Настолько плохо дело обстоит с отладчиками. Большинство программистов воспринимают их как чисто отладочное средство, так как в отладчике настойчиво используются А, В, С и т.д. Почему у программистов не 16 пальцев на руках! Все было бы так просто! А с десятью пальцами сумеет ли он посчитать, сколько будет 14x6 в восьмеричной системе счисления? Появились даже часы с калькулятором, работающим в двоичной, восьмеричной и шестнадцатеричной системах счисления!
Это все следствия одной проблемы - неправильной структуры системного обеспечения, а отсюда стиля программирования. Конечно, особенно у нас, в СССР, играют роль и такие факторы, как отсутствие рынка программных средств, попытки всех писать для себя инструменты и совсем немного ими пользоваться, так как необходимо вновь писать более хорошие инструменты и т. д.
Но для меня сейчас ближе проблемы структуры системного обеспечения. Структура файловой системы (наконец-то до нее добрались) - составная часть этого.
Файловая система должна играть значительно большую роль, чем сейчас: создавать большие возможности программисту и легко управляться конечным пользователем. Для этого она должна состоять из набора компонент, которые, как детали в пластиковом конструкторе LEGO, можно прикреплять друг к другу, создавая сложные композиции.
Идея древняя, как мир, - разделяй и властвуй! Но этим тезисом может воспользоваться только тот, кто умеет, во-первых, разделять. Это очень непростая задача. С одной стороны, надо сохранить целостность системы, с другой, - разделить на независимые компоненты. С одной стороны, система должна аккуратно реализовать то, что сейчас необходимо, с другой, позволять расширять себя не только новыми детальками, но и видами клея, который скрепляет детальки, новыми формами деталек, которые даже в голову не могли прийти при конструировании первого варианта. Такая система не может модернизироваться, а только расширяться. Если предусматривать расширение экстенсивное - добавление новых деталек, которые постепенно должны заменить старые, то получатся, как в MS DOS, две файловые системы - старая, использующая FCB, и новая, в стиле UNIX. И хотя старой никто практически не пользуется, ее приходится тянуть за собой. И, конечно, система кирпичиков должна базироваться на соответствующей поддержке в ядре системы.
Но это все строительные элементы. А что строить?
 


Обсудить вопрос в студенческом форуме

 

Сайт содержит информацию о учебном заведении и студенческой общине и не является официальным