эххх
мечты мечты....

зато г-н кунг видимо тормоз. ЭТА тема тут не задевалась вообше. задевалась только другая, в которой была пара похожих слов.

была тема "подскажите, ЕСТЬ ЛИ фс с п.1". а это тема - "ВОЗМОЖНО ЛИ создать фс с пп1-3".  разве они чем-то связаны, кроме пары похожих слов?

> Эта тема называет фс мечты, читать я умею, а насчет того что создать такое, ничего не написано.

написано-написано, просто кто-то читает хреново "есть идеи - реально ли такое? " . для читателя, не отягощенного синдромом знакомого слова, совершенно очевидно, что тут спрашивается про теоретическую возможность, а не про существование готовых фс.

С этого поста я не веду разборок с теми кто писать не умеет, а  потом начинает спорить, - "Да я то подразумевал, и вон то, и вот это, а то что я написал, - это всё фигня, не обращайте внимания". Теперь я  таких флемеров заношу в игнор. лист.

2Кунг Цзы
Умеющих писать крайне мало. Так что проще составить лист со списком тех, с кем будете общаться.

2buggzy
По п.1 идей нет. По п.2 - может посмотреть в сторону журналируемых fs. По п.3 - может лучше совместить в одну проблему и ПО и железо (смотреть в сторону RAID).

по п. 1.
регулярные бэкапы частично решают этот вопрос

> С этого поста я...
урра!

вот бы у тебя еще и хватило мудрости не пытаться оставить за собой последнее слово во флейме, который сам же сдуру начал - я бы тебя на последок зауважал

> Но ты забыл указать еще пару параметров "иметь приемлемую скорость работы и не занимать слишком много места для служебной информации".

подумал, что очевидные вещи поминать не надо

> регулярные бэкапы частично решают этот вопрос
не надо мне частичных. у меня вчера вин2к на нтфс грузиться не стала из-за сбоя в файловой системе. загрузился с компашки, фс вылечил - теперь все ок. причем я работу системы обычно завершаю корректно. может, винт сыпется, а я из-за всяких там смартов и не знаю об этом?

чего навыдумывал.
---

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

реализация основных операций:

1. чтение из файла: в списке транзакций ищется последняя, затрагивающая необходимую область файла.
2. запись в файл: просто добавляется одна транзакция в список
3. "консолидация": все транзакции, связанные с файлом, и более старые, чем определенная дата, естественным образом объединяются в минимальное количество транзакция. это - служебная операция, производящаяся в свободное время "вручную" или форсированно при недостатке места на носителе.

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

а вот что касается часто изменяемых файлов - тут жёпа неопределенного размера.

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

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

ЗЫ. да кстати, операция записи кроме простого "добавления записи в журнал транзакций" должна включать проверку того, а правильно ли оно записалось, если ошибка то надо: стереть эту запись в журнале, найти новое место, записать туда, снова проверить. если в середине этого процесса произойдет перезагрузка, то останется блок записанный на битый блок. придется вводить транзакции на записи в журнал транзакций