Легенда:
 новое сообщение
 закрытая нитка
 новое сообщение
 в закрытой нитке
 старое сообщение
|
- Напоминаю, что масса вопросов по функционированию форума снимается после прочтения его описания.
- Новичкам также крайне полезно ознакомиться с данным документом.
| | | |
В смысле? Ну, индексы она обновляет, когда много файлов... И ещё... 09.12.03 11:01 Число просмотров: 2570
Автор: HandleX <Александр М.> Статус: The Elderman
|
[moved from humor]
Subj. Зато потом ищет и открывает быстро... Незнаю с чего ты решил, но именно при работе с каталогами, в которых ОЧЕНЬ МНОГО файлов, проявляются все прелести NTFS. Вложенность каталогов как бы бесконечная, что тоже большой плюс для серьёзных файл-серверов.
Кстати, я в своё время NTFS ненавидел тоже, поскольку переходил на NT4 или 2k с FAT32\FAT16, поэтому FS конвертировалась. При этом размер кластера становился 512 байт, что нехорошо для больших винтов. Если же ось ставить вчистую с загр. диска и сразу правильно форматировать в NTFS, то очень даже быстро всё летает.
И ещё... В FAT, к примеру, когда хочешь открыть файл, сперва читаешь кластеры FAT, а потом кластер с данными... А вот в NTFS если размера записи MFT достаточно, чтобы сохранить там данные, то они прям там и будут сохранены...
|
|
<operating systems>
|
Да там девочки набирают, не шарят... А вообще зря. Мне NTFS нравится... Правда мудрёная она в реализации, поэтому не слишком быстрая... 09.12.03 06:48 [LLL, Killer{R}, fly4life, Ktirf]
Автор: HandleX <Александр М.> Статус: The Elderman
|
Попробуйте в других FS сделать такой финт ушами, как Read-Only реализация в драйвере NTFS для Win9x от Руссиновича — она позволяет писать на винт, и пишет, но после следующей перезагрузки изменений — ноль! ;-)
Вот бы ещё придумали такой финт типа транзакции для процесса — он вызывает что-то вроде NTFSTransactionBegin(), делает всё что угодно в плане чтения\записи\создания\удаления файлов, а потом, если всё нормально, говорит NTFSTransactionEnd(), а если что не получилось и надо всё откатить — NTFSTransactionDrop() ;-)
|
|
Куда уж там!!! "Правда мудрёная она в реализации, поэтому не слишком быстрая..." 09.12.03 10:08
Автор: DPP <Dmitry P. Pimenov> Статус: The Elderman
Отредактировано 09.12.03 10:09 Количество правок: 1
|
[moved from humor]
Она не просто не слишком быстрая, она ЖУТКО тормозная!!! Более тормозных ФС я и представить не могу! А уж какая мудреная она...
> Попробуйте в других FS сделать такой финт ушами, как
> Read-Only реализация в драйвере NTFS для Win9x от
> Руссиновича — она позволяет писать на винт, и пишет, но
> после следующей перезагрузки изменений — ноль! ;-)
Видел в ДОСе (на ФАТе) такой трюк/глюк.
> Вот бы ещё придумали такой финт типа транзакции для
> процесса — он вызывает что-то вроде NTFSTransactionBegin(),
> делает всё что угодно в плане
> чтения\записи\создания\удаления файлов, а потом, если всё
> нормально, говорит NTFSTransactionEnd(), а если что не
> получилось и надо всё откатить — NTFSTransactionDrop() ;-)
А на кой это все надо?! Я понимаю для сети транзакции нужны, но локально?!
Самый короткий хуморной прикол: "NTFS"!
|
| |
Мысль! А можно, я ее тоже подумаю? 09.12.03 14:36
Автор: Zef <Alloo Zef> Статус: Elderman
|
[moved from humor]
Я, вообще, очень похожими вещами занимаюсь: перехватом и логированием дисковых операций под w2k с разделением их по юзерам, процессам и поокам.
|
| | |
А чем встроенные средства аудита не нравится? 09.12.03 15:07
Автор: Killer{R} <Dmitry> Статус: Elderman
Отредактировано 09.12.03 15:10 Количество правок: 1
|
[moved from humor]
Кстати собираем шмотки и пеезжаем в другую ветку. Это уже не смешно. Ж)
|
| | | |
Это не аудит 10.12.03 04:28
Автор: Zef <Alloo Zef> Статус: Elderman
|
|
конечная задача - оптимизация диска и кэша под каждого юзверя/задачу на "больших" файл-серверах.
|
| |
Я юзаю НТФС дома.. 09.12.03 14:33
Автор: Killer{R} <Dmitry> Статус: Elderman
|
[moved from humor]
И ничего не тормозит. Винт на 5400. Юзаю даже не ради тех прелестей с транзакциями и правами о которых тут говорили а просто ради надежности и как ни странно скорости. Что касается тормозов НТФС - в основном они связаны с работой Indexing service который появился в 2к и с тем что система обновляет время доступа к файлу при каждом обращении к нему (т.е. при выполнении FindFirst\FindNext) Первое легко лечится отключением индексипования в настройках раздела и отключением самого Indexing service, второе - в реестре. Не помешает также оптимизация кэширования, благо памяти в компах ща валом. IOPageLock lmit поставить на 16мб минимум (в реестре) и работает все гораздо быстрее.
|
| | |
Нда, куда уж там коммандная строка и конфиг файлы (Юникс), в Нте нужно совсем в другом месте ковырять... 10.12.03 11:47
Автор: DPP <Dmitry P. Pimenov> Статус: The Elderman
Отредактировано 10.12.03 11:53 Количество правок: 2
|
> отключением самого Indexing service, второе - в реестре. Не
> помешает также оптимизация кэширования, благо памяти в
> компах ща валом. IOPageLock lmit поставить на 16мб минимум
> (в реестре) и работает все гораздо быстрее.
А именно в реестре, это ж каждой домохозяйке понятно:) Чуть что настроить (стратегию кеширования, например) - в реестр.
НТФС в принципе не будет кешировать на запись. А если ее это делать научить, то весь эффект пропадет. Я имею в виду то, что записи в журнал не должны кешироваться на запись. Это, собственно, беда всех журналируемых ФС. Заметить это легко. Стоит копирнуть небольшой файл или несколько файлов, суммарным объемом в несколько мегабайт, и в это время смортеть на лампочку активности винчестера. Под ДОСом (Смартдрайв или НортонКэш) этот эффект не наблюдается.
Накрапал тут програмку, замеряющую время создания/удаления файлов. Результаты: голый ДОС ~50 милисекунд, со смартдрайвом ~0.4 милисеунды (для 1024 файлов), НТФС Вин2000 14 или 3 милисекунды. Это время создания файла, а время удаления в несколько раз меньше с кешем, и совсем незначительно меньше без кеша. Время создания файлов под ДОСом с кешем квадратично зависит от количества файлов, а время под НТФС не изменяется (проверял только до 64 килофайлов). На идентичных аппаратно писюках с идентичными ОС (отличаются только настройками) с НТФС получена разность в 11 милисекунд (или в пять раз - 3 против 14). Под виндой на ФАТе то же самое, что и под обычным ДОСом. Жаль НОВЕЛА под рукой нет, а до Линуса пока не добрался.
Дома это одно, в организации - другое дело. Различные БД и другие сервисные программы обмениваются через расшареное дисковое пространство. Одна программа (сетевой сервис) получает информацию и передает пакеты (отдельные файлы) первому обработчику, та проверяет ЭЦП и передает второму, которые ковыряет Оракловую базу, третий обработчик (Оракловый) через файлы обменивается с обработчиком рабочей СУБД. Может это все криво реализовано, но хорошие реализации стоят столько денег!!! И подобных программ очень много. Рабочая база тоже хитро устроена - каждый рабочий день в отдельном каталоге создаются достаточное количество файловБД. Понятно зачем, надеюсь.
|
| | | |
Как раз таки кэширование записи именно в журналируемой FS будет самое надёжное! 10.12.03 12:56
Автор: HandleX <Александр М.> Статус: The Elderman
Отредактировано 10.12.03 13:00 Количество правок: 1
|
> НТФС в принципе не будет кешировать на запись. А если ее
> это делать научить, то весь эффект пропадет. Я имею в виду
> то, что записи в журнал не должны кешироваться на запись.
> Это, собственно, беда всех журналируемых ФС.
Это беда кривой реализаций дискового кэша — т.е. не должны кэшироваться журналы, а всё остальное — пожалуйста!
На "тупом" кэшировании (когда посекторно сохраняются изменения в ОЗУ, а потом делается Idle Write), конечно, не сделаешь...
Идея журналирования — обеспечить целостность транзакций. Именно при кешировании на запись этоОЧЕНЬважно, и это прекрасно реализовано в NTFS5!
Вот примерно как это выглядит:
------------ Взято из WinXP FAQ ------------------
Драйвер ввода/вывода NTFS инициирует процесс записи, одновременно сообщая сервису Log File Service вести лог всего происходящего.
Данные пишутся в кэш, под управлением сервиса Cache Manager.
Cache Manager посылает данные Virtual Memory Manager-у (менеджеру виртуальной памяти), для записи на диск в фоновом режиме.
Virtual Memory Manager посылает данные драйверу диска, пропустив их через Fault Tolerant Driver (если у вас массив дисков RAID).
Драйвер диска шлёт их контроллеру, который уже пишет их либо в кэш, либо прямо на диск.
Если эта операция проходит без ошибок, запись лога удаляется.
Если происходит сбой, запись лога остается в таблице транзакций, и при следующем доступе к диску Log File Service обнаруживает эту запись, и просто восстанавливает всё как было до этой операции.
|
| | | | |
Ну не знаю как и утверждать. Если часть диска кешироваться в... 10.12.03 14:50
Автор: DPP <Dmitry P. Pimenov> Статус: The Elderman
|
> > НТФС в принципе не будет кешировать на запись. А если
Ну не знаю как и утверждать. Если часть диска кешироваться в принципе может, а часть не должна ни под каким соусом. Вот я и написал, что кеширования на запись нет, поскольку кеширование с отложенной записью подразумевает, что в момент изменения данных никакой реальной записи не должно быть, она должна произойти позже, а инициирующие процессы сразу должны получить сообщение, что запись произведена успешно.
> Это беда кривой реализаций дискового кэша — т.е. не должны
> кэшироваться журналы, а всё остальное — пожалуйста!
> На "тупом" кэшировании (когда посекторно сохраняются
> изменения в ОЗУ, а потом делается Idle Write), конечно, не
> сделаешь...
Про журнал то я и говорю. Поскольку модификация записей в журнале является операцией более длительной, чем запоминание в кеше, отсюда и тормоза.
> Идея журналирования — обеспечить целостность транзакций.
> Именно при кешировании на запись этоОЧЕНЬважно, и это
> прекрасно реализовано в NTFS5!
Отсюда и тормоза по определению.
> Вот примерно как это выглядит:
>
> ------------ Взято из WinXP FAQ ------------------
>
> Драйвер ввода/вывода NTFS инициирует процесс записи,
> одновременно сообщая сервису Log File Service вести лог
> всего происходящего.
> Данные пишутся в кэш, под управлением сервиса Cache
> Manager.
> Cache Manager посылает данные Virtual Memory Manager-у
> (менеджеру виртуальной памяти), для записи на диск в
> фоновом режиме.
> Virtual Memory Manager посылает данные драйверу диска,
> пропустив их через Fault Tolerant Driver (если у вас массив
> дисков RAID).
> Драйвер диска шлёт их контроллеру, который уже пишет их
> либо в кэш, либо прямо на диск.
> Если эта операция проходит без ошибок, запись лога
> удаляется.
> Если происходит сбой, запись лога остается в таблице
> транзакций, и при следующем доступе к диску Log File
> Service обнаруживает эту запись, и просто восстанавливает
> всё как было до этой операции.
Дык при копировании файлов, общий объем которых может поместиться в кеше, лампочка винта должна моргать или нет? В ДОСе не моргает. Записи в журнале делаются при "сливе" кеша? Надеюсь кеш работает не на файловом уровне, а на секторном. Трудно представить что должно писаться в журнал в этом случае.
|
| | | | | |
Мы начинаем говорить о разных вещах ;-) 10.12.03 15:42
Автор: HandleX <Александр М.> Статус: The Elderman
Отредактировано 10.12.03 16:05 Количество правок: 1
|
> Ну не знаю как и утверждать. Если часть диска кешироваться
> в принципе может, а часть не должна ни под каким соусом.
> Вот я и написал, что кеширования на запись нет, поскольку
> кеширование с отложенной записью подразумевает, что в
> момент изменения данных никакой реальной записи не должно
> быть, она должна произойти позже, а инициирующие процессы
> сразу должны получить сообщение, что запись произведена
> успешно.
Ну так и есть. Процессы возврат из операции быстро получают. А винт моргает — логи пишет ;)
> Дык при копировании файлов, общий объем которых может
> поместиться в кеше, лампочка винта должна моргать или нет?
> В ДОСе не моргает. Записи в журнале делаются при "сливе"
> кеша? Надеюсь кеш работает не на файловом уровне, а на
> секторном. Трудно представить что должно писаться в журнал
> в этом случае.
Ну как бы идея кэша не в том, чтобы не обращаться к винту, доколе не кончится кэш-память, а в том, чтобы ускорять работу процессов, которые массированно занимаются файловым вводом-выводом. Он это и делает, но ещё и безопасно к тому же для структур FS. А уж как будет производится кэширование — это уже дело системы. Что плохого в том, что запись журнала не кэшируется? Я в этом только выгоду вижу.
Для чистоты эксперимента предлагаю снять крыжик в диспетчере устройств для физ. диска "отключить кэширование записи". В 2k это делается даже без перезагрузки системы — вот тогда наступают РЕАЛЬНЫЕ тормоза.
Эксперимент номер 2.
Качаем архив BugTraq, скажем ветку Programming (недавно dl выложил) Там 10200 файлов. Я разжимаю их WinRar'ом, вот, смортишь на процесс... Когда дойдёт до половины, жмёшь кнопку Pause... Прикольно смотреть за работой кэша... Во время паузы данные по-маленьку волнами падают на винт ;-)
|
| |
А я представляю :-) 09.12.03 14:22
Автор: amirul <Serge> Статус: The Elderman
|
[moved from humor]
> Она не просто не слишком быстрая, она ЖУТКО тормозная!!!
> Более тормозных ФС я и представить не могу! А уж какая
> мудреная она...
Например WinFS на основе SQL :-)
Аж страшно смотреть на это чудо
|
| |
присоединяюсь к Sandy - зря НТФС ругаешь 09.12.03 10:31
Автор: ZaDNiCa <indeed ZaDNiCa> Статус: Elderman
|
[moved from humor]
К примеру другой ФС которая имела бы столько фич сколько НТФС я не знаю:
- журналируемая
- поддержка ACL
- сжатие данных
- альтернативные потоки
Насчет быстродействия - она не такая медленная, она не сильно страдает от дефрагментации, поиск свободных кластеров для записи идет на порядок быстрее чем у FAT. Главное следить чтобы на ней всегда было по крайней мере 15% свободного места. Хочешь чтоб работала быстрее? отключи изменение времени последнего обращения к файл
З.Ы. свое мнение не навязываю - я только привел факты
З.З.Ы. надо закрывать ветку, а то начнется священная война ;-))
|
| | |
Всякие подобные штучки и под Линуком есть, правда там не... 09.12.03 10:56
Автор: DPP <Dmitry P. Pimenov> Статус: The Elderman
Отредактировано 09.12.03 10:56 Количество правок: 1
|
[moved from humor]
> К примеру другой ФС которая имела бы столько фич сколько
> НТФС я не знаю:
> - журналируемая
> - поддержка ACL
> - сжатие данных
> - альтернативные потоки
Всякие подобные штучки и под Линуксом есть, правда там не совсем на уровне ФС все реализуется, а на уровне сторонних модулей, за исключением журналируемости, эта штучка, разумеется в ФС должна быть встроена.
А в ДОСовском ФАТе - сжатие и даже шифрацию "на лету" вспомогательными программами, только это все не достижения ФС. ФС должна только хранить все грамотно.
> Насчет быстродействия - она не такая медленная, она не
> сильно страдает от дефрагментации, поиск свободных
> кластеров для записи идет на порядок быстрее чем у FAT.
> Главное следить чтобы на ней всегда было по крайней мере
> 15% свободного места. Хочешь чтоб работала быстрее? отключи
> изменение времени последнего обращения к файл
> З.Ы. свое мнение не навязываю - я только привел факты
> З.З.Ы. надо закрывать ветку, а то начнется священная война
> ;-))
Согласен, надо на соответствующей доске новую начать, а эту не раздувать.
|
| |
Ну ты сказал! 09.12.03 10:22
Автор: Sandy <Alexander Stepanov> Статус: Elderman
|
[moved from humor]
> Она не просто не слишком быстрая, она ЖУТКО тормозная!!!
> Более тормозных ФС я и представить не могу! А уж какая
> мудреная она...
А по мне так ничего, не сильно и тормозит.
> > Попробуйте в других FS сделать такой финт ушами, как
> > Read-Only реализация в драйвере NTFS для Win9x от
> > Руссиновича — она позволяет писать на винт, и пишет,
> но
> > после следующей перезагрузки изменений — ноль! ;-)
Это точно! Откат транзакции, однако! :)
> Видел в ДОСе (на ФАТе) такой трюк/глюк.
Это под НТФС трюк, а под ФАТом - глюк, да еще какой! :(
> > Вот бы ещё придумали такой финт типа транзакции для
> > процесса — он вызывает что-то вроде
> NTFSTransactionBegin(),
> > делает всё что угодно в плане
> > чтения\записи\создания\удаления файлов, а потом, если
> всё
> > нормально, говорит NTFSTransactionEnd(), а если что не
> > получилось и надо всё откатить — NTFSTransactionDrop()
> ;-)
>
> А на кой это все надо?! Я понимаю для сети транзакции
> нужны, но локально?!
Объясняю на пальцах - пишешь ты в файл на диск, система обновляет содержимое кластера, в котором лежит инфа о файле (время обновления, допустим), в этот момент система уходит в ребут (не важно, по какой причине). Что имеем после загрузки? Под ФАТом в ЛУЧШЕМ случае - потерянные кластеры, в худшем - хана части каталога со всеми вытекающими. Под НТФС менеджер транзакций файловой системы обнаруживает незавершенную транзакцию и откатывает все изменения, сделанные этой транзакцией. Это НЕ гарантирует целостность файла, который ты писал, зато ГАРАНТИРУЕТ целостность файловой системы.
> Самый короткий хуморной прикол: "NTFS"!
А в чем прикол? Объясни зды тем, кто в танке! :)
|
| | |
Видать не пробовали создать несколько миллионов файлов в... 09.12.03 10:47
Автор: DPP <Dmitry P. Pimenov> Статус: The Elderman
|
[moved from humor]
> А по мне так ничего, не сильно и тормозит.
Видать не пробовали создать несколько миллионов файлов в каталоге, а потом их удалить.
> Это точно! Откат транзакции, однако! :)
Откат транзакций, видимо, на уровне одной задачи должен быть.
> Это под НТФС трюк, а под ФАТом - глюк, да еще какой! :(
Было же.
> Объясняю на пальцах - пишешь ты в файл на диск, система
> обновляет содержимое кластера, в котором лежит инфа о файле
> (время обновления, допустим), в этот момент система уходит
> в ребут (не важно, по какой причине). Что имеем после
> загрузки? Под ФАТом в ЛУЧШЕМ случае - потерянные кластеры,
> в худшем - хана части каталога со всеми вытекающими. Под
> НТФС менеджер транзакций файловой системы обнаруживает
> незавершенную транзакцию и откатывает все изменения,
> сделанные этой транзакцией. Это НЕ гарантирует целостность
> файла, который ты писал, зато ГАРАНТИРУЕТ целостность
> файловой системы.
"На пальцах" - не катит. От возможности отрабатывать транзакции системой цикл не меняется - требуется все также записать данные, изменить таблицу распределения кластеров на диске, атрибуты файла... Обрубание питания, все равно, может произойти в этот указанный самый неприятный момент.
> > Самый короткий хуморной прикол: "NTFS"!
>
> А в чем прикол? Объясни зды тем, кто в танке! :)
Крутая ФС! Меня от нее наизнанку выворачивает. Новые технологии! Для крутых файловых серверов! Разрекламирована и раскручена! А в результате...
Попробуйте опыт с миллионами файлов на других ФС.
|
| | | |
не пробовали вроде... а надо ли?.. 09.12.03 11:37
Автор: LLL <Алексей> Статус: Member
|
[moved from humor]
> Откат транзакций, видимо, на уровне одной задачи должен
> быть.
В файл могут и несколько задач вносить изменения одновременно, поэтому полезно именно на уровне операционки заботиться о целостности ФС в плане соответствия системных областей записанным данным.
> "На пальцах" - не катит. От возможности отрабатывать
> транзакции системой цикл не меняется - требуется все также
> записать данные, изменить таблицу распределения кластеров
> на диске, атрибуты файла... Обрубание питания, все равно,
> может произойти в этот указанный самый неприятный момент.
Как тут уже ответили, NTFS своим механизмом транзакций как раз и заботится о том, чтобы завис/выключение не нарушали соответствия между всякими атрибутами файла и данными.
Но Sandy хочет еще, чтобы ФС помогла ему позаботиться о целостности структуры его собственных файлов при внесении в них изменений, чтоб самому не напрягаться с реализацией этого дела в каждом отдельном случае.
|
| | | | |
Не-е-е, я не о целостности файла, я говорил о кластере самого каталога! :) 09.12.03 23:15
Автор: Sandy <Alexander Stepanov> Статус: Elderman
|
|
|
| | | | | |
Извиняюсь :-) 10.12.03 10:31
Автор: LLL <Алексей> Статус: Member
|
|
Это говорил HandleX. Просто, отвечая, я наткнулся на желание иметь функции NTFSTransaction{Begin,End,Drop} вдвойнойцитате из поста Sandy, ошибочно приписав эту цитату тоже ему, как оппоненту DPP в дискуссии :-)
|
| | | |
Да, не пробовали! 09.12.03 11:23
Автор: Sandy <Alexander Stepanov> Статус: Elderman
|
[moved from humor]
> Видать не пробовали создать несколько миллионов файлов в
> каталоге, а потом их удалить.
Обычная такая повседневная задача, я каждый день по 10 млн файлов в одном каталоге создаю! :) Ты берешь задачу не реальную, а надуманную, а в реальной жизни все совсем по другому.
> Откат транзакций, видимо, на уровне одной задачи должен
> быть.
Задача и файловая система - не одно и то же!
> > Это под НТФС трюк, а под ФАТом - глюк, да еще какой!
> :(
>
> Было же.
я и говорю - глюк!
> > Объясняю на пальцах - пишешь ты в файл на диск,
> система
> > обновляет содержимое кластера, в котором лежит инфа о
> файле
> > (время обновления, допустим), в этот момент система
> уходит
> > в ребут (не важно, по какой причине). Что имеем после
> > загрузки? Под ФАТом в ЛУЧШЕМ случае - потерянные
> кластеры,
> > в худшем - хана части каталога со всеми вытекающими.
> Под
> > НТФС менеджер транзакций файловой системы обнаруживает
> > незавершенную транзакцию и откатывает все изменения,
> > сделанные этой транзакцией. Это НЕ гарантирует
> целостность
> > файла, который ты писал, зато ГАРАНТИРУЕТ целостность
> > файловой системы.
>
> "На пальцах" - не катит. От возможности отрабатывать
> транзакции системой цикл не меняется - требуется все также
> записать данные, изменить таблицу распределения кластеров
> на диске, атрибуты файла... Обрубание питания, все равно,
> может произойти в этот указанный самый неприятный момент.
Да, конечно, цикл не меняется, меняется сама методика, как это делается.
И обрубание питания при методике, испоьзуемой в НТФС, НИКАКОГО влияния на саму ФАЙЛОВУЮ СИСТЕМУ не окажет!
>
> > > Самый короткий хуморной прикол: "NTFS"!
> >
> > А в чем прикол? Объясни зды тем, кто в танке! :)
>
> Крутая ФС! Меня от нее наизнанку выворачивает. Новые
> технологии! Для крутых файловых серверов! Разрекламирована
> и раскручена! А в результате...
> Попробуйте опыт с миллионами файлов на других ФС.
На какой, например?
И для какой реальной задачи (кроме чисто академического интереса)?
|
| | | | |
На серваке работают сотни человек. Люди, конечно, тоже по... 09.12.03 12:13
Автор: DPP <Dmitry P. Pimenov> Статус: The Elderman
|
[moved from humor]
> Обычная такая повседневная задача, я каждый день по 10 млн
> файлов в одном каталоге создаю! :) Ты берешь задачу не
> реальную, а надуманную, а в реальной жизни все совсем по
> другому.
На серваке работают сотни человек. Люди, конечно, тоже по десятку тысяч файлов не создают. А, вот, обслуживающие программы могут и на несколько порядков больше.
> Задача и файловая система - не одно и то же!
Вопрос в том - может ли одна программа начать транзакцию, а остальные программы ею пользоваться.
> Да, конечно, цикл не меняется, меняется сама методика, как
> это делается.
> И обрубание питания при методике, испоьзуемой в НТФС,
> НИКАКОГО влияния на саму ФАЙЛОВУЮ СИСТЕМУ не окажет!
А здесь проявляется не способность отрабатывать файловые транзакции, а ее журналируемость.
> На какой, например?
> И для какой реальной задачи (кроме чисто академического
> интереса)?
У NOVELL NETWARE очень удачная ФС. А прпробовать хоть под досом можно.
|
|
|
подробно о проекте
Анализ криптографических сетевых...
