информационная безопасность
без паники и всерьез
 подробно о проектеRambler's Top100
Страшный баг в WindowsГде водятся OGRы
BugTraq.Ru
Русский BugTraq
 Анализ криптографических сетевых... 
 Модель надежности двухузлового... 
 Специальные марковские модели надежности... 
 Три миллиона электронных замков... 
 Doom на газонокосилках 
 Умер Никлаус Вирт 
главная обзор RSN блог библиотека закон бред форум dnet о проекте
bugtraq.ru / форум / operating systems
Имя Пароль
ФОРУМ
если вы видите этот текст, отключите в настройках форума использование JavaScript
регистрация





Легенда:
  новое сообщение
  закрытая нитка
  новое сообщение
  в закрытой нитке
  старое сообщение
  • Напоминаю, что масса вопросов по функционированию форума снимается после прочтения его описания.
  • Новичкам также крайне полезно ознакомиться с данным документом.
Да, не пробовали! 09.12.03 11:23  Число просмотров: 2222
Автор: Sandy <Alexander Stepanov> Статус: Elderman
<"чистая" ссылка>
[moved from humor]
> Видать не пробовали создать несколько миллионов файлов в
> каталоге, а потом их удалить.

Обычная такая повседневная задача, я каждый день по 10 млн файлов в одном каталоге создаю! :) Ты берешь задачу не реальную, а надуманную, а в реальной жизни все совсем по другому.

> Откат транзакций, видимо, на уровне одной задачи должен
> быть.

Задача и файловая система - не одно и то же!

> > Это под НТФС трюк, а под ФАТом - глюк, да еще какой!
> :(
>
> Было же.

я и говорю - глюк!

> > Объясняю на пальцах - пишешь ты в файл на диск,
> система
> > обновляет содержимое кластера, в котором лежит инфа о
> файле
> > (время обновления, допустим), в этот момент система
> уходит
> > в ребут (не важно, по какой причине). Что имеем после
> > загрузки? Под ФАТом в ЛУЧШЕМ случае - потерянные
> кластеры,
> > в худшем - хана части каталога со всеми вытекающими.
> Под
> > НТФС менеджер транзакций файловой системы обнаруживает
> > незавершенную транзакцию и откатывает все изменения,
> > сделанные этой транзакцией. Это НЕ гарантирует
> целостность
> > файла, который ты писал, зато ГАРАНТИРУЕТ целостность
> > файловой системы.
>
> "На пальцах" - не катит. От возможности отрабатывать
> транзакции системой цикл не меняется - требуется все также
> записать данные, изменить таблицу распределения кластеров
> на диске, атрибуты файла... Обрубание питания, все равно,
> может произойти в этот указанный самый неприятный момент.

Да, конечно, цикл не меняется, меняется сама методика, как это делается.
И обрубание питания при методике, испоьзуемой в НТФС, НИКАКОГО влияния на саму ФАЙЛОВУЮ СИСТЕМУ не окажет!

>
> > > Самый короткий хуморной прикол: "NTFS"!
> >
> > А в чем прикол? Объясни зды тем, кто в танке! :)
>
> Крутая ФС! Меня от нее наизнанку выворачивает. Новые
> технологии! Для крутых файловых серверов! Разрекламирована
> и раскручена! А в результате...
> Попробуйте опыт с миллионами файлов на других ФС.

На какой, например?
И для какой реальной задачи (кроме чисто академического интереса)?
<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 очень удачная ФС. А прпробовать хоть под досом можно.
1  |  2 >>  »  




Rambler's Top100
Рейтинг@Mail.ru


  Copyright © 2001-2024 Dmitry Leonov   Page build time: 1 s   Design: Vadim Derkach