Cascade File System или размышления о файловой системы моей мечты

Все мы привыкли к уже давно ставшему стандартному видению файловых систем: есть точка монтирования, и дерево node-ов ростёт от неё. Это удобно, привычно всем и проверенно десятилетиями. Но что если этих точек станет несколько?

Я хотел бы предложить Вам мой концепт того, как я это вижу. Пока, к сожалению, в теории, так как я не обладаю достаточным знанием проектирования файловых систем, но я более чем уверен, что на Хабре таких людей предостаточно, и моя цель — призвать их к конструктивной критике и обсуждению предложенной мною идеи.

Для чего это вообще нужно

Когда-то я сидел на Windows внутривенно и шансы того, что после установки программы её можно будет удалить и в системе не останется её остатков, стремились к нулю, стоит лишь вспомнить папку system32 и dll-ужас, творившийся там. Потом я пересел на Mac OS X, где бОльшая часть программ устанавливается просто копированием папки *.app к себе. Но всё оказалось не так просто, программы по прежнему писали в Library, а так же другие системные папки. А что, если можно было бы программы «монтировать» к файловой системе, создавая им тем самым «песочницу», из которой они не могли бы выбраться? Отмонтируешь один такой образ — и абсолютно все файлы, созданные данной программой, удалились бы из системы. Но не всё так просто.

А как у других?

На идею каскадной файловой системы меня навела структура пакетов в языках, подобных Java.
Например, у нас есть приложение, состоящее из 3х jar-библиотек:



В итоге наше приложение есть совокупность всех классов всех библиотек, которые воспринимаются единым целым. При этом конфликты решаются наложением.

Конфликты

Пожалуй, самая главная проблема этого подхода в том, как разрешать конфликты, когда файл присутствует в двух и более образах. Пока единственное адекватное решение, которое я могу предложить, это приоритетная линейная иерархия точек монтирования (где 0я позиция обеспечивает максимальный приоритет)
Благодаря этому, алгоритм поиска файла становится тривиальным: попытаться взять файл из первого образа в списке, если его там не будет — повторить операцию для следующего. С прикладной стороны должен быть механизм перестановки приоритетов образов.
По понятным причинам первый образ должен быть образом операционной системы. Это обеспечит невозможность просто переопределить системный файл из образа с меньшим приоритетом. Так же, в теории, это позволит переустанавливать ОС простым смещением образа новой ОС на нулевую позицию.

Выход из песочницы

Но не всегда приложение должно работать в своей песочнице, не редко им требуется выход из неё для модификации системных файлов либо получения повышенных привилегий. Для этого можно использовать стандартную систему привелегий пользователей для записи в «чужие» образы.

Преимущества

Как я уже говорил, одно из главных преимуществ — это невозможность программы без явного на то разрешения оставлять за собой файлы. Так же данные пользователя могли бы быть вполне себе обособленным образом, и всё, что Вы создали своими руками Вы можете либо унести с собой или создать бекап, либо удалить без опасения за то, что что-то забудется (например, при увольнении с работы)

Заключение

Я не претендую на гениальность решения и сам вижу в нём не меньше минусов, чем плюсов, но хотелось бы услышать именно Ваше мнение а не вынашивать эту мысль у себя в голове. Как программист я всегда стараюсь разделять монолитные структуры на составляющие, и файловую систему, с которой мне приходится работать каждый день, я просто не мог обойти стороной:)

P.S. Как всегда замечания относительно орфографии и стилистики текста прошу писать личными сообщениями, а не в комментариях. Спасибо.

UPD: пользователь pawnhearts привёл ссылку на ru.wikipedia.org/wiki/UnionFS. Его гугл сильнее моего:)