|
Обновите ArcaOS до уровня NeoWPS
- Установите набор PNG иконок, нарисованных дизайнером, специализирующемся на оформлении OS/2
- Установите eSchemes 2018, чтобы менять цвета и кнопки на рабочем столе
|
Inside NTFS или как выглядят потороха |
TITLE: Inside NTFS или как выглядят потороха
DATE: 2003-02-06 14:48:43
AUTHOR: Pavel Shtemenko
Эх, сейчас бы супчику, да с потрошками....
к/ф "Место встречи изменить нельзя"
Вступление
Я думаю, что вряд ли найдется человек, имеющий дело с компьютерами и ни разу
не слышавший аббревиатуру NTFS. Я даже расшифрую ее полностью, New Technology
File System. Хвалебных статей и восторженных криков можно найти массу, ну хотя
бы на exbt.ru. Я предлагаю вам свое видение этой новой технологичной файловой
системы. Внешне все выглядит очень благопристойно - максимальная емкость
64к * 2^64 (при размере сектора 512 байт), длина имени файла 255 символов
(юникодных), имена файлов хранятся в юникоде, с файлом можно связывать
всяческие посторонние данные, типа прав доступа, комментариев и чего там еще
захочется. Имеется также журнал изменений и даже средство для пометки "плохих"
кластеров. Соотвественно поддерживается сжатие и шифрование данных. Все
выглядит очень замечательно и красиво, быть может она и была бы замечательной
и красивой если бы ее делал не MicroSoft (tm). Это все внешнее и это все
усиленно раздувается и рекламируется.
Итак сделаем взгляд в "потроха" NTFS.
Единственно, что позволю себе еще заметить - NTFS файловая система не для
бедных, не по причине крутости FS, а по причине излишне занимаемых ресурсов.
Самое главное - начать. Лозунг революционеров
Первое - BootBlock
Вся идея NTFS заключается в объектности, есть небольшая кучка объектов со
своими свойствами, эти свойства могут наследоваться, размножаться и
видоизменятся, мечта C++ программиста... и кошмар системного программиста.
Итак, начинаем с бутблока. Вопреки уже установишейся традиции поле OEM
бутблока (начало +4) содержит не вендора/производителя, а гордое название NTFS
(лично мне такой вендор не знаком) и поле метки тома содержит не символьную
метку, а бинарный код обозначающий серийный номер тома. Там есть еще небольшая
кучка несоотвествий приводящяя к тому, что для обработки бутблока надо писать
отдельную процедуру. Лично для меня стало загадкой почему MS декларировала
максимальный размер кластера в 64к, хотя поле бутблок "Секторов на кластер"
может принимать значение 256, что соотвествует 128к... Наверное опять синдром
MS 64к сработал. Замечу, что ID партиции у NTFS равен 7, у HPFS тоже равен 7...
Хотя в OS/2 в принципе это и называется ID Installable File System, но для
JFS существует отдельный ID... впрочем называемый LVM partition. Соотвественно
системный программист, вспоминая всех родителей MS поименно, пишет на все это
отдельные процедуры с кучей сравнений. В структуре NTFS также имеется файл
$Boot, коеий по всем канонам должен содержать как раз бутблок с загрузочной
записью, на самом деле он указывает в никуда, занимая соотвественно полезное
место.
Кроме того, постулировано, что загрузочная запись всегда занимает логический
кластер 0, теперь представим что у нас размер кластера 512 байт и файл $Boot
показывает в никуда. Что мы имеем? Правильно, небольшую кучку логических
кластеров начиная с 0-го, которые по всем канонам должны считаться потеряными,
так как никому не принадлежат.
Все люди делятся на две категории, те что сидят на трубах и те кому нужны деньги...
к/ф "Игла"
Второе - File record
У NTFS есть несколько видов системных записей, мы будем рассматривать только
две, File Record (FR) и Index Record (IR). Есстественно надо начинать с FR,
потому как с нее начинается любая работа с NTFS. Практически все системные
записи NTFS имеют имя. Самая главная FR имеет имя $MFT и ссылка на ее
размещение содержится в бутблоке, также имеет копия этой $MFT под названием
$MFTmirr. "Это же великолепно!" - воскликните вы, - "Это же увеличивает надежность!".
Да, конечно, заоодно съедая полезное пространство, увеличивая количество
операций записи и вдобавок полностью неуправляемое пользователем, чисто в стиле
MS - "пользователь полный идиот и мы лучше знаем, что ему надо".
Все полезное место адресуется логическими кластерами, но каждая запись имеет
свою адресацию, под названием виртуальные кластера, теперь заметим, что если
логические кластера имеют постоянный размер, записанный в бутблоке, то размер
виртуального кластера может изменятся даже в одной цепочке распределения тех
или иных данных. Подхватили упавшую челюсть? Продолжим, сразу заметив, что
такой подход к делу исключает прогнозирование или предварительный расчет
местонахождения сразу и навсегда, заодно делая кошмаром перевод виртуального
кластера в логический. Надеюсь понятно, что для того чтобы мне прочесть N-ый
виртуальный кластер, мне придется вычитать все N-1 кластера в худшем случае.
Даже предвижу возгласы "MS не могла так поступить с нами!", но история
показывает, что MS поступает всегда так как удобно ей, а отнюдь не тем, кого
она присадила на свою иглу под названием Windows. Надо отдать должное, MS типа
поспособствовала тому, что бы экономить место, предусмотрела даже так
называемые sparce кластера, но предусмотрела только один единственный случай,
когда весь кластер состоит из нулей.
Трактор в поле dir, dir, dir - мы за мир, мы за мир.
Народная присказка
Второе - директории
MS показалось мало записей типа FR и в случае директорий в NTFS используется
еще и IR. Сразу оговорим, что заранее размер IR узнать невозможно, нужно
вычитать то место, где он указывается (+1 операция чтения), можно только из
BOOT Record узнать масксимальный размер, дабы отвести для этого буфера заранее.
Штатная структура дирестории NTFS состоит из последовательности Имя - Кластер
списка - Кластер распределения списка, итого уже надо читать 3 кластера в
лучшем варианте (в отдельных случаях конечно может быть и один, но это для
директорий содержащих максимум 2 файла). Далее учитываем, что и список, и
распределение списка может быть фрагментировано, а фрагментированные записи
тоже могут быть фрагментированы, мы получаем, мы получаем....
Сразу заметим, что избыточность информации здесь на высшем уровне, сведения
об файле типа имя и атрибуты хранятся аж в двух местах - FR и IR, зато какого
размера файл надо узнавать через какое-то место, то бишь вычитывая
распределение. Если вспомнить, что сейчас не осталось таких ос, коеи по DIR или
ls не показывают размер файла... Сразу замечу, что я даже таких FS не упомню,
где размер файла не прописывался явно. Кроме того, мня позабавило адресация
записей. По всем крикам MS, NTFS вся 64 бит, но... в одном месте номер файла
64 бита, в другом 48... Я встречал 32ричную систему исчисления в t-mail, но
48ричную... Далее заглянем в поле типа "время создания/доступа e.t.c." файла,
что мы видим? Правильно, время файла исчисляется с января 1601 года выраженное
в 100 наносекундных интервалах... Лично я весьма сомневаюсь, что в 1601 году
вообще такое понятие как секунда было известно, уже не говоря об наносекундах,
ну что можно сказать на это - "размахнись рука - раззудись плечо"?
Нам не нужны милости от природы, взять их - наша задача.
Высказываение приписываемое Мичурину.
Третье - файлы собственно
Итак, наконец добрались до того ради чего вся эта FS и делалась, доступ к
файлам. Сразу отметим, что с файлами небольших размеров (как показывает
практика до 512 байт) NTFS себя чуствует великолепно, еще бы, они не требуют
отдельного диского пространства как в прочих FS. Но... как только на такой файл
навесить права доступа, то, хотя данные и содержатся в самой FR, то права
доступа начинают фрагментироваться... Если навесить на этот файл комментарий
(широко рекламируется как огромная фича) она тоже зафрагментируется. Итак, для
того чтобы наконец таки поиметь хоть часть информации с файла, мы должны:
- прочитать директрию
- выловить имя
- узнать распределение
- прочитать то что надо
Во сколько обращений к диску эта примитивная операция чтения куска файла
встанет, лично я прогнозировать не берусь, думаю и из MS engine никто на это не
ответит. Если требовать от файла доп информацию типа прав доступа или
комментариев, то во что это выливается, я думаю, что вы и сами сможете
подсчитать. Я уже даже умолчу об упоминаемом размере файла, который
необходим хотя бы для того, чтобы позиционироваться по файлу. Если учесть, что
позицию в файле я могу определить только вычиткой сначала всего
распределения файла по диску, становится грустно. Теперь призадумаемся, а
сколько же надо сделать операций, дабы записать файл на NTFS?
Наверняка ошибетесь, кучу, итого:
- Запись MFT записи
- правка $MFT
- правка $MFTmirr
- правка битмап
- правка директории
- правка записи самого файла
- запись файла собственно
Нравится? Я согласен, что тут без журнала ну просто не куда, это на мой
взгляд единственная FS, где журнал не тормозит работу, а ускоряет. С
испорльзование журнала ессено все будет несколько иначе, как то:
- запись в журнал
- молитва, чтоб не отключили питание
Заключение
Краткое, бо все уже высказано - пользуйтесь MS продуктами и у вас будет
стимул покупать более быстрые диски и немеряно наращивать память. Слегка
подытожим.
Итого, есть FS, объектная, как ящики в бывшем совке. Так же засектреченная и
также сжирающяя все что подвернется под руку (ну или шину или че там у нее).
Так собственно чего же нового в этой New Techology FS? В общем только то, что
данные мелких файлов могут хранится в самом описателе. Я достаточно детально
изучал JFS/2 и до сих пор не могу отделаться от мысли, что они близнецы братья,
но только JFS сделана с участвием системных программистов, а вот NTFS явно нет.
Но зато вьюношей воспитанных на дельфях или билдерах было предостаточно.
Послесловие
На мой взгляд плохих FS уже нет, есть только или плохо сделанный кеш или его
недостаток. Hадо отдать должное, MS кешированию отдало куда больше сил, чем
проектированию FS.
Попробуй программу:
|
Lucide - просмотр документов PDF/DjVu в eComStation.
|
Комментарии: Николай Николаев 2003-02-07 04:41:52 | Хорошо, что у нас еще есть Настоящие Системные Программисты! MS отдыхает...
| Василий А. Сидоров 2003-02-07 08:42:32 | А не рановато-ли начали делать NTFS для "юношей воспитанных на дельфях или билдерах"? | POKEMON 2003-02-07 13:49:05 | Это делали не вьюноши , а вполне сурьезныя дяди. Я их знаю. На одном гектаре ср@ли. А сделано так сложно не потому что руки кривые, а нарочно. Чтобы П.Ш. себе голову сломал, когда будет делать драйвер под ось.
Наипревосходнейший.
Кис Мяу Покемон. | KAA 2003-02-07 17:29:38 | Неплохо бы, что бы кто-нибудь, кто хорошо ориентируется в JFS рассказал бы и о ней... Ну очень интересно. | Eleph_W 2003-02-07 19:36:19 | 2KAA: Тот же Pasha, и рассказать может... | Constantin 2003-02-07 21:29:32 | 2Eleph_W:
И писАл ведь уже - [url]
А вот где я видел его-же статью про bootable JFS? | Pavel Shtemenko 2003-02-08 01:02:02 | 2KAA: У JFS тоже естьнекоторые пробои, но... она хоть продумана системно и пробои в общем-то в большей части системные ограничения для ускорения или минимизации информации.
2:Василий А.Сидоров: Дельфи может и не было, а вот билдеры были еще когда NT 3.5 стояла на HPFS ;-)
2:Constantin: А поищи на этом же сайте ;-) | Mak 2003-02-10 11:59:33 | Злобные выпады любителей осей .... :))
Скажу сразу что я небольшой спец по устройству NTFS, и все что приведено наверное правда, или половина правды :))
Хороша она или нет, но она работает достаточно быстро и надежно ... Может быть заслуга тут в кешах или еще в чем, но факт есть факт.
Я уже лет 30 работаю на разных компах и NTFS в свое время была наиболее продвинутой системой (вспомните когда она появилась). Много раз торопясь домой я просто выдергивал вилку из розетки (WinNT, W2k) и ни разу небыло никаких проблем с файловой системой. В то же время часто приходилось наблюдать что бывает когда неожиданно пропадает питание на FAT16, Linux и Nowell. Обнажды, когда я работал в банке одна тетка дернула ножкой под столом (а там стоял новелевский сервер) и нечаянно выдернула вилку из розетки ..... Половина файловой системы рухнула. Системщик всю ночь пахал и смог восстановить часть файлов .... С NTFS такого бы никогда не случилось ...
Конечно, современные файловые системы стали лучше и надежнее, но корректно ли сравнивать "Победу" из 50-х и современные BMW ?
Чтобы меня тут сильно не били, скажу, что к Мелкософту отношусь сильно отрицательно, НО, у них хороший маркетинг и они смогли задавить весь мир. И пусть Ось хорошая система (предполагаю, видел ее фанатов), но ошибки на ранних стадиях ее продвижения сделали ее тупиковой. Перспектив уже никаких. Сейчас главная война с виндами и мелкософтом идет со стороны Линуксов. Думаю, что последние в течении нескольких ближайших лет заметно потеснят винды. И даже появились слухи что мелкософт собирается в ближайшие год-два портировать в Линукс несколько своих серверных приложений (очень правдоподобно). Не дай бог, если он займется Линуксом в серьез ... | KAA 2003-02-10 18:11:30 | 2 Pavel Shtemenko.
А действительно, напиши статью о потрохах JFS.
Да и рабочуу ссылку на утилиты работы с JFS неплохо бы. Кстати, возможно ли в JFS сохранить лог проверки для последующего просмотра. В HPFS это есть. | Юрий Пронякин 2003-02-10 22:10:54 | 2Mak: Я хорошо знаком с внутренним устройством HPFS и NTFS. NTFS ведь появилась гораздо позже HPFS, но тем не менее является откровенным шагом назад - как в плане быстродействия, так и в плане надежности.
Мне как-то пришлось вытаскивать файлы с рухнувшего раздела NTFS, как я матерился. На ту работу, которая на HPFS отняла бы полчаса, я угробил почти две недели. И ведь не было никаких проблем с питанием, винда сама раздел угробила. (Как я потом выяснил, в такой же ситуации точно так же гибли разделы и у других людей.)
Но я не о том, почему раздел гибнет, а о том, что в силу некоторых странных архитектурных решений в NTFS повреждение небольшого количества секторов может привести к потере огромного количества файлов. Да и нормальные средства для восстановления файлов напрочьь отсутствуют. | Mak 2003-02-11 14:27:26 | Да, наверное все так ...
В ранних версиях NT стояла HPFS,
и вообще у NT и Оси одни корни ... :))
Если не ошибаюсь, Ось ведь начиналась совмесно IBM и Microsoft? Точнее Microsoft по заказу IBM ...
Потом эти компании поссорились и Microsoft хлопнув дверью ушла и занялась своими системами и какие-то из идей остались в НТях ... А IBM пришлось самой раскручивать разработку Оси ...
Но в то время (как мне показалось) Билл совал нос во все дырки. Его влияние (не лучшее) чувствовалось во всех продуктах Microsoft того времени ... Лучше бы он оставался просто менеджером ...
Мне тут недавно показывали (рассказывали?) исходники знаменитой программы всех времен - FDISK, так там в комментариях Автор писал что это его первый опыт программирования ... :)) И с тех пор ничего не изменилось ... система разделов, загрузки, fdisk все те же ... :))) | vv 2003-02-12 17:03:20 | только не exbt, а ixbt ;) | Eugene Gorbunoff 2003-02-13 04:41:54 | 2 Mak: "..А IBM пришлось самой раскручивать разработку Оси.." - это я заберу себе в куки :)
Любая корпорация сотрудничает с маленькими компаниями. Это естественные процессы на рынке. Точно также Microsoft сейчас нанимает ученых со стороны для реализации какой-либо фичи в своих продуктах и делает заказы более мелким фирмам на выполнение черновой работы.
Скорее, наоборот, IBM строила для своих нужд очередную операционную систему, а Microsoft влез со своей файловой оболочкой.
| dga 2003-02-13 13:58:33 | А что слышно о перспективах портируемости (posix compatible) оси? ИМХО это пока что ахиллесова пята os/2... | RElf 2003-02-13 23:07:35 | Я бы заменил слово "потроха" на слово "требуха" ;)
| Alexey Smirnov 2003-02-14 14:32:07 | По поводу HPFS.
Пользователи Полуоси страдают не от отсутствия драйвера файловой системы NTFS. Ставь себе Win2000 на раздел FAT32 и радуйся.
Пользователи страдают из-за общей безалаберности IBM.
На данный момент у нас есть 3 штатные файловые системы:
1)FAT - 32 бит, драйвер встроен в ядро. Бутовая, на развитии поставлен крест (ну, это понятно)
2)HPFS - штатно -16 бит. Бутовая. На развитии поставлен крест, в общем, как и на общем развитии Полуоси.
3)JFS - 32 бит, развивается. Не бутовая!!
Работа с простым HPFS.IFS - не очень то большая радость - скорость таки низкая, кешироавние слабое. Ставить HPFS386 - нарушать лицензионное соглашение даже тем пользователям. которые владеют той же eComStation вполне официально.
Вот и выходит что в самой передовой операционной системе до сих пор нету нормальной файловой системы, котороя удовлетворяля всем возможным критериям Т.е., была бы 32 разрядная. загрузочная, с нормальным кешированием, с возможным(но не обязательным!) откатом транзакций, поддерживала длинные имена. Про корректную поддержку русского языка я уже и не говорю.
Так что все надежды на проект FreeJFS - особенно в смысле бутовости и поддержки русского языка.
С уважением, Алексей. | Alexey Smirnov 2003-02-14 14:41:45 | Ув. Mak!
Novell пишется через букву V! Это первое.
Второе. Что это у Вас за банк такой, в котором тетка выдергивает шнур из розетки в серверной комнате? А была ли комната такая в данном банке?
А что такое UPS, в том числе, монтируемый в штатную стойку вместе с рек-маунт компьютером - у Вас в банке не знали?
И еще. Вы в банке уходя домой выдергивали шнур из розетки? Круто., что только скажешь.
Значит, в этом банке компьютеры не работали в режиме 24 часа в день 7 часов в неделю... И на данные было совершенно наплевать.
Алексей. | Eugene Gorbunoff 2003-02-14 15:03:47 | 2 Alexey Smirnov:
Загрузочная JFS существует, но ее установка в данный момент не может выполняться в автоматизированном режиме. Как только нужное количество денег от продажи eCS будет накоплено, проект будет доведен до конца.
2 Alexey Smirnov:
хмм. банки ничем не отличаются от булочных :) просто у них немножко другой имидж и на работу туда берут только если у тебя хорошая родословная 8]
| Alexey Smirnov 2003-02-14 16:52:36 | Ув. Eugene Gorbunoff!
Про Bootable -JFS. А есть ли отличная от нуля вероятность, что это чудо таки дойдет до enduser?
А можно ли поучаствовать в бета-тестировании?
Про банк и тетку со шваброй.
Вообще говоря, надежность хранения данных складывается из
1)Адмистративных мероприятий - выделение отдельной, закрытой по умолчанию, хорошо проветриваемой, с постоянной температурой в 19 градусов комнаты для серверов.
2)Технических мероприятий - стандартизации железа (все - рекмаунт, на каждую стойку - промышленный UPS), дополнительная, отдельная от остального офиса электропроводка.
3)Программно-технических решений - эксплуатация в режиме 24х7, SCSI диски в режиме хотя бы программного зеркалирования, а лучше - RAID 5й категории со stendby.
4)И уж в последнюю очередь - выбор файловой системы.
Если подобные меры не применяются в "банке" - это говорит о принебрежении к хранимым данным и о низкой квалификации ответственных лиц.
Кстати, как Novell CNE, могу сказать, что файловая система Novell -журналирующая, имеется возможность отката транзакций (к сожалению, не всех, но тем не менее). И выключение питания не приводит к потете тома в целом. И есть средства восстановления тома, штатно поставляемые с Novell - тот же NWREPAIR, которые в 99 случаях из 100 спасут данные. Максимум что будет - файл нулевой длины.
А вот улет програмного volumeset под NTFS я наблюдал воотчию. Том начинался на одном физическом диске, а заканчивался на другом. Сервер был выключен штатно (через клавишу "Пуск"). При включении - тома нет. Менеджер видит пол-тома на первом физическом диске без буквы. Лечилось так - том удалялся из менеджера, создвался заново, и на него натравили GetDataBack for NTFS. 3 часа работы - и данные были спасены.
С уважением, Алексей. | Василий А. Сидоров 2003-02-17 04:06:57 | 2dga: clib есть "сто лет в обед".
Если говорить о портируемости с/на всяких хрюнюксов, то (IMHO) основной вопрос - "против кого дружить будем" :) | Mak 2003-02-18 12:39:40 | 2 Eugene Gorbunoff: "Скорее, наоборот, IBM строила для своих нужд очередную операционную систему, а Microsoft влез со своей файловой оболочкой. "
Не так ... Если помните, когда у IBM появились самые первые писишки, они выбрали Майкрософт в качестве подрядчика на разработку софта для нее. Тогда в майкрософте (а может и названия этого еще не было?) работало "полтора" человека, или чуть больше :)). И все, что у них было - это Бейсик для какой-то микроэвм (толи 4-х, толи 8 разрядной). Конкурентов у них тогда практически небыло. IBM пригласил эту команду для разработки самого первого софта для их новой (самой первой) PC. От этого софта наверное до сих пор в биосах следы остались ... Это был прошитый в Биос бейсик, работа с бытовым магнитофоном в качестве внешней памяти и т.д.
С этого собственно и началась раскрутка Майкрософт. Если бы не это событие, то возможно мы бы и не знали сейчас этой фирмы :)). Потом была первая ОС для PC, которую Билл купил у какого-то парня и слегка переделал. Названия ее уже не помню, но в конце концов она превратилась в MSDOS. Потом был самый первый Windows, многие идеи которого были содраны с Apple ...
Когда началась разработка Оси, Майкрософт уже был извесной фирмой и видимо Бил уже чуствовал силу и не захотел делиться деньгами с IBM .... После того, как он "кинул" IBM, последней пришлось туго, и проект по Оси некоторое время был в подвешенном состоянии ...
2 Alexey Smirnov ...
Да, Novell пишется через букву V! :))
Я работал с ним последний раз лет 5 назад и уже забыл как это правильно пишется (да и суть была не в нем ? ).
Банк был нормальный, но было это лет 7 назад, и тогда Серверные и Коммуникационные комнаты еще не были в моде. Но структурированную кабельную систему для банка уже делали в новом офисе (кажется фины).
Та тетка была не уборщицей, а начальницей отдела АСУ (взятой по блату, работу делали другие). Сервер был 486 с 32Мб (тогда это было круто :)). УПС был и сервер работал круглосуточно, но она ухитрилась выдернуть шнурок который шел из УПСа в системный блок ... :))
Алексей, это я как бы оправдываюсь ... :)) Пытаюсь прокомментировать Ваши скороспелые выводы ... | Mak 2003-02-18 12:42:36 | Забыл добавить, Novell был версии 3 с чем-то (3.20 кажется) | dixie 2003-02-26 08:38:24 | Люди добрые, разговоры разговорами, а где NTFS.IFS то? ;)) Хоть для тестирования? | alexey 2003-02-27 23:44:39 | Необъективно как-то... | Eugene Gorbunoff 2003-02-28 00:06:32 | 2 alexey: зато когда ты прочитаешь где-нибудь еще один текст про ntfs, у тебя сложится достаточно объективная точка зрения. | alexey 2003-03-01 23:26:49 | 2 Eugene Gorbunoff:
Во-первых, когда я посмотрел DFSEE на раздет NTFS, и MFTMirr - всего 4096, так как ещё я должен воспринимать слова, что при записи файла необходима правка MFTMirr? Более нецензурно? А как я должен расценивать это:
* запись в журнал
* молитва, чтоб не отключили питание
в анализе системного программиста о журналируемой файловой системе (т.е. гарантрующей в разумных пределах _собственную_ целостность)? И почему это же самое (молитва, то есть) не говорится об JFS?
А вот слов о том, что то-то и то-то в NTFS для улучшения отказоустойчивости, и как это работает по сравнению с JFS, увы нет. Как нет слов о том, что виртуальные кластеры составляют базу для реализации сжатия. В отличие от...
Поэтому, увы, я мягковато выразился... | Pavel Shtemenko 2003-03-03 07:58:39 | В MFTMirr есть собственно сам MFT, в MFT содержится его собственный bitmap и Run. Править надо и никуда от этого не дется. Журнал.. Есть разница когда в журнал пишут, когда кеш не сброшен или когда в журнал пишут и из журнала реплицируют по мере возможности. Рекомендую задуматься почему так долго выключается NT.Отказоустойчивость. Лично я ее там не увидел, увидел только излишнюю проверку добавляющяя геморою системному программисту, это так называемые FixUp. Если сектор разрушен, то будет разрушена уже начало записи типа "FILE", "INDX" e.t.c. В JFS кстати все блоки имеют свой magic number. Что в JFS что в NTFS проверки и повышения отказоустойчивости собственно данных нет. Компрессия. Во первых JFS может ее поддерживать, вопрос в том что в OS/2 ее нет. В NTFS.... Наверное кой для кого будет открытием то что файлы менее длины FR не компрессируются в любом случае. Теперь подумаем, что нынче занимает большие объемы с большими файлами? Явно то что компрессируется очень плохо. Виртуальные кластера. В данных (которые могут быть сжаты) их размер неизменен, меняются они только в индексных записях. И я вообще-то указал где читать хвалебные статьи об NTFS ;-) | Тимофей 2003-03-04 18:31:27 | Кстати о сжатии на уровне FS. А чем плоха виртуальная FS, сжимающая данные на уровне файлов родительской FS? В OS/2 это ZipStream/CryptStream, которая не только прилично сжимает, но и опционально умеет шифровать данные. Для хранения больших объемов документации - самое оно. А к надежности сжатия на уровне кластеров у меня стойкое недоверие со времен Stacker/doublespace | Tolyan 2003-06-11 14:12:45 | Здесь потрахами-то и не пахнет, просто обзор... Подскажите где взять ПОТРОХА!!! | Masm 2003-07-14 23:44:35 | Потроха NTFS (по стандарту) [url]
рекомендую всем ознакомится и не строить скоропостижных выводов, система далеко не идеальна, винда из-за ее постоянных глюков сносит NTFS - видел ентуфишку в w2k, в mss2k3 такого уже нет...
да, кстати, для особознающих систему: если выделить 3 блока памяти, суммарно ~7M - можно считать базовое размещение каталогов за 1-2 прохода по диску... за сим к RTFM, [url] и мозгам...
PS. вот сижу тут, читаю и не доходит до меня, с чего такой ссыр-бор поднялся??? | Masm 2003-07-14 23:54:38 | да, чють не забыл... запись на диск, всеми нормальными людьми просходит с точностью до наоборот тому, что указано в обзоре и молитв тогда не понадобится :) если сначала исправить вводные записи, то при омнене записи файла, получается, что всю FS нужно перетряхнуть заново и отметить чистые блоки??
да, о кластерах секторах и тд... ?? даже ?????? знаков вопроса: ГДЕ ТАМ ТРУДНОСТИ!!!???? - если есть желание, разберитесь с фат, рассматривая ее 8, 12 , 16 и 32 варианты в одном - вот тут явно и процедуры лишнии и сравнения и определения..
в NTFS в все супер понятно...а о HPFS я вообще молчу - система суупер... хотя,.. зачем мне на винте сидюк??? интересно да??! HPFS, Joilet и...ммм... не соврать бы...UFd используются долгодержащими носителями в пулах SCSI и RAPID, а тагже на сменном CD-приводе(не штамповка)...
Всего наилучшего господа :;) | Alexander Sheiko 2003-07-15 01:49:48 | Похоже автор просто решил порисоваться якобы "большим пониманием" сути этой ФС.
Про надёжность NTFS тут уже писали. Из своего немалого опыта могу сказать, что ни разу не сталкивался со сбоями NTFS (не считая битого железа). За то регулярно сталкивавался с потерей данных на UFS.
Кроме того - весьма показательна картинка:
[url]
Сразу становится на место вопрос о производительности (EXT2 - не журналируемая, а скорость как у NTFS).
А автору советую действительно почитать статьи на этом сайте:
[url] | Petra 2003-07-15 11:46:50 | ЭЭэ, обосрать всё что угодно можно.
Я уже лет 7 работаю с NTFS, и она у меня ни разу не рухнула, было пора обвалов, но только вместе со смертью диска.
В статье явно наблюдаеться ненависть к Макрософт и неглубокие познания NTFS.
Автор писал под неё драйвера? Или быть может он разрабатывал коммерческое ПО для HPFS или JFS? Или он являеться Open Source активистом и вложил свой труд в Linux Ext2. Или он разработчик коммерческого ПО с 4 значной зарплатой? Если нет, то это статья - есть мнение озлобленного неудачника, недостаточно хорошо разобравшегося в сути вопроса. | Юрий 2003-07-15 14:10:44 | Прочитал статью и комментарии. Довольно интересно. Я не очень сильно разбираюсь в этом, но уже три года работаю с win2k, - занимаюсь видео (монтаж и все такое). Соответственно, - большие диски (сейчас 2 по 120 и 2 по 160) и на них эта самая NTFS. Никогда никаких проблем не было. Вообще никаких. Из статьи я так примерно понял, - NTFS - плохая, неправильно написанная, но работает быстро и надежно. А JFS - правильная и хорошая, но работает медленно и ненадежно. Так и есть? | Dorian Grey 2003-07-15 17:26:47 | Alexander Sheiko
Petra
"мнение озлобленного неудачника, недостаточно хорошо разобравшегося в сути вопроса"
Согласен. Говорю как Microsoft Certified Professional | Dorian Grey 2003-07-15 17:28:45 | Юрий
:-) ДА | Starper 2003-07-15 21:57:09 | 1. В статье не приведен исчерпывающий перечень и структуры данных кластеров. Потому это не "потроха", а только их запах
2. Согласен с автором, что запошок тот еще. Достаточно одного примера: данные малых по размеру файлов расположены в описании файла. Явный признак, что на этапе конструирования системным подходом и не пахло. Спохватились похоже при отладке, когда сгенерировав много маленьких файлов, были удивлены, что не хватает места на диске
3. Не согласен с автором про кеш. Это все же функциональная часть физического доступа к устройству, а не к логическим данным на нем расположенным | Сотрудник MS :) 2003-08-29 13:54:00 | Да что вы блин херню несёте... шаг назад... медленно... сложно... неэффективно...
Идеала нет и не будет никогда.
Всё что делает MS сделано лучше чем любой другой продукт любой другой фирмы. | Kolian 2003-11-16 21:00:51 | em narod tut vse takie umnye , mysli taki umnye u vsex, mozhet kto podskazhet zelionomu parniu kak dobitsia togo 4tob sidia v linuxe nasilovat' ntfs particiju na katoroi stoit xp i chtob on mne ne pisal READ ONLY. |
Прокомментируйте эту статью (напоминаем, автор работал над текстом несколько недель, уважайте мнение других).
|
В eComStation 2.0 реализовано удобное (автоматическое) переключение между WiFi и Ethernet-соединением. Что нового в eCS 2.0? |
|
|
|
Готовая eComStation на SSD диске
Последний активный опрос: Какая высота барьера RPM?
[Google]
|
IBM OS/2 Warp
|