Здравствуйте, ononim, Вы писали:
O>Потому что блочное устройство, файловая система и СУБД — три разных уровня абстракции, которые хорошо имплементятся именно в таком порядке
Ничего не слышал про возможность работы СУБД вообще без ФС?
Здравствуйте, 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.
