Транзакции уже давно есть в NTFS, но программисты ими не пользуются, поэтому это API помечено устаревшим.
T>откаты (restore points)
Это есть на любой современной файловой системе, SQL для такого не нужен.
T>очень быстрый поиск
Какая-то особая ФС для этого не нужна, нужен обычный индекс по метаданным (и данным если нужно). Это делается внешними программами.
T>встроенная версионность файлов
Как это предполагается работать? На каждый flush делать новую копию? Мне кажется, в масштабах ОС это работать не будет, всё место моментально отожрётся, люди, которые пишут программы, не рассчитывают на это. Кроме того это тривиально реализуется в рамках NTFS и тот факт, что никто этого не делает, показывает, что никому оно особо не надо. Но в принципе любая современная файловая система такое может делать, нужно только API доработать.
>виртуализация
Что имеется в виду?
> репликация
Это может быть полезно, но, опять же, какие-то SQL для этого не нужны.
T>Стабильность такой системы будет over 9000
Нет. Файловая система это такой же программный продукт, как и всё остальное и ему требуется довольно много лет, прежде чем он станет зрелым и применимым в продакшне. Причём чем больше фич туда напихают, тем сложней он станет. Поэтому к выбору фич надо относиться с большой аккуратностью.
T>Для програмистов наконец то нормальная объектная модель для работы с файловой системой, можно будет даже через SQL или через ORM работать с ней.
Да вроде и сейчас можно, я точно видел такие решения. Только никому это не нужно.
T>>>SSD дает быстрый доступ, почему и теперь должно тормозить? O>>Оно все равно для типично файловых задач будет работать медленнее чем plain FS. А значит — не нужно, T>MSDOS сейчас вообще летает, но никто ж не говорит что Windows медленно работает поэтому давайте её в топку и верните нам DOS.
Нет, не летает.
T>Если WinFS будет приемлемо работать с транзакциями и всем добром что может обеспечить SQLServer то выбор очевиден.
Дык поставь любую СУБД и получишь тот же функционал. Какой выигрыш в 'СУБД вместо ФС' по сравнению с 'СУБД поверх ФС'?
Как много веселых ребят, и все делают велосипед...
Здравствуйте, turbocode, Вы писали:
T>MSDOS сейчас вообще летает, но никто ж не говорит что Windows медленно работает поэтому давайте её в топку и верните нам DOS.
"Ты не поверишь!..." Именно это и хочу сказать. МИЛЛИОНЫ компьютеров используются в эксклюзивном режиме. Я даже родителей не подпускаю — это ПК, а не общажная сковородка. Отсюда, все эти попытки "надстройки над ДОС" выглядеть каким-то интыпрайзом — смехотворны или по кр. мере нелепы — в домашних условиях ЗА ГЛАЗА хватало именно "MS DOS" со всей её простотой.
По-хорошему, типичному домашнему компу нужна быстрая ФС и безпользовательская ОС. Т.е. не просто "одноюзерская", а вообще без понятия "твоё-моё"! Юзер — он же админ, он же System, он же повелитель всея Оси. А ФС — там вообще должно быть единственное понятие — иерархия файлов. И какая-то заточенная на скорость "система распределения свободного места". Всё.
Как всё это сделать устойчивым? Да это НЕ НАДО ДЕЛАТЬ СЛОЖНЫМ, тогда и устойчивость появится приятным бонусом! Типичный ДОС 6 ставился мной лично... из зазипованного каталога MSDOS. Просто форматил хард с флагом "системный" и распаковывал архив. Всё, готова чистая, безвирусная система. Помойка вроде домашней Венды именно на это и должна быть заточена — на полный формат системной области и быстрое восстановление системы. Увы, Мелкософт только с 7-ки научился ставить ОС с нуля без конвертации FAT32 в NTFS Про "быстрое восстановление" вообще забудьте — все ваши настройки, сеттинги программ, твики реестра... всё это летит к чертям, ибо мелким и мягким это лишний гемор.
Вирусы — сами видите, от ФС они ну вообще никак не зависят! Дырявое Вендо пропускает всё, что нужно ФБР. Даже сама концепция "запускаю Нотепад от имени Васяпупкин" — ущербна, вот почему на сегодня НЕТ спасения от вирусни.
ОК, и так много написал, но поверьте — перегруженная интыпрайзом Венда — всего лишь некомпетентность и лень MS — не хотят они возиться с разными редакциями, запустили слонопотама на 10 гигов — и пусть домашний хомячок утонет в этих прибамбасах! (99% которых ему вообще не впёрлись)
Помню у MS была идея выпустить файловую систему операционной системы Windows на базе ядра SQLServer но первый заход в продакшин был полным провалом из-за очень низкого перформанса копирования файлов.
Но сейчас ввиду SSD теперь WinFS должен работать приемлимо, почему не пытаются сделать повторный запуск этой идеи?
Здравствуйте, turbocode, Вы писали:
T>Помню у MS была идея выпустить файловую систему операционной системы Windows на базе ядра SQLServer T>почему не пытаются сделать повторный запуск этой идеи?
Возможно, потому что сама идея была глупая? Не всё можно унифицировать по количеству ног, не всё есть база, что имеет поля.
ФС — это не только (и не столько) записи о файлах, сколько оптимальное управление пространством носителя. На хардах это были сектора и важнейшая задача ФС в том числе была оптимизация перемещения головки между цилиндрами. Абстрактная СУБД ничего не должна знать о таких вещах, у неё тупо записи, индексы... Получается, что ФС только с виду — иерархичная БД, на деле не получится полностью абстрагироваться от носителя.
Да и в целом, ну что принесёт важного использование БД? Профит — мизерный, а гемора по склейке БД и носителей — много.
K>Да и в целом, ну что принесёт важного использование БД? Профит — мизерный, а гемора по склейке БД и носителей — много.
Транзакции, распределённые транзакции, откаты (restore points), очень быстрый поиск, встроенная версионность файлов, виртуализация, репликация и все это на уровне файловой системы операционной системы.
Стабильность такой системы будет over 9000
Для програмистов наконец то нормальная объектная модель для работы с файловой системой, можно будет даже через SQL или через ORM работать с ней.
T>Но сейчас ввиду SSD теперь WinFS должен работать приемлимо, почему не пытаются сделать повторный запуск этой идеи?
Потому что блочное устройство, файловая система и СУБД — три разных уровня абстракции, которые хорошо имплементятся именно в таком порядке (который внезапно совпадает с ествественным порядком роста сложности системы). Сделать СУБД на базе файловой системы — можно, и работать оно будет ничуть не лучше чем СУБД на блочном устройстве напрямую. Сделать файловую систему на СУБД — можно, но работать оно будет так как работало в результате у МС, изза чего все и закрыли.
Как много веселых ребят, и все делают велосипед...
Здравствуйте, vsb, Вы писали:
T>>Транзакции vsb>Транзакции уже давно есть в NTFS, но программисты ими не пользуются, поэтому это API помечено устаревшим.
не-не, подмена понятий. МС упорно пытался сделать транзакции, но не осилил их, в итоге объявил данное API устаревшим и строго-настрого запретил всем пользоваться транзакциями, т.к. они будут выпилены в скором времени. При этом новые ФС
от микрософта транзакций не поддерживают совсем (refs). Поэтому программисты их не используют.
PS: единственное применение транзакций на сегодняшний день — это windows updater.
T>>Если WinFS будет приемлемо работать с транзакциями и всем добром что может обеспечить SQLServer то выбор очевиден. O>Дык поставь любую СУБД и получишь тот же функционал. Какой выигрыш в 'СУБД вместо ФС' по сравнению с 'СУБД поверх ФС'?
Здравствуйте, ononim, Вы писали:
O>Потому что блочное устройство, файловая система и СУБД — три разных уровня абстракции, которые хорошо имплементятся именно в таком порядке
Ничего не слышал про возможность работы СУБД вообще без ФС?
Здравствуйте, Pavel Dvorkin, Вы писали:
m2l>>1. Более быстрые устройства могут использоваться в качестве буфера доступа к более медленым; PD>Вот о таком в Windows не слышал.
И правильно. Потому что изврат это и полумеры.
Здравствуйте, turbocode, Вы писали:
K>>Да и в целом, ну что принесёт важного использование БД? Профит — мизерный, а гемора по склейке БД и носителей — много.
T>Транзакции, распределённые транзакции, откаты (restore points), очень быстрый поиск, встроенная версионность файлов, виртуализация, репликация и все это на уровне файловой системы операционной системы.
Это во многом уже есть и без БД. Версионность с откатами на уровне файлов, например. T>Стабильность такой системы будет over 9000
А стабильность — это разве проблема сейчас? По-моему, с ССД эта проблема довольно редкая, даже при сбое питания. Разве что на серверах, но они и так в БД, а не прямо на диск пишут. T>Для програмистов наконец то нормальная объектная модель для работы с файловой системой, можно будет даже через SQL или через ORM работать с ней.
Нафиг-нафиг.
Переубедить Вас, к сожалению, мне не удастся, поэтому сразу перейду к оскорблениям.
Здравствуйте, turbocode, Вы писали:
T>Но сейчас ввиду SSD теперь WinFS должен работать приемлимо, почему не пытаются сделать повторный запуск этой идеи?
Судя по тому, что файловая система следующего поколения для Windows называется ReFS и в ней нет ничего подобного, этот проект похоронили.
Здравствуйте, turbocode, Вы писали:
T>Помню у MS была идея выпустить файловую систему операционной системы Windows на базе ядра SQLServer но первый заход в продакшин был полным провалом из-за очень низкого перформанса копирования файлов. T>Но сейчас ввиду SSD теперь WinFS должен работать приемлимо, почему не пытаются сделать повторный запуск этой идеи?
— Файловая система ReFS (Resilent File System), оптимизированная для использования на компьютерах с большими массивами данных. Она поддерживает автоматическое исправление ошибок на дисках.
Среди основных особенностей:[4][5]
Улучшенная надёжность хранения информации на диске структур. ReFS использует B+ деревья[4] (принцип, сходный с хранением данных в реляционных СУБД) как для метаданных, так и для содержимого файлов. Размеры файлов, томов, количество файлов в каталоге ограничены лишь 64-битным числом, что соответствует размеру файла в 16 эксбибайт, размеру тома в 1 йобибайт (при использовании кластеров данных размером 64 КиБ). Свободное место на диске описывается 3 отдельными иерархическими таблицами для малых, средних и больших фрагментов свободного пространства. Имена файлов и длина пути ограничена 32 кибибайтами, для их хранения используется Unicode.
Поддержка стратегии Copy-on-write (копирование при записи, выделение при записи) для метаданных[4], при которой любые транзакции файловой системы не перезаписывают старые метаданные, а записываются в новый блок и организуются в пачки. Для всех метаданных в ReFS используются 64-битные контрольные суммы, хранящиеся независимо. Данные файлов могут иметь контрольную сумму в отдельном потоке (атрибут «integrity»). В случае, если содержимое файлов или метаданных не соответствует контрольным суммам, не требуется отключение файловой системы для удаления или восстановления таких данных. За счет встроенных проверок ReFS не требует регулярного использования утилит проверки диска типа CHKDSK.
Совместимость со старыми API[4], поддержка многих особенностей NTFS, например, шифрование BitLocker, Access Control Lists, USN Journal, уведомления об изменениях,[6] символьные ссылки, junction point, точки монтирования, reparse point, «теневых» копий, идентификаторов файлов, NTFS oplock. ReFS интегрируется с технологией виртуализации носителей данных Storage Spaces[4], которая позволяет применять зеркалирование и объединять несколько физических носителей, как в рамках одного ПК, так и через сеть.[7] При использовании зеркалирования ReFS может обнаруживать и исправлять сбойные копии файлов в процессе data scrubbing, при котором проводится фоновая сверка контрольных сумм.
Многие возможности NTFS не поддерживаются в ReFS, включая именованные потоки файлов (после проверки на Windows 10 TP ADS работает с ReFS. Для поддержки ReFS нужно вносить изменения в реестр), NTFS Distributed Link Tracking (DLT), короткие имена файлов (формат 8.3), сжатие файлов, шифрование на уровне файлов Encrypting File System, транзакции NTFS, жёсткие ссылки, extended attributes и дисковые квоты.[4][2] Разреженные файлы (Sparse files) поддерживаются в RTM.[8][9]
В Windows Server 2012 не поддерживается загрузка с ReFS. Ввиду отсутствия поддержки именованных потоков ReFS не может быть использована для размещения экземпляров MS SQL, включая версию 2012.[10]
и солнце б утром не вставало, когда бы не было меня
T>>Но сейчас ввиду SSD теперь WinFS должен работать приемлимо, почему не пытаются сделать повторный запуск этой идеи? O>Потому что блочное устройство, файловая система и СУБД — три разных уровня абстракции, которые хорошо имплементятся именно в таком порядке (который внезапно совпадает с ествественным порядком роста сложности системы). Сделать СУБД на базе файловой системы — можно, и работать оно будет ничуть не лучше чем СУБД на блочном устройстве напрямую. Сделать файловую систему на СУБД — можно, но работать оно будет так как работало в результате у МС, изза чего все и закрыли.
SSD дает быстрый доступ, почему и теперь должно тормозить?
T>SSD дает быстрый доступ, почему и теперь должно тормозить?
Оно все равно для типично файловых задач будет работать медленнее чем plain FS на том самом железе. А значит — не нужно.
Как много веселых ребят, и все делают велосипед...
T>>SSD дает быстрый доступ, почему и теперь должно тормозить? O>Оно все равно для типично файловых задач будет работать медленнее чем plain FS. А значит — не нужно,
MSDOS сейчас вообще летает, но никто ж не говорит что Windows медленно работает поэтому давайте её в топку и верните нам DOS.
Если WinFS будет приемлемо работать с транзакциями и всем добром что может обеспечить SQLServer то выбор очевиден.
K>"Ты не поверишь!..." Именно это и хочу сказать. МИЛЛИОНЫ компьютеров используются в эксклюзивном режиме. Я даже родителей не подпускаю — это ПК, а не общажная сковородка. Отсюда, все эти попытки "надстройки над ДОС" выглядеть каким-то интыпрайзом — смехотворны или по кр. мере нелепы — в домашних условиях ЗА ГЛАЗА хватало именно "MS DOS" со всей её простотой. K>По-хорошему, типичному домашнему компу нужна быстрая ФС и безпользовательская ОС. Т.е. не просто "одноюзерская", а вообще без понятия "твоё-моё"! Юзер — он же админ, он же System, он же повелитель всея Оси. А ФС — там вообще должно быть единственное понятие — иерархия файлов. И какая-то заточенная на скорость "система распределения свободного места". Всё.
Temple OS наше фсе
Как много веселых ребят, и все делают велосипед...
Здравствуйте, Kolesiki, Вы писали:
K>ФС — это не только (и не столько) записи о файлах, сколько оптимальное управление пространством носителя. На хардах это были сектора и важнейшая задача ФС в том числе была оптимизация перемещения головки между цилиндрами.
Это относится к функциям драйвера физического диска , а не драйвера файловой системы. Драйвер ФС просто передает запросы драйверу физического диска, а тот может оптимизировать перемещения головок. Тем более что к драйверу физического диска будут запросы от драйвера файловой системы, обслуживающего разные логические диски. Драйвер же физического диска о файловой системе понятия не имеет, не его дело.
Здравствуйте, Kolesiki, Вы писали:
K>Возможно, потому что сама идея была глупая? Не всё можно унифицировать по количеству ног, не всё есть база, что имеет поля.
Ты, как обычно, не в курсе, но уже мнение имеешь.
K>ФС — это не только (и не столько) записи о файлах, сколько оптимальное управление пространством носителя. На хардах это были сектора и важнейшая задача ФС в том числе была оптимизация перемещения головки между цилиндрами. Абстрактная СУБД ничего не должна знать о таких вещах
А неабстрактная MSSQL знает о таких вещах очень много.
Здравствуйте, ononim, Вы писали:
T>>SSD дает быстрый доступ, почему и теперь должно тормозить? O>Оно все равно для типично файловых задач будет работать медленнее чем plain FS на том самом железе.
Record Management Services is the structured I/O layer of the VMS operating system. RMS provides comprehensive program support for managing structured files, such as record-based and indexed database files. The VMS file system, in conjunction with RMS, extends files access past simple byte-streams and allows OS-level support for a variety of rich files types. Each file in the VMS file system may be thought of as a database, containing a series of records, each of which has one of more individual fields. A text file, for example, is a list of records (lines) separated by a newline character. RMS is an example of a record-oriented filesystem.
Как писал главный эрлангист всея РФ Лео Валкин "но потом разработчиков стошнило, и они перестали это использовать".
Здравствуйте, Ops, Вы писали:
Ops>Это во многом уже есть и без БД. Версионность с откатами на уровне файлов, например. Ops>А стабильность — это разве проблема сейчас? По-моему, с ССД эта проблема довольно редкая, даже при сбое питания. Разве что на серверах, но они и так в БД, а не прямо на диск пишут.
Чтиво. Сам-то когда с ужастиками сталкивался? Я написал где-то рядом честно — в начале нулевых. А сейчас в деревню переехал, где иногда свет отключают, и вот ни разу не было проблем.
Переубедить Вас, к сожалению, мне не удастся, поэтому сразу перейду к оскорблениям.
O>>Потому что блочное устройство, файловая система и СУБД — три разных уровня абстракции, которые хорошо имплементятся именно в таком порядке НС>Ничего не слышал про возможность работы СУБД вообще без ФС?
Я о многом слышал) Если от накопителя нужна только СУБД — не вопрос.
А данный топик о том чтобы использовать СУБД вместо файловой системы для задач, в которых сейчас используются файловые системы.
Как много веселых ребят, и все делают велосипед...
Здравствуйте, ononim, Вы писали:
O>>>Потому что блочное устройство, файловая система и СУБД — три разных уровня абстракции, которые хорошо имплементятся именно в таком порядке НС>>Ничего не слышал про возможность работы СУБД вообще без ФС? O>Я о многом слышал) Если от накопителя нужна только СУБД — не вопрос. O>А данный топик о том чтобы использовать СУБД вместо файловой системы для задач, в которых сейчас используются файловые системы.
Тем не менее твои рассказы про уровни абстракции несколько отличаются от реальности.
Здравствуйте, Ops, Вы писали:
Ops>Здравствуйте, Слава, Вы писали:
С>>Да если бы. Увлекательное чтение: https://danluu.com/file-consistency/
Ops>Чтиво. Сам-то когда с ужастиками сталкивался? Я написал где-то рядом честно — в начале нулевых. А сейчас в деревню переехал, где иногда свет отключают, и вот ни разу не было проблем.
Я не верю, что ты успел это прочитать с такой скоростью. Также, я не верю, что ты вообще занимался низкоуровневой работой с файлами, всеми этими FILE_FLAG_WRITE_THROUGH.
Ну и, посыпавшуюся NTFS я видел много раз, как и RaiserFS. И битые файлы реестра видел много раз. Я ведь ремонтником работал.
O>>>>Потому что блочное устройство, файловая система и СУБД — три разных уровня абстракции, которые хорошо имплементятся именно в таком порядке НС>>>Ничего не слышал про возможность работы СУБД вообще без ФС? O>>Я о многом слышал) Если от накопителя нужна только СУБД — не вопрос. O>>А данный топик о том чтобы использовать СУБД вместо файловой системы для задач, в которых сейчас используются файловые системы. НС>Тем не менее твои рассказы про уровни абстракции несколько отличаются от реальности.
Реальность штука многогранная. В реальности некоторые мужчины в задницу сношаются. И некоторые женщины в задницу дают. Но это не повод объявлять вагинальный секс ненужным, как недостаточно универсальный механизм.
Как много веселых ребят, и все делают велосипед...
Здравствуйте, Слава, Вы писали:
С>Я не верю, что ты успел это прочитать с такой скоростью.
Так чтиво же. С>Также, я не верю, что ты вообще занимался низкоуровневой работой с файлами, всеми этими FILE_FLAG_WRITE_THROUGH.
А это не мои проблемы. Вы мне обеспечили надежные файлы — и хорошо.
С>Ну и, посыпавшуюся NTFS я видел много раз, как и RaiserFS. И битые файлы реестра видел много раз. Я ведь ремонтником работал.
Ну а в реале сколько видел? У себя, у семьи? Наверное, нисколько?
Переубедить Вас, к сожалению, мне не удастся, поэтому сразу перейду к оскорблениям.
Здравствуйте, Ops, Вы писали:
Ops>А это не мои проблемы. Вы мне обеспечили надежные файлы — и хорошо.
Вон из профессии.
С>>Ну и, посыпавшуюся NTFS я видел много раз, как и RaiserFS. И битые файлы реестра видел много раз. Я ведь ремонтником работал. Ops>Ну а в реале сколько видел? У себя, у семьи? Наверное, нисколько?
Я не понимаю, к чем этот аргумент. Я например и СПИДом не болел — что же, его нет?
Здравствуйте, Слава, Вы писали:
С>Вон из профессии.
Почему? Обоснуй. Если ты не умеешь собрать комп из говна и палок — то сам вон. А я за переиспользование чужих наработок, не вникая в детали.
С>Я не понимаю, к чем этот аргумент. Я например и СПИДом не болел — что же, его нет?
Так его и нет. Ты преувеличиваешь его масштабы и вероятность заразиться. Тот же сифилис намного опаснее, но ты же не переживаешь из-за него?
Переубедить Вас, к сожалению, мне не удастся, поэтому сразу перейду к оскорблениям.
Здравствуйте, Ops, Вы писали:
С>>Вон из профессии. Ops>Почему? Обоснуй. Если ты не умеешь собрать комп из говна и палок — то сам вон. А я за переиспользование чужих наработок, не вникая в детали.
Я-то как раз умею. А ты являешься ярким примером того, за что программистов не любят сотрудники IT Operations.
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Здравствуйте, Kolesiki, Вы писали:
K>>ФС — это не только (и не столько) записи о файлах, сколько оптимальное управление пространством носителя. На хардах это были сектора и важнейшая задача ФС в том числе была оптимизация перемещения головки между цилиндрами.
PD>Это относится к функциям драйвера физического диска , а не драйвера файловой системы. Драйвер ФС просто передает запросы драйверу физического диска, а тот может оптимизировать перемещения головок. Тем более что к драйверу физического диска будут запросы от драйвера файловой системы, обслуживающего разные логические диски. Драйвер же физического диска о файловой системе понятия не имеет, не его дело.
Если разводить умные космические абстракции — да. На деле ФС должна знать особенности носителя. Скажем, для ленточного носителя удобнее все каталоги держать ближе к началу кассеты + резервировать некоторое про-во для расширения. Но это абсолютно не нужно на flash, зато желательна "кратная" работа с блоками, чтобы микрухи зря не насиловать. И совсем другая история с хардами — там нужно часто используемые файлы держать на краях диска (где наибольшая скорость), а саму запись оптимизировать по цилиндрам и даже выбирать нужный цилиндр, чтобы, например, туда мог поместиться весь каталог.
Простой командой "запиши по смещению 17 вот этот килобайт" ты НИЧЕГО не сможешь контролировать. Отсюда, все ваши абстракции "текут" — нельзя слишком высоко парить над железом!
Здравствуйте, Слава, Вы писали:
С>Ну и, посыпавшуюся NTFS я видел много раз, как и RaiserFS. И битые файлы реестра видел много раз. Я ведь ремонтником работал.
Что ты этим хочешь доказать? Топик — про уместность использования СУБД вместо ФС. Разумеется, надёжность можно повышать вообще не прибегая к СУБД.
Здравствуйте, Kolesiki, Вы писали:
PD>>Это относится к функциям драйвера физического диска , а не драйвера файловой системы. Драйвер ФС просто передает запросы драйверу физического диска, а тот может оптимизировать перемещения головок. Тем более что к драйверу физического диска будут запросы от драйвера файловой системы, обслуживающего разные логические диски. Драйвер же физического диска о файловой системе понятия не имеет, не его дело.
K>Если разводить умные космические абстракции — да.
Это не абстракции, а модель многоуровневых драйверов в Windows.
K>На деле ФС должна знать особенности носителя. Скажем, для ленточного носителя удобнее все каталоги держать ближе к началу кассеты + резервировать некоторое про-во для расширения. Но это абсолютно не нужно на flash, зато желательна "кратная" работа с блоками, чтобы микрухи зря не насиловать. И совсем другая история с хардами — там нужно часто используемые файлы держать на краях диска (где наибольшая скорость), а саму запись оптимизировать по цилиндрам и даже выбирать нужный цилиндр, чтобы, например, туда мог поместиться весь каталог.
Ленты обсуждать не буду, так как последний раз имел с ними дело очень давно, а для дисков это никак не возможно, просто потому, что NTFS (или FAT) не знает, что находится под ней. А там может быть и простой том (часть винчестера), и составной том , лежащий на нескольких HDD(striped, RAID-5), и зеркало, а с другой стороны, и HDD, и SSD, и флешка.
В общем, стек драйверов — драйвер NTFS передает запрос драйверу нижележащему, тот, в свою очередь, нижележащему и т.д. При этом любой драйвер полагается на работу нижележащего драйвера и ничего не знает о том, как тот внутри себя устроен и с чем в реальности работает.
Подробности здесь. Кто такой Руссинович — надеюсь, знаешь.
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Это не абстракции, а модель многоуровневых драйверов в Windows. PD>Ленты обсуждать не буду, так как последний раз имел с ними дело очень давно, а для дисков это никак не возможно, просто потому, что NTFS (или FAT) не знает, что находится под ней. А там может быть и простой том (часть винчестера), и составной том , лежащий на нескольких HDD(striped, RAID-5), и зеркало, а с другой стороны, и HDD, и SSD, и флешка. PD>В общем, стек драйверов — драйвер NTFS передает запрос драйверу нижележащему, тот, в свою очередь, нижележащему и т.д. При этом любой драйвер полагается на работу нижележащего драйвера и ничего не знает о том, как тот внутри себя устроен и с чем в реальности работает.
Всё в общем то верно, но ntfs и этот стек дисковой подсистемы разрабатывалась почти тридцать лет назад и предназначались для жеских дисков того времени.
Более современные системы вроде ZFS/Btrfs имеют другой дизайн.
Здравствуйте, m2l, Вы писали:
m2l>Всё в общем то верно, но ntfs и этот стек дисковой подсистемы разрабатывалась почти тридцать лет назад и предназначались для жеских дисков того времени. m2l>Более современные системы вроде ZFS/Btrfs имеют другой дизайн.
Я с их внутренним устройством незнаком, поэтому хочу лишь задать вопрос. Верно ли, что они напрямую работают с физическим диском (то есть осуществляют ввод-вывод по CHR или логическому номеру сектора) ? Или же они это делают все-таки через драйвер физического диска, а сами занимаются только своими структурами в рамках того раздела, который отведен этому тому на физическом диске ?
То, какой у них дизайн в рамках собственно тома, которым они управляют — несущественно, пусть там что угодно создают. А вот если они с физическим диском напрямую работают — это уже нечто иное.
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Я с их внутренним устройством незнаком, поэтому хочу лишь задать вопрос. Верно ли, что они напрямую работают с физическим диском (то есть осуществляют ввод-вывод по CHR или логическому номеру сектора) ? Или же они это делают все-таки через драйвер физического диска, а сами занимаются только своими структурами в рамках того раздела, который отведен этому тому на физическом диске ?
Они делают это через драйвер блочного устройства, которым не обязан быть физический диск.
PD>То, какой у них дизайн в рамках собственно тома, которым они управляют — несущественно, пусть там что угодно создают.
Одна ФС может располагаться поверх нескольких "томов" или устройств без разметки разделов. При этом, что пришло в голорву на всидку:
1. Более быстрые устройства могут использоваться в качестве буфера доступа к более медленым;
2. Запись динамически балансируеться между устройствами по их пропускной способности;
3. Выбирает размер своих секторов в зависимости от размера секторов устройств включенных в ФС;
4. Динамическая репликация/востановление при возникновении событий подключения/отключения и ошибок ввода/вывода на блочном устройстве;
Если всё это не подподает под "На деле ФС должна знать особенности носителя", то мне странно...
PD>А вот если они с физическим диском напрямую работают — это уже нечто иное.
iSCSI/файл/программный RAID?
По твойму если файловая система не шлет SCSI команды прямо в шину — то она не знает особеностей блочного устройства поверх которого работает?
С каких пор IOCTL_DISK_GET_DRIVE_GEOMETRY_EX/IOCTL_DISK_GET_CACHE_INFORMATION/IOCTL_DISK_GET_DISK_ATTRIBUTESIOCTL_DISK_GET_CLUSTER_INFO и т.д. противоречат Руссиновичу?
Здравствуйте, m2l, Вы писали:
PD>>Я с их внутренним устройством незнаком, поэтому хочу лишь задать вопрос. Верно ли, что они напрямую работают с физическим диском (то есть осуществляют ввод-вывод по CHR или логическому номеру сектора) ? Или же они это делают все-таки через драйвер физического диска, а сами занимаются только своими структурами в рамках того раздела, который отведен этому тому на физическом диске ? m2l>Они делают это через драйвер блочного устройства, которым не обязан быть физический диск.
Так и в NTFS не определено, что там ниже. Там потенциально может быть все, что угодно. Например, драйвер томов, который реализует RAID-5.
m2l>Одна ФС может располагаться поверх нескольких "томов" или устройств без разметки разделов. При этом, что пришло в голорву на всидку:
Есть и Windows. RAID5, stripped.
m2l>1. Более быстрые устройства могут использоваться в качестве буфера доступа к более медленым;
Вот о таком в Windows не слышал.
m2l>2. Запись динамически балансируеться между устройствами по их пропускной способности;
Кем ? Вот это основной вопрос. Драйвером ФС (ZFS etc.). или все же драйвером блочного устройства ? В Windows это есть, но занимается этим драйвер физического диска или драйвер томов. Например, если ниже зеркало, то драйвер томов при чтении может решить , с какой половины зеркала читать, чтобы было быстрее, и передать запрос драйверу физического диска, указав ему, с какого диска читать и по какому номеру логического сектора(ов)
m2l>3. Выбирает размер своих секторов в зависимости от размера секторов устройств включенных в ФС;
Видимо, под своим сектором ты понимаешь здесь не сектор HDD, который всегда 512 байт, а нечто иное. Если это единица размещения файла, то в NTFS это называется кластером. Об этом речь ? Если да, то уточни — это при создании ФС или же во время работы динамически. Первое, очевидно, есть в NTFS , о втором не слышал, если такое там есть — дай ссылку, если можешь, было бы интересно узнать.
m2l>4. Динамическая репликация/востановление при возникновении событий подключения/отключения и ошибок ввода/вывода на блочном устройстве;
Э нет, минуту. При возникновении ошибок об этом в Windows узнает драйвер физического диска, и, конечно, сообщит об этом драйверу NTFS. Тот должен предпринять меры, например, произвести горячую замену кластера, но для этого он в своих таблицах делает изменения, но для записи их опять обращается к драйверу физического диска.
PD>>А вот если они с физическим диском напрямую работают — это уже нечто иное. m2l>iSCSI/файл/программный RAID? m2l>По твойму если файловая система не шлет SCSI команды прямо в шину — то она не знает особеностей блочного устройства поверх которого работает? m2l>С каких пор IOCTL_DISK_GET_DRIVE_GEOMETRY_EX/IOCTL_DISK_GET_CACHE_INFORMATION/IOCTL_DISK_GET_DISK_ATTRIBUTESIOCTL_DISK_GET_CLUSTER_INFO и т.д. противоречат Руссиновичу?
Да никак они не противоречат. Они даже из 3 кольца доступны, можешь из своего приложения заняться изменением геометрии разделов. Только вот поступит этот DeviceIOControl , естественно, в диспетчер ввода -вывода после перехода в 0 кольцо, а тот перенаправит его не драйверу NTFS, которому до DRIVE_GEOMETRY и дела нет, а драйверу физического диска, который и займется всей этой геометрией. Ты можешь спокойно сделать этот вызов для диска, на котором вообще нет никакой файловой системы, что , кстати, и делает инсталлятор Windows.
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Так и в NTFS не определено, что там ниже. Там потенциально может быть все, что угодно. Например, драйвер томов, который реализует RAID-5.
Разве ж я спорю?
m2l>>Одна ФС может располагаться поверх нескольких "томов" или устройств без разметки разделов. При этом, что пришло в голорву на всидку: PD>Есть и Windows. RAID5, stripped.
Нет нету. В Windows это как раз на разных уровнях абстракции. Драйвер реализующий программный рейд предоставляет ФС монолитное блочное устройство. В zfs/btrfs эти два уровня слиты в один.
m2l>>1. Более быстрые устройства могут использоваться в качестве буфера доступа к более медленым; PD>Вот о таком в Windows не слышал.
Вообщето ReadyBoost ближайщий аналог. Разница только что в одном случае устройство должно быть частью файловой системы, а для ReadyBoost наоборот не должно.
m2l>>2. Запись динамически балансируеться между устройствами по их пропускной способности; PD>Кем ? Вот это основной вопрос. Драйвером ФС (ZFS etc.). или все же драйвером блочного устройства ? В Windows это есть, но занимается этим драйвер физического диска или драйвер томов. Например, если ниже зеркало, то драйвер томов при чтении может решить , с какой половины зеркала читать, чтобы было быстрее, и передать запрос драйверу физического диска, указав ему, с какого диска читать и по какому номеру логического сектора(ов)
Драйвером файловой системы. В Windows этого нет. Я написал про балансировку записи, а не чтения. И мне интересно какой драйвер томов "может рашить" вместо одновременного чтения одинакового объема разных кусков со всех дисков? Или это теоретическое допушение?
m2l>>3. Выбирает размер своих секторов в зависимости от размера секторов устройств включенных в ФС; PD>Видимо, под своим сектором ты понимаешь здесь не сектор HDD, который всегда 512 байт, а нечто иное. Если это единица размещения файла, то в NTFS это называется кластером. Об этом речь ? Если да, то уточни — это при создании ФС или же во время работы динамически. Первое, очевидно, есть в NTFS , о втором не слышал, если такое там есть — дай ссылку, если можешь, было бы интересно узнать.
Под сектором я понимаю сектор устройства хранения, который не всегда 512 байт. Открываем первую попавшую под руку seagate Archive HDD Data Sheet и смотрим в табличке параметр "Sector (Media/Fmat)". Ты просто немного отстал от современных жеских дисков.
m2l>>4. Динамическая репликация/востановление при возникновении событий подключения/отключения и ошибок ввода/вывода на блочном устройстве; PD>Э нет, минуту. При возникновении ошибок об этом в Windows узнает драйвер физического диска, и, конечно, сообщит об этом драйверу NTFS. Тот должен предпринять меры, например, произвести горячую замену кластера, но для этого он в своих таблицах делает изменения, но для записи их опять обращается к драйверу физического диска.
Это теоретизирования или есть первоисточник? И что значит "горячая замена кластера"?
И мне интересно, а каким ioctl в винде драйвер блочного устройства передает изменение его состояния драйверу фс? Я что-то такого механизма не помню.
m2l>>С каких пор IOCTL_DISK_GET_DRIVE_GEOMETRY_EX/IOCTL_DISK_GET_CACHE_INFORMATION/IOCTL_DISK_GET_DISK_ATTRIBUTESIOCTL_DISK_GET_CLUSTER_INFO и т.д. противоречат Руссиновичу? PD>Да никак они не противоречат. Они даже из 3 кольца доступны, можешь из своего приложения заняться изменением геометрии разделов. Только вот поступит этот DeviceIOControl , естественно, в диспетчер ввода -вывода после перехода в 0 кольцо, а тот перенаправит его не драйверу NTFS, которому до DRIVE_GEOMETRY и дела нет, а драйверу физического диска, который и займется всей этой геометрией. Ты можешь спокойно сделать этот вызов для диска, на котором вообще нет никакой файловой системы, что , кстати, и делает инсталлятор Windows.
Ты думаешь, что драйвер ntfs при монтировании тома не вызвает к примеру IOCTL_DISK_GET_DISK_ATTRIBUTES?
По твойму если файловая система не шлет SCSI команды прямо в шину — то она не знает особеностей блочного устройства поверх которого работает?
Здравствуйте, Kolesiki, Вы писали:
K>Типичный ДОС 6 ставился мной лично... из зазипованного каталога MSDOS. Просто форматил хард с флагом "системный" и распаковывал архив. Всё, готова чистая, безвирусная система.
Нормальный стелс ты так не вылечишь. Особенно Protected Mode реинкарнации, когда вся ОС работает под пристальным наблюдением вируса, не имея никаких средств к его обнаружению.
K>Вирусы — сами видите, от ФС они ну вообще никак не зависят! Дырявое Вендо пропускает всё, что нужно ФБР.
Ты на количество дыр в других ОС посмотри сначала. Вот тебе ленукс. И это только ядро.
Знаешь кто это сказал ?
UNIX, and every system like it, can NEVER be "secure". It doesn't matter how many layers of anti-virus software, "internet worm protection", "firewall" or any other buzzword -- systems like UNIX (including all versions of Linux, Macintosh OSX, and all versions of WinXP) will NEVER be secure.
Именно это и хочу сказать. МИЛЛИОНЫ компьютеров используются в эксклюзивном режиме. Я даже родителей не подпускаю — это ПК, а не общажная сковородка. Отсюда, все эти попытки "надстройки над ДОС" выглядеть каким-то интыпрайзом — смехотворны или по кр. мере нелепы — в домашних условиях ЗА ГЛАЗА хватало именно "MS DOS" со всей её простотой.
Про "быстрое восстановление" вообще забудьте — все ваши настройки, сеттинги программ, твики реестра... всё это летит к чертям, ибо мелким и мягким это лишний гемор.
