Комментарии 154
на as/400 существовала операционная система с идеологией «все есть объект». т. е. вместо файлов данные хранились прямо в БД и этим данным можно было сопоставить некие функции и методы их обработки.
А БД хранилась как?
Упрощенно можно сказать, что она очень глубоко интегрирована в операционку.
Это мейнфрейм от IBM, где вместе всё поставляется сразу - и железо, и ОС, и БД - DB2.
Мейнфрейм в корпусе tower :-)
СУБД интегрирована в ОС. Классная была система!
Это не мейнфрейм, а мини-эвм.
OS/400 представляет собой виртуальную машину, в которой выполняется байт-код. В результате аппаратура там давно уже не имеет ничего общего с исходной System/38 (сейчас это процессоры POWER), но код, написанный в те годы, выполняется без перекомпиляции.
Очевидно в стриме. В дополнение получаем неограниченный размер БД
Не знаю конкретно за as/400, но некоторые СУБД умеют работать напрямую с сырыми разделами дисков. Прослойка в виде файловой системы им не нужна, а в кэширование и журналирование они умеют лучше универсальной ФС.
Oracle так умеет. Называется Oracle ASM (Automatic Storage Management).
MS Тоже так умеет
Да даже мускул так умеет (для InnoDB). Ну или как минимум умел когда я последний раз с этим разбирался.
ASM — это другое. ASM позволяет работать с ненадёжными дисками, дублируя запись на несколько дисков на уровне самой СУБД. Так-то Oracle всегда ставили на какой-нибудь мощный RAID, а для Exadata сделали ASM. Ну и без экзадаты она доступна.
А работа с сырыми устройствами была сделана задолго до ASM.
Firebird так умеет.
аппаратные решения часто оперируют безразмерными потоками данных, т. е. стримами
По мне, так все у вас притянуто за уши. Безразмерные они пока есть безразмерной устройство хранения, а их нет :). Пока есть устройства хранения будет файл, или как там его назовут.
про идею со снепшотами потока - читайте ниже. нужно мыслить "ширше и ширее"?
пример с as/400 показывает, что существуют альтернативы. файл просто привычнее, т.к. с ним вы работали всю жизнь.
ровно также упирались бухгалтеры, когда им вместо калькуляторов ставили компьютеры.
По мне так все что вы придумываете это логические обманки. Все что нас окружает имеет границы, даже скорость света. Может Вселенная безгранична, но мы не знаем.
Все ваши стримы ограничены. В любом случае вам надо буде задать ему размер. И где то хранить т.е. нужно имя и т.п., чтоб отличать от других. Вот вам и файл.
Сколько данных можно отправить в /dev/null? Какова длина /dev/urandom?
Конечно, можно расчитать значение из времени существования самого быстрого из компьютеров при условии что он всё время существования пишет (читает) эти сущности. И объявить это постоянно растущее значение размером. Но это не совсем так.
Можно сказать что всё имеет имена, но не всё имеющее имя - файлы.
давайте еще раз резюмирую. даже если трактовать фразу "все есть файл" как "все состоит из файлов", а разница, согласитесь, есть, то это - все-равно не так.
файловый ввод вывод не поддерживает дуплексные операции. сокеты-поддерживают. ускорение в 2 раза не является причиной для перехода на дуплексный обмен вместо файлового?
stdin, stdout и stderror- это стрим, искусственно разбитый на 3 файловых хендла. был бы дуплекс, потребовался бы один хендл. в winapi, например, количество системных хедлов ограничено в районе 64к или менее на процесс. делить это число на 2 или 3 в реальных условиях не есть хорошо. именно по этой причине в delphi ушли от графических оконных хендлов в визуальных компонентах. то есть, скроллбар в окне винды имеет свой хендл субокна, а в delphi есть только хендл всего окна. скроллбар отрисовывается внутри основного окна. т.е. проблема количества хендлов не надумана мной.
виртуальная память ядра ни разу не является файловой операцией. даже по той причине, что она дробнее файла и действует на уровне страницы памяти. каждая страница, сгружаемая на диск не имеет своего имени файла. и то, что в той же винде оно хранится в своп-файле тоже ничего не означает. потому что этих файлов может быть несколько на разных дисках. где-то из драйвера виртуальной памяти все это дело пишется в некое место, условно зарезервированное за файлами свопа. файл свопа нужно организовать только затем, чтобы на это место никто ничего другого записать не мог. и заметьте, пишется своим способом, а не файловым вводом-выводом ос.
бд предоставляют альтернативный вариант организации хранилища, нежели файлы. т.е. можно выделить бд целый том и она будет его использовать своим образом. как-то много ранее я сравнивал производительность db2 с хранилищем из файлов и с хранилищем на томе. с разгромным счетом файлы проиграли.
в указанных случаях где тут файловый ввод-вывод? в 1-нет, во 2ом- 3 файла и программа ими управляющая, извините, это не чисто файл. в 3-ем опять нет файлового ввода-вывода.
и что же я придумал? от нас скрывают правду, Карл..
файловый ввод вывод не поддерживает дуплексные операции. сокеты-поддерживают.
Не силен в технической части. Предполагаю, что это техническое ограничение, если взять HDD, то такое сделать сложно. А дуплекс сокетов поддерживается не за счет буферизации?
и то, что в той же винде оно хранится в своп-файле тоже ничего не означает
Виртуальная память - это не бездонная бочка, а конкретное место с конкретным размером. Как вы там логически это разбиваете не важно.
выделить бд целый том и она будет его использовать своим образом
Хорошо назвали файл - БД, что от этого поменялось? БД оптимизирована для быстрого доступа - хорошо. Это все равно файл. Вас смущает стандартный способ ввода-вывода? Ну так он же не на пустом месте возник, а из-за технических ограничений. Пока нет чего то другого так и будет и логические придумки тут не помогут. Вам надо хранить информацию, надо ее находить как это организовать?
вспомните принципы файлового ввода-вывода. сперва открывается файл с каким-то именем. всегда! это либо реальное имя файла, либо файла-устройства.
при открытии получаете дескриптор файла, который используете для операций записи и чтения.
виртуальная память работает совсем по-другому. сам процессор (на примере intel) поддерживает специальные структуры-таблицы gdt и ldt, которые описывают страницы-куски памяти дескрипторами (записями) этих таблиц. в дескрипторе есть бит- загружена страница в ram или выгружена на диск. когда ваша прога обращается к куску памяти по адресу, она использует не только адрес, но и селектор, в который помещен номер дескриптора gdt/ldt. например прочитать байт по ds:[edi]. в edi содержится смещение байта от начала области памяти. а сам физический адрес памяти проц определяет по номеру дескриптора в ds, затем лезет в gdt/ldt и оттуда определяет физический адрес начала блока памяти, который складывает со смещением из edi.
далее процессором происходит попытка чтения по рассчитанному адресу. ввиду того, что дескриптор пометил блок памяти выгруженным, генерируется аппаратное исключение(int). обработчик этого исключения разгребает проблему: определяет, что страница памяти выгружена и ее можно загрузить. освобождает кусок ram(возможно, выгружая другие страницы памяти), подгружает нужный блок с диска и возвращает управление на адрес кода, который читал этот байт. т.е. команда проца как бы рестартует заново с новым состоянием системы. теперь чтение байта проходит успешно.
Вот этот механизм очень похож на файловый ввод-вывод? Да даже не рядом..
В WinAPI порядка 16M хендлов на процесс, а не 64k. Есть ограничения 10k на виндовые хендлы, но 10k окон - это что-то странное.
ну, нередкость открыть 40 окон в браузере. каждое окно содержит ленту. если делать хендл на каждый элемент ленты, да еще те, которые скрыты вне экрана (а мы не знаем, так ли это, хотя такое- плохой паттерн), то легко вылезти за лимит хендлов.
любой поток винды, использующий com открывает скрытое окно, минимум одно. выяснил случайно. в винде есть функция переключения активных десктопов. она не работает, если в потоке было создано хоть одно окно. из потока, работающего с com объектами она тоже не работает. приходится запускать чистый поток и переключать оттуда. но эта фишка нигде в msdn не описана. отсюда - вывод: винда сама использует эти хендлы даже в вашем потоке, а не только в системных. и сколько из них она использует - фиг знает.
про хендлы: опытным путем проверял только хендлы кучи памяти и графические. но возможно, это на поток, а не на процесс. глубже не копал.
У Вас полная каша
>> stdin, stdout и stderror- это стрим, искусственно разбитый на 3 файловых хендла. был бы дуплекс, потребовался бы один хендл. в winapi, например, количество системных хедлов ограничено в районе 64к или менее на процесс. делить это число на 2 или 3 в реальных условиях не есть хорошо. именно по этой причине в delphi ушли от графических оконных хендлов в визуальных компонентах. то есть, скроллбар в окне винды имеет свой хендл субокна, а в delphi есть только хендл всего окна. скроллбар отрисовывается внутри основного окна. т.е. проблема количества хендлов не надумана мной.
stdin, stdout и stderror -- это как раз таки file descriptor, и они вполне себе дуплексные, в том смысле, что в них можно писать, из них можно читать.
В юниксах количество файловых дескрипторов также ограничено ( https://docs.oracle.com/cd/E23389_01/doc.11116/e21036/perf002.htm , например; для нужного дистра линуха, FreeBSD: https://man.freebsd.org/cgi/man.cgi?limits(1) ) Зачем делить на 2 или 3 -- глупость, читайте https://www.amazon.com/Windows-Internals-Part-architecture-management/dp/0735684189 ). вкратце, в Windows хендлы окон не являютяс объектами ядра, поэтому на этих хендлах нельзя делать то, что можно делать на хендлах от ядра (файлов в том числа) -- ReadFile/WaitForSingleObject, т.п.
Ну вообще, если мы бесконечно получаем и бесконечно отдаём, тогда, судя этой логике, проблем нет.
Вообще просто название "файл" не очень удачное. Есть поток данных, а файл это что-то системное. (но статья странная, согласен)
Понимаете, эти срачи на тему "как должна выглядить ОС", были где-то в начале 2000х на LOR. В частности, упоминалось, что "всё есть файл" реально реализовано только в Plan 9, не в UNIX (см sockets). Что NT (ядро), сделанное Катлером сотоварищи построено на идеологии "всё есть объект". Правда написано на С, поэтому объекты реализованы как в glib. Дальше это было развито в средах выполнения .Net и JVM.
В общем, да, вы безусловно правы, что идеология UNIX стара, что можно что-то новое и интересное забабахать. Но вы тему не изучили ну совершенно, потому что люди забабахивали.
Мимо вас, например, полностью прошла идеология VM/370 "всё есть виртуальная машина". Где каждая программа выполнялась в своей собственной виртуальной машине.
Нет, вот есть у нас файл, скажем con и prn и это обычные 2 разных файла. Откуда у вас взялся размер у con? Да, в физической реализации есть переполнение буфера и куча других проблем, но логический con остается безразмерным файлом, даже если у вас буммага в prn или место на диске кончилось.
Но при необходимости долговременного хранения такие данные должны быть
перемещены в обычные файлы. Что породило такие вынужденные приемы,
как циклическая перезапись файлов в видеорегистраторах. т. е. когда
пространство на диске заканчивается, видеорегистратор затирает самые
старые файлы и на их место помещает новую информацию. И подобные
ухищрения.
А у Вас уже есть какой-то "прогрессивный механизм" обработки видеопотока, который будет распупыживать аппаратное хранилище видеорегистратора? Поделитесь, пожалуйста. Будет очень любопытно почитать.
Не очень понял о чем вы. Но попробую ответить как понял. Здесь же ниже уже озвучил, как можно заменить файл. Через снепшоты потока во времени. Детали см. в комменте рядом.
На самом деле уже есть первая попытка создать безразмерное хранилище контента. Это ipfs. Но здесь есть нюансы. Разрабатывать эту штуку начали парни, которым близок веб-контент. Т.е. возникла потребность в хранении большого именно веб-контента и они подходят к теме именно с позиции веб-технологий. Другими словами, доя целей хранения и передачи поток данных нужно оборачивать в http. Есть еще какой-то fuse метод доступа, но я не в курсе деталей. Возможно, это то, что надо.
Оборачивать данные стрима в веб не всегда хочется. Например, есть у вас корпоративная система наблюдения. Или камера обзора в авто. Зачем вам веб и накладные расходы на кодирование/декодирование в/из base64? Это приводит к прожорливости ОС и ПО в части железа. А сами веб-сервисы- достаточно медленные, с точки зрения их альтернатив.
Думаю, в ОС могла быть какая-то настройка, которая позволяла бы сохранять структура файла(цепочку кластеров или кусков) локально, а сами данные располагать где-то еще. Однако, облачные платформы сейчас предлагают другой подход - клиент отдает весь поток в облако и оно хранит весь поток целиков на своих раидах. Здесь надо думать, что лучше и где какой вариант подошел бы больше. Но я - за универсализацию. Т.е. технические возможности должны быть. А выпиливать их - если со временем этими возможностями никто не будет пользоваться. Для того - можно проводить какие-то публичные опросы.
Почему вариант с облаком не очень хорош? Ну, представьте центр видеонаблюдения крупного ТЦ. Допустим, стоят камеры 5Мп с битрейтом в районе 8-16Мбит/с. Понятно, что пятьдесят камер забъет канал 1гбит/с. А если взять центр видеонаблюдения Москвы? Да он один всю итернет-магистраль забьет. Поэтому, здесь может быть комплексный подход: пока сырые данные пишутся на местные hdd, в параллели они пакуются (я в курсе про аппаратные кодаки 264 и 265, здесь речь скорее о накоплении данных), в параллели же наиболее старые данные отправляются в облако. Но стрим-то должен быть один!!! Поэтому, должны быть блоки стрима, сохраненные локально и также должны быть блоки, помеченные как хранимые в облаке. Здесь же я говорю о том, что подобная схема повысит требования к пиковой пропускной способности, но во времени будет оставлять "дыры" для других пользователей той же сети.
Что мы имеем сейчас? Видеорегистраторы дробят стрим на независимые файлы. И хранят также. Но если для видеонаблюдения это допустимо, то для целей видеотрансляций - уже не очень. Напомню, любая видеотрансляция идет с задержкой хотя бы в несколько секунд. Понятно, что каждый видеокадр не летит прямо в сеть. Идет их накопление и потом выстреливают пакетом. Вот эти несколтко секунд кадры и копятся в пакет. В итоге, на клиента нужно загружать какой-то спец.плеер, который сумеет склеить разные файлы. Либо, на клеить сервере, применяя медиасервер. В любом случае, либо накладные расходы на сервере, либо неудобства на клиенте.
Хранение прямо в потоке позволит реализовать достаточно интересные схемы. Например, когда на клиента закидывается схема размещения стрима, затем идет вещание с первого сервера, потом согласно схеме стрима клиент просто переключается на другой сервер, где хранится очередная порция данных. В процессе вещания схему стрима можно дополнять, что удлиняет сам "файл" стрима, простите за каламбур. И это все очень интересно с точки зрения цифрового ТВ (кино/передача по запросу), где разные пользователи могут возжелать разный контент.
Технически, конечно, можно все это реализовать на файлах, но будут оверхеды по производительности и ресурсам. Пример см. пояснения про кластеры тут рядом в комментах.
А как вы будете паковать сырые данные? Не в файлы ли? Так или иначе дискретизировать их придется. И непонятно чем вам так видеорегистраторы насолили, вполне естественный подход, без аплинка вы без удаления старых данных ничего нового не запишете.
кольцевой буфер с таймкодами, размером с доступный объем носителя. фактически закольцованная же аудио/видеокассета, лол. потому что единица выборки - временной интервал отсюда дотуда.
вы, кажется, только что переизобрели HLS...
Поскольку вас вопрос вызвал интерес, давайте попробую дополнить некой фантазией, как могло бы быть в реальности.
Вот у меня есть смартфон, не дешевый. Но я заметил, что 4к видео он пишет не очень заморачиваясь на сжатие. Другими словами, я могу в видеоредакторе это видео подсжать еще раза в два. Правда, потратив какое-то время. Это совершенно точная информация, поскольку я иногда делаю и выкладываю видеоролики.
Допустим, примерно так же работают системы видеонаблюдения - пишут какой-то полусырой контент на диск, не особо утруждаясь его сжатием. это снижает требования к процессору.
Теперь, допустим мы имеем реализацию чистого стрима, т.е. отдаем данные на хранение, не заморачиваясь сколько там свободного места осталось. Что может делать механизм хранения? он пишет на свои hdd сколько может. Где-то при заполнении дисков, допустим, на 90% он параллельно отправляет самую старую часть данных в облако на временное хранение, т.о. высвобождая место на локальных hdd. т.е. концепция "подержи немного, скоро заберу". и так далее до окончания стрима. по окончании стрима он более тщательно запаковывает данные и возвращает из облака ранее отправленную туда часть. при этом, само облако может более качественно поджать эти данные. т.е. назад пойдет меньший обьем. и все уместится на локальный hdd.
замечу, при этом, все время работы стрима и после на локальном hdd присутствует схема хранения стрима и мы точно знаем, где какой кусок находится: часть у себя, часть- в облаке. если не смогли забрать все из облака по причине недостатка места на hdd, просто сигнализируем оператору. но в любом случае, медиасервер может работать с полным контентом отгребая его с hdd или из облака. и это уже проблема оператора проплатить облако на время, пока он не сможет перегнать контент в надежное хранилище целиком.
В итоге, мы имеем схему, где облако выступает буфером пиковой нагрузки при работе медиасервера. Как уже указал, облако можно привлекать не только для хранения, но и обработки данных: сжатия, распознавания номеров и лиц и.т.д. т.о. назад уже может вернуться структурированная информация.
Сейчас подобные реализации, может, и существуют. Но я о них не знаю. Это означает, что они если и есть, то не очень широко известны. И их владельцами могут быть какие-то частные конторы с непонятным будущим.
Более того, сейчас подобные схемы могут быть реализованы в медиасерверах. А они стоят ну очень дорого. Другими словами, вася пупкин не будет покупать такой медиасервер, чтобы сделать свой видеоредактор. Вот о том и речь, что хорошо бы в фс ос ввести хотя бы функции хранения такого контента. И здесь помогли бы существенно паттерны для хранения в стриме. Надо вам хранить видео с 4 дорожками - пожалуйста, открывайте стрим с паттерном таким. Надо вам хранить ресурсы видеоигры - паттерн такой. Нужно вам сохранить ресурсы web-сайта - патерн такой.
Сами паттерны могут определять количество дорожек хранения и их назначения. Например, для игры можно определить дорожку 3-д фигур, дорожку текстур, дорожку звуковых сэмплов и т.д. Сейчас каждый разработчик изобретает свой "велосипед".
И их владельцами могут быть какие-то частные конторы с непонятным будущим.
Т.е. срочно нужно государственное меганадёжное облако с ясным будущим?
бы в фс ос ввести хотя бы функции хранения такого контента.
Так кто ж запрещает? Берете FUSE и реализовываете любую хотелку - хоть заливку в облако, хоть переключение формата видео через fcntl, хоть слияние видеопотоков в один на лету.
та же microsoft не пошла этим путем
А хотели: была такая WinFS в планах...
Ага. Но потом оказалось, что погромистов разогнали, остались только школьники, которых каждый год набирают новых и они способны только переписывать приложения но новый модный UI-фреймворк...
Честно говоря, я никогда не мог понять, почему такая очевидная штука, как реляционная ФС (хотя бы на уровне пользовательских данных) до сих пор не пришла на смену тупым именованным областям диска, которыми являются файлы с костылями типа символических ссылок и внешних индексаторов их имён для ускорения поиска. В 2024 году мы всё ещё адресуемся к файлам через имя и строковый путь, запрещая использовать кучу "служебных" символов, а ведь куда логичней было бы иметь просто уникальный UUID файла с кучей атрибутов (типа контрольных сумм, mime, тегов, "папок" и прочих метаданных) и выкинуть все костыли типа "поиска по диску" и сломанных путей к файлам. Нечто подобное предлагал ещё Джеф Раскин, но проклятое legacy не даёт ничего сделать уже лет 30.
такие попытки были. но бд не справились с объемами. практически все мега-хранилища документов терабайтных объемов используют бд только для хранения ссылок на файловую систему и метаинформации типа наследования документов. сами доки хранят в фс ос. что конкретно там произошло я не в курсе, но с тех пор попытки поутихли.
впрочем, я тоже недоумеваю, поскольку хранить терабайты документов обычному юзеру и не надо. и современные бд вполне могут хранить все файлы с машины среднестатистического пользователя.
возможно, тут действуют какие-то штатовские законы о конкуренции. т.е.получится, что какая-то одна бд получит конкурентное преимущество.
такие попытки были. но бд не справились с объемами. практически все мега-хранилища документов терабайтных объемов используют бд только для хранения ссылок на файловую систему и метаинформации типа наследования документов.
Я подозреваю, что тут как с графами - нет пока хорошего интерфейса на все случаи жизни. Кстати, опыт Python и JSON показывает, что огромное кол-во случаев при условии динамической типизации вполне закрывается буквально двумя структурами: массивом и hashmap.
а ведь куда логичней было бы иметь просто уникальный UUID файла с кучей атрибутов (типа контрольных сумм, mime, тегов, "папок" и прочих метаданных) и выкинуть все костыли типа "поиска по диску" и сломанных путей к файлам.
А потом открывая файловый менеджер вы захотите видеть директорию со своими фотками, например, где всё разложено по годам и событиям, а не бесконечные uuid-ы в одномерном массиве без какой-либо струтуры.
Получается, что теги у вас есть, а поиск вам не нужен?
И 'папки' у вас всё таки упомянуты (т.е. нечто человекочитаемое вам необходимо - какая-то структура) и они хранятся в метаданных файла. А как вы будете выбирать те файлы которые нужно отобразить непосредственно сейчас? Устроите брутфорс на предмет выявления файлов у которых 'папка' соответствует искомой 'папке'? Или нужно будет хранить какие-то индексы?
Вобщем я вижу желание разрушить всё до основания, а потом создать то же самое.
Зачем брутфорс, можно отдельно хранить структуру папок/тэгов, и менять ее при изменении содержимого.
Насколько я вижу проблему, на данный момент путь к файлу - это его единственный и однозначный идентификатор. Но это не всегда правильно, потому что может быть несколько подходов к структурированию. Сейчас это потенциально решается символическими ссылками, но все ещё есть один "истинный" файл.
Если я правильно понимаю предложение с реляционной бд, все что мы видим в проводнике - это символические ссылки на файл. То есть убирается лишний "истинный" путь. Назвать это тэгами как будто лучше описывает структуру, хотя и сейчас можно имитировать тэги, например, папка с ссылками на фотографии "с Олегом" это эквивалент фильтрации по тэгу "с Олегом".
В линуксе есть жёсткие ссылки на файл. Сделайте их на чётные файлы в папке "с Олегом" и положите их в папку "с Олегом чётные". Вот вам будут и теги и индексы и всё, что угодно. Всё уже придумано. А если не хочется использовать весь функционал достаточно использовать только необходимый в конкретной задаче. Зачем ломать работающее?
На самом деле у нас уже есть отдельно хранимая структура - это собственно то, что раньше называлось File Allocation Table - подобие БД, которая, очень упрощая, хранит словарь "путь" -> "указатель на сектор диска". Т.е. "файлы" это же на физическом уровне всё равно просто области данных с адресом доступа по таблице. Но тогда в чём проблема сделать эту таблицу реляционной для пользователя, добавив туда метаданные и избавив его от адресации по путям?
Скажем, если использовать уникальный хэш от файла как его ID, то ушёл бы целый ворох проблем с версиями пакетов, библиотек и прочего - уникальность и наличие файла в системе гарантировались бы прямо на уровне "имени", и без разницы, где он лежит и какие имена носит для пользователя.
То, что пользователи хотят этого, косвенно подтверждается автоматическим отслеживанием изменения пути к файлу в ярлыках (средствами ОС), и всякими macOS Spotlight и Windows Search, которые пытаются вытянуть из файлов метаданные и сохранить их в своих БД поиска. Почему не вынести это на уровень FS? И да, хорошо бы внедрить это на уровень протоколов типа smb/afp к сетевым дискам и этим решить вечную проблему поиска по сетевым дисками.
Сейчас это потенциально решается символическими ссылками, но все ещё есть один "истинный" файл.
Hard links даже в Windows давно уже завезли. Да - в пределах одного тома. Но это несколько равноправных имен у одного и того же файла.
А хотите прикол на тему "открывая файловый менеджер"? Для нас это прозвучит безумно, но опросы в университетах и школах США показывают, что зуммер-поколение практически не пользуется папками - они понятия не имеют, где лежит нужный им файл и всё ищут поиском.
Внезапно... уже :) например https://github.com/yandex-cloud/geesefs - прикидывается POSIX-совместимой FS со (почти) всем что полагается а реально работаем с S3 который объектное хранилище чистое.
Ну и всякие Ceph (который объектное хранилище по сути пусть весьма специализированное) и CephFS (который имитация FS)
Git работает через хеши, но поверх обычной ФС.
Можно ли такое реализовать в файле? Можно, если представить файл в виде
некой стандартной структуры с несколькими направлениями хранения.
Вы не поверите, но в том или ином виде "метаданные" файлов могут храниться в xattrs
А еще есть атрибуты MFT в ntfs. Это вообще структура которая позволяет хранить файл "Под файлом"
Вы берете только частный случай. Вот, смотрите: есть видеопоток, у него есть русская звуковая дорожка, есть английская. В какой-то момент времени организаторы подсуетились и с середины потока появилась испанская звуковая дорожка. К фильму могут прикладываться видео и звук бэкстейджа. Для самого основного потока это все есть метаатрибуты. А не только дескрипторы безопасности, тип кодека, разрешение и пр. как вы считаете.
Вы предлагаете это все хранить в xattrs? Очевидно, что удобнее было бы иметь какие-то отдельные дорожки хранения в общем стриме. На каждой из них хранить свой контент - или видео основного потока или языковую озвучку или бэкстейдж.
Если все хранить в едином потоке, то для той же испанской дорожки в примере выше необходимо переделать на лету часть стрима, что выражается в оверхедах.
Опять же, напомню, не я это понятие придумал. Та же ms уже имеет в ntfs файловые стримы, где данные могут храниться параллельно, но в рамках одного объекта. Надо это лишь "допилить" до нужной кондиции.
Я ничего не предлагаю, это вы говорите, что концепция устарела
Конкретно ваш пример опять же очень легко решается несколькими путями:
Отдельный поток на каждую дорожку. Появилась новая - открылся новый поток. Управление - внешнее, через отдельный поток. Никто не говорил, что поток должен быть один.
Если должен - тоже всё очень просто. Поток в том или ином виде будет содержать метаданные, например данные для обработки следующего кадра в случае видео. Транспортный протокол может (и, вообще говоря, в реальных протоколах будет) содержать возможность для кодирования управляющих данных, в которых можно и данные об изменении кол-ва дорожек передавать, например
Та же ms уже имеет в ntfs файловые стримы, где данные могут храниться параллельно, но в рамках одного объекта.
Вы точно так же программно можете сделать структуру, которая будет в рамках одного объекта объединять столько файловых дескрипторов UNIX, сколько надо.
начну с конца вашего ответа. тогда это будет решение конкретного разработчика. другая контора будет придумывать ровно такой же механизм. и все изобретают велосипеды.
момент второй. файл в ос ограничен по размеру. что делать с дескриптором файла, если в одном из ним закончится место? получается, нужен механизм открытия и закрытия файлов, а также определения свободного места в файле. этого всего можно избежать в концепции потока. аналогия - вы отдаете поток в облако и там оно хранит его в файлах на раиде. но для вас как клиента это поток, а не набор файлов. про файлы вы вообще ничего знать не будете. вы его отдаете, не заботясь о наличии свободного места, не заботясь об открытии новых файлов и ровно также забираете. и теперь альтернативный сценарий - с сервера ютуба, напр., вам идет видео, поделенное на файлы. очевидно, что плеер это все должен как-то собирать. это все оверхеды.
есть еще одно техническое отличие потока от файла. в ос блокировка ставится на файл целиком, а у потока - только на "дорожку" потока, т.е. условно на часть файла.
блокировка части файлов ранее реализовывалась той же ms, но не удачно. потом они вообще отказались от таких механизмов. а в стриме это будет возможно, поскольку дорожка хранения будет физически обособлена от других и связана с ними только логически. на уровне - если начали читать одну, то и вот эту тоже готовь в параллели.
вы его отдаете, не заботясь о наличии свободного места, не заботясь об открытии новых файлов и ровно также забираете
Если вы живёте в мире с бесплатными облаками и соединениями, которые никогда не рвутся, то да.
Но в реальном мире свободное место в облаке может и не заканчивается, но заканчиваются деньги, на которые оно оплачивается. Поэтому в том или ином виде за лимитами следить придётся. Да, это будет не лимит эфемерного "потока", но это будет лимит.
Точно так же, соединения могут закрыться и нужно это обрабатывать. Это очень слабо отличается от открытия/закрытия файлов, т.к. файлы, которые не влезают в оперативку, к примеру, обычно читаются до EOF, и это концептуально тоже самое, что и чтение из потока.
нет, это архитектурно другой подход. в варианте с чистым стримом вы никогда eof не проверяете. просто послали в все. если хранилище не готово, оно вернет ошибку и клиент-программа может ее игнорировать, например. а то может, и вообще не вернет, как в случае с udp. там вообще соединений нет. послал и забыл.
клиент, формируя контент, хочет работать только с ним. т.е. х265 и сотоварищами. вы предлагаете такой клиент нагрузить работой по мониторингу и управлению файловыми ресурсами. Но если мы говорим о коммуникационных слоях, то зачем работу одного слоя перекладывать на другой, более высокий? Это как tcp попросило бы поуправлять своими соединениями верхний протокол http.
задача клиента - сформировать и отправить контент. облачный сервер же не просит поуправлять своими файлами клиента? Так почему же на одной машине вы это допускаете?
т.о. задача формирования и отправки контента должна лежать на медиасервере. а задача управления сохранением этого контента должна лежать на файловом/стримовом сервере. И здесь уже речь о хранении структурированного контента. ну, в теории, оба сервера могут располагаться на одной машине. и сейчас происходит сериализация структурированного контента в один файл. зачем? это оверхеды.
Выше уже писал про фьюз. Здесь то же самое - никакой проблемы брать сырые стримы и представлять их в системе одним файлом в формате, например, mp4 и отдавать бесконечный поток начиная с момента открытия. Точно также нет никакой проблемы переключать на лету звуковую дорожку. Это несколько дней работы программиста с нужным знаниями.
Просто это никому не надо.
Вы перепутали термин "файл", как идентификатор данных и "файл", как физическое место расположения данных.
"Файл" - как идентификатор, это не только место на диске. Это и потоки, и отображение в память и динамическая информация о системе и много чего еще. И это все файлы с унифицированным интерфейсом доступа. Может быть не всегда оптимальным, но всегда одинаковым.
И "файл" - как место на носителе информации. Это конкретное устройство у которого есть и второй вариант доступа, специфичный для соответствующего типа устройств и учитывающий его особенности (блочный доступ, последовательный, потоки в ntfs и т.д.).
во-первых, ничего я не перепутал. называть разные вещи одинаковыми названиями - это называется притягивать "за уши" и костылить. Потому, что и в том и в другом случае доступ к файлу идет через одно и то же api. Не зря же я в сабже указал широко известную фразу: "все есть файл". Она означает, что идеологи никсов сводят и первый и второй ваш случай к одному и тому же понятию. И реализуют через одни и те же механизмы. О том и статья.
Но раз уже такое есть, то - второе:
я сказал о том, что понятие "файл" изначально было введено для хранения данных. Потом придумали ему назначить функцию передачи данных.
Понятие "поток данных" помимо функций хранения и передачи имеет еще одну - "управление потоком". И эта функция очень плохо ложится на файловое api. Рассмотрите пример tls-потока. Здесь есть свой протокол, когда перед передачей данных, необходимо обменяться рядом сообщений, выбрать безопасные алгоритмы и установить общие криптографические ключи и только потом передавать данные. В этом и состоит функция управления потоком для tls. При передаче данных также идет работа над данными - они шифруются и дешифруются. И пытаться это управление впихнуть в файловое api -это получить гибрид бульдога с носорогом. Той же ms удалось сделать общее api ssl/tls, но совместили они его не с файловым api, а с api авторизации. Речь идет о sspi packages и их winapi. Для тех, кто не в курсе: там одни и те же функции используются и для windows авторизации и для организации ssl/tls соединения. Только выбираются разные провайдеры. Но методика вызова функций - одна и та же. Т.е. на этих функциях и реализовано управление потоком. К слову, с win2008 в винде появилось новое выделенное cng api для управления ssl. Т.о. сама ms признала, что предыдущая реализация управления потоком получилась не очень.
Т.о. понятие потока - оно существенно шире, чем понятие "файл".
Вероятно, если попытаться заменить файл стримами о 3 указанных выше функциях, то можно получить интересные решения. Например, рассматривать файл как snapshot потока во времени. Тогда весь стрим можно представить как ряд снепшотов (файлов). Замечу, что именно такую концепцию реализуют некоторые плееры видео, которые умеют проигрывать и склеивать в единое видео несколько последовательно переданных на клиента файлов. А делается это в некоторых видеостриминговых сервисах в целях защиты от скачивания видеофайла целиком.
В итоге, что получится? Условно "бесконечно" длинный файл. Современные файловые системы (фс) уже имеют такую возможность. Но здесь дело уже в том, что фс реализуют это через кластеры. Т.е. для достижения гигантских размеров файлов используются кластеры с бОльшим значением байт в каждом. Стрим же будет это делать более рационально. Опять же, в существующих реализациях каждый файл (как часть стрима) может иметь размер до 4 Гб, соответственно иметь мЕньший кластер. Но за счет объединения нескольких файлов в один стрим получается "файл" существенно бОльшего размера. Почему не оставить файл как есть, а придумывать какие-то "снепшоты" - это отдельный разговор.
когда перед передачей данных, необходимо обменяться рядом сообщений,
выбрать безопасные алгоритмы и установить общие криптографические ключи и
только потом передавать данные
А в чём конкретно с TLS проблема? Управляющие сообщения об установлении TLS подключения передаются через обычные read/write операции, который при работе с потоками слабо отличаются от операций с файлами.
если так, то сама реализация tls выносится из потока вовне. т.е. функция управления уже не принадлежит потоку. это просто другой взгляд на архитектуру.
с вашей точки зрения можно рассматривать поток как класс, расширяющий файл. однако, отличие в том, что поток может иметь несколько "дорожек" - видео, аудио, телетекст и пр. Все это можно передать в как один файл, но возникают оверхеды по работе с искусственно созданной структурой такого файла.
все приводит к тому, что каждый разработчик ПО придумывает свой формат потока в файле. Напр. вордовый файл - это целая бд. Аналогично - сертификат, аналогично имеют свои форматы видеокодаки.
А можно было бы сделать универсальный формат хранения на уровне ОС. И его бы поддержали все. Вот о чем речь.
ps конкретно про tls. он сидит на tcp. если tcp тоже рассматривать как файловую операцию, то возникает такое понятие как oob данные (параллельный поток данных). сейчас этот костыль зарыт в tcp. и эти oob данные нужно еще как-то протащить через криптованные данные tls, где идет учет каждого пакета. т.е. просто как-то там вставить пакет внутрь tls потока не получится. т.о. oob пойдут либо в нешифрованном виде, либо шифровать их нужно как-то отдельно. а соответственно, возникает рядом еще один такой ssl. это все вынуждает не использовать oob, а как-то мудрить со структурой основного потока на более высоком уровне. любая новая структура - это оверхеды на ее создание и парсинг.
tls - это формат представления данных при их обмене между сервером и клиентом.
Вместо TCP можно с успехом использовать другой протокол, файлы или голубиную почту.
с таким подходом вы систему с высоким уровнем надежности не сделаете.
Допустим, у вас ранее был веб-сервис на порту 80. Ныне это считается небезопасным, поскольку данные авторизации и sessionid передаются в открытом виде. И вы решаете приспособить к веб-сервису tls на 443 порту. а на 80 порт просто вешаете редирект на 443.
Что получается? Если ранее вы использовали oob, то теперь - никак. Это раз. И все упирается в концепцию файла-единого потока. К слову, медиасервисы реально открывают несколько соединений для своих нужд. Это я к тому, что их УЖЕ не устраивает концепция единого файла-потока.
И что делать, если ваша система высоко нагружена, а память исчерпалась? отказывать в запросе? я как раз и веду речь, что tls-у нет необходимости держать все поступившие запросы в памяти. Если их слишком много, то часть можно кешировать/сохранить на диск. Получается, что смысл хранения на диске для tls потока - временное кеширование.
Растить память на сервере бесконечно вы не сможете. Такой подход может быть выходом из ситуации. И рассматривать сетевые протоколы только как коммуникационные - это тоже устаревшая идея, имхо.
В качестве еще одного примера приведу http и загрузку по нему на сервер для хранения 10гб-ого видеофайла. Что делает сервер? Он тупо скидывает полученные пакеты в вируальную память, которая может системой сбрасываться на диск, при необходимости. Поскольку когда там придет еще последний кусок - не понятно, а ram нужна здесь и сейчас. И вот когда последний кусок получен и http увидел, что content-length у него сравнялся с фактически полученным, он отдает эту всю виртуальную память куда-то далее, возможно, кусками через ram.
Если вы попытаетесь этот весь файл разместить в ram на все время его получения, количество потенциальных пользователей вашего сервиса сократится до пары десятков при условии размера ram 200—300гб. и это не считается хорошим паттерном.
А http также считается коммуникационным протоколом, как и tls. А по tls идет примерно тот же объем данных, что и по http.
Надеюсь, пример показателен.
В качестве еще одного примера приведу http и загрузку по нему на сервер для хранения 10гб-ого видеофайла. Что делает сервер? Он тупо скидывает полученные пакеты в вируальную память, которая может системой сбрасываться на диск, при необходимости. Поскольку когда там придет еще последний кусок - не понятно, а ram нужна здесь и сейчас. И вот когда последний кусок получен и http увидел, что content-length у него сравнялся с фактически полученным, он отдает эту всю виртуальную память куда-то далее, возможно, кусками через ram.
Не нужно держать в оперативке данные целиком. Нужно сохранять их по мере поступления. Например в файл.
Но здесь дело уже в том, что фс реализуют это через кластеры. Т.е. для
достижения гигантских размеров файлов используются кластеры с бОльшим
значением байт в каждом. Стрим же будет это делать более рационально.
Но ведь потоки, сетевые в частности, тоже имеют сегментацию на разных уровнях. В UDP есть максимальный размер датаграммы (хотя это конечно не совсем стрим), в TCP есть MSS, в IP есть MTU.
разница в том, что mtu вы можете поменять динамически. размер кластера вы не можете изменить в сохранением данных на том же диске. сперва данные нужно куда-то переместить, потом отформатировать фс под новый кластер и потом вернуть данные назад. это и есть оверхеды при работе с фс.
и потом, mtu- это только про функцию передачи, при чем на уровне достаточно низком (много ниже понятия "файл", если в терминах ipfs). как отметил ранее, у потока есть 3 функции - хранение, передача и управление/обработка данных потока. Механизм работы с потоком должен поддерживать эти все 3 функции, а не частями. И они должны быть сынтегрированы друг с другом. другими словами, http из ipfs не может поменять mtu и ему приходится изобретать свой способ паковки данных.
Ох, вьюноша...
Ненавижу давать советы, но тут как бы... В общем, или занимайтесь стримами (в смысле изготовления), или изучите матчасть. Ну у вас же ошибка на ошибке. То логическая, то фактическая.
Еще раз, менять устоявшуюся систему заради трех с половиной видеоблоггеров, никто не будет. Жирно слишком.
И реализуют через одни и те же механизмы
Не механизмы, а интерфейсы. Если бы механизмы были одинаковые, то пришлось бы при чтении файла из оперативной памяти раскручивать у нее шпиндель.
Искал такой коммент перед тем как написать свой такой же :) но теперь нет необходимости писать.
А вообще при прочтении первых строк статьи сразу подумалось о линуксовых /dev /sys /proc и прочих подобных. Автору видимо ещё многому предстоит научиться. Не умеет мыслить абстрактно.
Прежде всего, давайте вспомним, какими важными характеристиками обладает файл?
Размер. Любой классический файл имеет строго установленный и известный размер в произвольный момент времени. К файлам-устройствам вернемся позднее.
Файл хранится на одном логическом томе. Это следствие логической разбивки диска на тома, которые далее размечаются файловой системой. Другими словами, два обособленных куска на 2 физических машинах - это 2 файла.
А если эти характаристики не требовать, то концепция неплохо так живет.
Могу предложить свои характеристики:
В файл можно писать.
Из файла можно читать.
важными для целей статьи. не ерничайте. я знаю, что у файла есть еще имя и атрибуты создания. к данной теме они отношения не имеют. уже раз 5 написал, что чтение из одного файла разнородной информации приводит к необходимости создания структуры такого файла. а для машины - это оверхеды на запаковку и парсинг такой структуры. для разработчика - это все новые виды структур. а мог бы быть единый механизм хранения и передачи разнородного контента.
Т.е. на хранение и чтение стримов в файловой (стримовой?) системе машина ресурсы тратить не будет? Дайте две!
Офигеть, то есть разобрать с пяток чунков в файле (особенно, когда три-четыре, например, аудиодорожки на других языках) и тупо скипнуть их, будет дороже, чем все вышеописанные пляски с бубном? Серьёзно?
Вы, походу не понимаете, насколько прожорливую тварюгу предлагаете взамен. Причем не понимаете фундаментально. Ваша "всё есть поток" как бы не в три порядка требовательней будет. Если не все четыре, или пять. Тут да. Про оверхэд уже речи не будет. Вот жеж.
Да как то наплевать что там думают об этом разработчики от майкрософт.
Вначале хотел возразить примерно то же, что сказал @rsashka, потом дочитал до примера с сокетами, которые кроме Unix-socket и правда не очень укладываются в эту парадигму. Сейчас, наверное, по факту можно считать "все есть API", файл, сокет, url и тп. Пример с xattr вроде только подтверждает, что абстракция "все есть файл" - протекает, тк xattr же не читаются и не пишутся стандартным api open, read, write. Т.е. Некоторые файлы обладают xattr, но сами xattr файлами не являются. Но все абстракции так или иначе "протекают" при подробном рассмотрении. Подход с файлами устройств тех же и STD{IN,OUT,ERR} вроде до сих пор прекрасно работает, да и VFS всякие тоже хороши.
Моя же фраза "все есть API" - это на самом деле тавтология, которая не несёт никакой новой информации. Что толку с этого утверждения, если API разные и какие они никак из этого утверждения не следует? Можно ещё сказать все есть сущность или все есть процесс, а толку? Хотя с идеей "все есть процесс" может и можно поиграться. В таком случае файл на диске выглядел бы процессом, который ждёт обращения и отдаёт данные или принимает, аналогично REST серверу.
ну, api- это всего лишь фасад для механизмов. в принципе, ms реализовала его для вынь в виде com+ и idl-интерфейсов. универсальный апи для всего. это покрывает функции управления и передачи практически на любом уровне. они даже обьектную модель драйверов сделали на подобном механизме.
однако, он не затрагивает вопросы хранения. т.е. здесь еще важно как хранить. в свое время ms ушла от стандартного odbc драйвера к mssql в пользу oledb драйвера. знаете в чем основная разница? odbc хранит данные по записям, а oledb - по колонкам. Оказывается, хранение однородных данных в массивах устраняет оверхеды при хранении данных. По скорости работы разницы я не заметил, но сейчас best practices- это oledb.
т.е.инженеры ms посчитали важным иначе хранить и передавать данные. вот я здесь о том же, но уже для файлов.
а вообще статья была лишь призвана проиллюстрирована, что давно уже не все есть файл. надеюсь, примеров привел достаточно.
Классическое определение файла - это досье, если уж на то пошло.
>> Концепция «все есть файл» — давно устарела
Концепция была и есть "всё есть file descriptor". А что там за ним стоит -- дело десятое. Что сокет, что файл, что в Windows handle объекта ядра, т.п. , а уж дальше высокоуровневая обёртка в stream.
Как мне видится, вы эти слегонца смешали солёное с сухим в заметке.
неть. все есть несколько файловых дескрипторов, обьединенных каким-то одним объектом, в ваших терминах, в общем случае.
целью статьи как раз и было это показать. другими словами, можно было бы упрощенно сказать, что понятие потока данных расширяет несколько файлов. ну потому что удобно в разных дорожках потока/файлах передавать/хранить однородную информацию - или видео или аудио или телетекст. опять же, в фильме есть основное видео и есть бонусное видео. очевидно, что их лучше хранить раздельно для возможности быстрого доступа к обоим.
на dvd они так и хранятся отдельными "дорожками". я говорю о том, что пора бы такое хранение организовать на уровне фс в ос, а не только в cdfs.
вместе с тем, сведение работы с потоком к файловым операциям вынуждает отрывать функцию управления потоком и помещать ее в отдельную библиотеку. что приводит к все новым форматам потоков в файле. а можно было бы иметь один универсальный формат хранения на уровне ос. но наполнять его разным контентом. разницу чувствуете?
Что делать тем разработчикам, которым нужно не аудио дорожки хранить, а, скажем, бинарные деревья и разряженные матрицы? Предлагаемая система обеспечит эффективный способ хранения для них (а для других)? Или же эти разработчики не достойны и пусть сами решают, как упаковать свои данные. Пусть в стриме хранят структуру... файла?
del
Сюда же можно отнести стримы ntfs, которые не признаются файлами разработчиком ОС (microsoft). Это‑ отдельный механизм, у него свой api, свой механизм хранения, стримы в файловом менеджере не видны. т. е. функции ос по работе с файлами эти стримы не видят.
Создайте файл file.txt с любым содержимым
Откройте
cmd.exeи введитеecho text2 > file.txt:streamВведите
notepad.exe file.txt:streamи в блокноте вы увидите заветное "text2" из строки вышеВы удивитесь, но здесь ОС предстааляет "альтернативные потоки данных" именно в виде файла, я записал в них данные как в файл и прочитал как из файла.
Более того, команда dir /r позволяет увидеть все файлы вместе с их альтернативными потоками
Бонус: У альтернативных потоков, как и у файлов, есть размер, который можно увидеть в выводе команды dir /r
согласен, это лишь показывает, что ms давно уже готовится к переходу на стримы. но все вот что-то никак.
Однако! Командами командной строки обычные юзера не пользуются. Не все файл-менеджеры, включая проводник, поддерживают отображение файловых потоков. файловое winapi тоже стримы не видит, их там несколько. Плюс к тому же, здесь мы видим стрим как атрибут файла. И его содержимое предстоит разбирать каждой программе отдельно. Это не очень удобно, поскольку формат файла получается закрытым и никакой сторонний плеер не сможет проиграть видео из такого стрима. Только свой. И невозможно, какой-то стрим показать, а какой-то скрыть. Либо все, либо ничего. Ну так и живет.
Не все современные фс поддерживают понятие стрима. А unix так и вообще стрим выводит в коммуникационный протокол, хотя это давно уже не так: в rfc описывают не только контракт и протокол, но и последнее время начали описывать основы реализации - сервер ДОЛЖЕН или НЕ должен делать то-то, клиент в таких случаях делает -то-то.. Чисто коммуникационный протокол - это контракт +схема взаимодействия. все. А когда вам начинают расписывать состояния клиента и сервера, да еще по маршрутам (напр. в tls по варианту psk или без), то это что ни на есть уже реализация. Не протокол взаимодействия.
И если говорить про паттерны хранения(см. тут рядом в комментах), то у такого стрима (а точнее его дорожки хранения) должно быть api выбора конкретного объекта с этой дорожки. Например, дорожка стрима хранит аудиосэмплы. Должна быть возможность сказать: "а подайте мне вот тот сэмл с перламутровыми пуговицами". Или видео за номером 2. Такого в ntfs и винде сейчас нет. Но! есть подобная фича в структуре pe-файла, к которому можно привязать бинарные ресурсы. Однако, файл имеет конечную длину и размещен на внутреннем носителе. Переместите, скажем, на ftp/http- стримы потеряются.
Сейчас же для каждого аудиосэмпла игры придется делать свой стрим. Или свой файл. Или делать свою БД для этих целей.
Так что стримы ntfs - это лишь полшага. Над ним можно много чего надстроить. но хотелось бы это в виде стандарта в ОС. Тогда отпадет необходимость делать самописные файлы-бд для хранения ресурсов и контента. Это достаточно объемный кусок работы, надо сказать.
Ну и в итоге, не цель статьи была сказать как делать. Цель статьи - озвучить, что файл в настоящем виде исчерпал свой потенциал. Идея многодорожечного стрима дает гораздо больше интересных вариантов для хранения, передачи и главное - параллельной обработки данных.
Вы вводите в заблуждение утверждая, что стримы в ntfs - это какая-то пришлёпка сбоку.
На самом деле, файл в ntfs - это список стримов, и основные данные файла лежат в стриме с именем $DATA. Так что, у любого файла есть минимум один стрим.
Идея многодорожечного стрима дает гораздо больше интересных вариантов для хранения, передачи и главное - параллельной обработки данных
А почему в медиа-файлах аудио и видео дорожки замуксены в один стрим? А для того, чтобы минимизировать операции seek, при проигрывании файла обычно нужны обе дорожки. Конечно, с SSD это менее актуально.
Что породило такие вынужденные приемы, как циклическая перезапись файлов в видеорегистраторах. т. е. когда пространство на диске заканчивается, видеорегистратор затирает самые старые файлы и на их место помещает новую информацию. И подобные ухищрения.
А что не так? Чем это вынужденная мера? Или вы хотите бесконечный поток видео куда-то записать? Пока не изобретут хранилица информации с бесконечной вместимостью - это невозможно
пример фантазии на эту тему я озвучил несколько выше в комментариях, не хочу повторяться. конечно, это не решает полностью проблему циклической записи, но облако поджимать видеоконтент может более качественно, чем ваша локальный видеорегистратор. а заодно распознавать лица и номера авто. а это означает, что вместо 2 недель записей у вас могут храниться 3 на тех же ресурсах. кроме того, проц на клиенте может быть слабее. уже интереснее. вся описанная мной схема сейчас может быть реализована только путем заказной разработки. подобных коробочных продуктов я не видел. хотя я не очень хорошо знаю возможности современных медиасерверов. это очень дорогая игрушка, чтобы в нее просто играться.
но тут дело, скорее, в концепции и программной архитектуре. вот недавно появился, а потом исчез коммент про стандартные консольные потоки stdin, stdout, stderror. прекрасная иллюстрация моей идеи. все три потока составляют один объект "консоль". Файловые дескрипторы, в отличие от тех же сокетов, не способны к дуплексной передаче данных. Иначе бы stdin и stdout реализовали на одном дескрипторе. Другими словами, вы не можете и читать из файла и писать туда одновременно. С точки зрения файла - это бессмысленно и труднореализуемо (блокировки). С точки зрения стрима - очень даже полезно.
Иными словами. стандартная консоль - это НЕ файл. Это 3 файла. И обьект управления над ними. Что и требовалось доказать.
del
А вот такое Вам как?
$ echo "YOUR_MESSAGE" > /dev/{TRANSPORT_PROTOCOL}/{DESTINATION_IP}/{DESTINATION_PORT}
Так себе, потому что только в одну сторону. Вы скажете: "откройте два потока в двух направлениях". Ну тогда уже как-то странно получается, контекст (соединение) один, а файлов нужно два. И плюс еще какие-то костыльные ioctl для управления параметрами соединения.
а в случае tls/ssl иостилами не обойтись. там хендлы сертификатов и ключей нужно хранить, состояние сервера и клиента. и еще кучу мутотени. и непонятно при чем здесь криптооперации, когда файловый ввод-вывод - это что получил, ровно то и отдал. а в криптооперациях даже длина может поменяться, не говоря уже о содержимом.
если все это реализовать через иостилы, то получится корова на бане. это вам говорит человек, который расковырял исходники openssl.
Cat тоже будет работать, так что не так уж и односторонне.
Приведенный выше пример ограничен командой echo которая работает только в одном направлении. Замените команду echo на netcat и у Вас будет двустронний обмен.
Так ведь netcat или socat как раз откроет два дескриптора (stdin + stdout) для взаимодействия с терминалом.
Это свойство терминала, так они были рождены в Unix. По сети netcat установит одно соединение с одним дескриптором. Замените терминал на локальный TCP порт.
По-моему, автор вместо обсуждения тезиса "всё есть файл" почему-то начал обсуждать "всё есть файл на томе", да ещё и добавил "на томе физически ограниченного размера". Неудивительно, что дальше всё пошло наперекосяк.
файлы-устройства, вроде обсудили. том всегда ограничен. даже рассмотрел пример виртуальной памяти и сокетов. привел конкретные примеры, что файлом не является. ну я уж не говорю про объекты без состояния, кои к файловому вводу-выводу вообще отношения не имеют.
и если пайпы можно посчитать за файловый ввод-вывод, то блокировки вы к нему как отнесете?
машину состояний ни разу не делали? ей хранение практически никогда ненужно. если нужно, то это уже процесс.
вы о чем? так что же имеется ввиду под "все"?
Сами придумали, сами опровергли.
Единица хранения в линуксе - это inode, а уж как ваш командный интерпретатор или визуальная оболочка их представит - другое дело.
Ну выше уже накидали панамку про файл дескрипторы и про то, что те же сокеты немного необычно создаются, но дальше это [почти] обычные read/write/close. Так же как и файлы устройств.
А пошло это со времён первого UNIX-а, а никак не Linux-a. Керниган с Ричи придумали такую вещь, как таблица файловых дескрипторов, которая своя у каждого процесса. И первыми тремя дескрипторами у каждой программы были stdin с номером 0, stdout с номером 1 и stderr под номером 2. Вот так вот "всё есть файл" и появилось.
т.е. oob сокетов вы тоже причисляете к файловым механизмам?? а в каком толмуде написано, что по одному ФАЙЛОВОМУ дескриптору можно передавать параллельные потоки данных в одну сторону? А где написано, что файловые дескрипторы могут использовать дуплекс (одновременную передачу в разные стороны)? а где сказано, что при файловых операциях данные могут изменить длину и состав (tls и архивирование)?
не многовато ли нагрузок вы накладываете на понятие файла?
ну, ладно, а виртуальная память у вас тоже через файлы работает? это базовый механизм ядра.
Вы путаете файлы (как их понимает ядро) и inode.
Чем вам, кстати, oob так не нравится? И да, вы можете пульнуть на одном дескрипторе несколько параллельных (асинхронных) операций чтения и записи — через io_uring или более древнее AIO. В винде, кстати, такое было со времён NT4.0, а может и раньше.
уточните, на файловом дескрипторе или сокете? например, винда не рассматривает сокет как файловое устройство. там свое api чтения и записи в сокет. более того, в сокетах винды появились события. это-то кае укладывается на файловый ввод-вывод?
про io_uring и aio- ничего не знаю, не знаток архитектуры линухов. но если они древние, то почему древние?
не увидел, где я сказал, что мне oob не нравится. я сказал, что через файловый ввод-вывод нельзя протащить oob данные. это фишка только сокетов. с какого перепугу все решили, что файловый ввод-вывод так умеет?
Ну ок, ок, rec[v]/send[v] являются спецификациями универсальных read[v]/write[v] конкретно под сокеты и позволяют задать дополнительные параметры, в частности режим OOB. Если хотите, вторые реализуются через первые с опциями по умолчанию. Дальше-то что? От наличия перегруженных функций сокет не перестаёт быть файловым дескриптором.
Нужно лучше курить матчасть против которой ведёшь риторику, и быть дотошным в тезизах, а так статья хорошая, молодец. Покури ещё концепцию "всё есть capability".
Hidden text
Концепция "всё есть capability" (everything is a capability) представляет собой подход к дизайну систем, где основным элементом является понятие "способности" или "права" (capability), которое определяет, что именно может делать программа или процесс в системе. Эта идея фокусируется на безопасности и изолировании, позволяя контролировать доступ к ресурсам на более тонком уровне, чем традиционные модели, основанные на разграничении доступа (например, Unix-подобные права на файлы).
В контексте "всё есть capability":
1. **Определение**: Capability — это ключ или токен, который предоставляет держателю право на выполнение определенной операции или доступ к ресурсу. Важной особенностью является то, что capability конкретизирует и минимизирует права, тем самым предотвращая злоупотребления и ограничивая возможные точки сбоя.
2. **Ресурсы и операции**: В системе, основанной на capabilities, всё, что требует контроля доступа — файлы, устройства, сетевые соединения и даже более абстрактные действия, такие как возможность перезагрузки системы — представляется через capability. Это означает, что для любого действия или доступа к ресурсу существует соответствующая capability.
3. **Делигирование и распространение**: Capability можно передавать от одного процесса к другому, позволяя создавать тонко настроенные цепочки доверия и делегирования прав. Это делает систему гибкой и позволяет строить сложные многоуровневые архитектуры безопасности.
4. **Изоляция и безопасность**: Использование capability обеспечивает естественную изоляцию между компонентами системы, поскольку каждый компонент имеет доступ только к тем ресурсам, для которых у него есть явно выданные права. Это снижает риск несанкционированного доступа и предотвращает множество атак, связанных с повышением привилегий.
5. **Примеры систем**: Некоторые операционные системы и платформы, например, Genode OS Framework или Google's Fuchsia, используют концепции, близкие к идеям capability для обеспечения безопасности и изоляции.
Концепция "всё есть capability" может значительно улучшить безопасность и гибкость системы за счет более точного контроля над тем, кто и как может взаимодействовать с ресурсами системы. Однако реализация такого подхода требует сложного дизайна и администрирования, а также может потребовать от разработчиков и пользователей изменения привычного подхода к взаимодействию с системой.
никто ни с кем не воюет, если вы про это? идеальную статью тоже нет смысла писать. тогда никто комментировать не будет?
Автору бы сначала узнать, что такое файл, перед тем как чего-то писать :) Начинаем с определения, которое дал автор
Прежде всего, давайте вспомним, какими важными характеристиками обладает файл?
Размер. Любой классический файл имеет строго установленный и известный размер в произвольный момент времени. К файлам-устройствам вернемся позднее.
Файл хранится на одном логическом томе. Это следствие логической разбивки диска на тома, которые далее размечаются файловой системой. Другими словами, два обособленных куска на 2 физических машинах - это 2 файла.
На самом деле я чуток польстил, так как до определения автор так и не смог, ограничившись парой непонятных характеристик, которое по большому счету неверны. Первую он опроверг сам, хотя помимо устройств есть fifo и сокеты, которые по очевидным причинам не имеют размера
Про хранение - на самом деле снова мимо от слова совсем. Изначально мы имеем следующую картину мира. Есть дерево подкаталогов, которое стартует от корня (он же каталог "/"). Далее есть дерево и (совершенно незаметно) оно образовано разными фаловыми системами, которые и есть по сути реализация "абстрактного" API ядра. Понятно, физически для реализации доступа к файлу необходимо иметь файловую систему, иначе - ну правда, а как тогда? Причем тут тома и т.д. мне не очень понятно, так как файловые системы могут быть совершенно разные. Могут быть такие, которые действительно предоставляют доступ к данным на диске, который разбит и т.д. Могут быть сетевые, может быть просто память. В целом в рамках данной концепции никто не мешает написать свой драйвер, который добавить в ядро и обращаться к вашим данным как к файлам
Т.е. все есть файл - это не про реализацию конкретных файловых систем, а про концепцию на уровня ядра ОС, которая все (на самом деле нет) так и воспринимает через общее API
Современные программные и аппаратные решения часто оперируют безразмерными потоками данных, т. е. стримами
Тут автор ушел в свою нишевую область, точнее какой-то мини мирок, где весьма вероятно часто этим и оперируют. Возможно. Но я по секрету скажу, что в реале это крайне редко, если не сказать почти никогда :)
Идеологи linux скромно обходят этот вопрос стороной.
How to open a TCP/UDP socket in a bash shell (xmodulo.com) - вас не затруднит прокомментировать. Мне просто лениво вспоминать пароль к еще пока бесплатному аккаунту в облаке, поднимать там машинку и проверять. Просто вы то точно знаете, целу. статью написали
Дальше я ничего уже комментировать не буду, разве что с трудом сдержал рвотный порыв возле слова documentum
fifo и сокеты - это НЕ КЛАССИЧЕСКИЕ файлы. вы читаете не внимательно. в той же винде сокет не рассматривается как файл. только линух пытается работать с сокетами как файлами. классический файл имеет размер. точка.
разницу уже показал, но вы упорно ее не замечаете. ваш пример - это хафдуплекс. вы дуплексный пример мне покажите при работе с сокетами через файловые хендлы. коментировать вашу ссылку по этой причине нет смысла.
вы можете в какой-нибудь файловой системе никса поместить часть видеофайла на локальный hdd, а часть - в облако? ну или хотя бы в другую файловую систему на другом физическом диске того же компа? если спросите зачем, значит комменты вы не читали. или читали не внимательно. повторяться не буду.
на уровне ядра: поясните мне, пожалуйста, каким образом файловый ввод-вывод относится к виртуальной памяти?
про documentum - на вкус и цвет. однако, такая система есть и стабильно продается. ваш доход выше, чем у компании, продающей documentum? ну так и держите свое фи при себе
fifo и сокеты - это НЕ КЛАССИЧЕСКИЕ файлы. вы читаете не внимательно. в той же винде сокет не рассматривается как файл. только линух пытается работать с сокетами как файлами. классический файл имеет размер. точка.
Ну вы тогда либо крестик снимите, либо трусы наденьте :) Концепция "все есть файл" (которая выросла из *nix систем) используется не там, где "файл" - это классический файл.
Вы довольно таки странно выглядите, когда:
не понимаете концепцию
ограничиваете ее, не очень понимая зачем, и что вы делаете
после ваших вводных обнаруживаете что она не работает
Я не спорю, что ВАША реализация концепции "все есть файл" действительно ущербна и отжила свое :) Но слаба богу, люди, которые придумали *nix, создали другую концепцию с тем же именем :)
Вы можете рассматривать, не рассматривать - это лично ваше дело. Но, весь мир от этого не поменяется, и концепция тоже :)
Кстати винда вроде и не пыталась играть в подобное :)
вы можете в какой-нибудь файловой системе никса поместить часть видеофайла на локальный hdd, а часть - в облако? ну или хотя бы в другую файловую систему на другом физическом диске того же компа?
Ну не повторяйтесь, вы и так написали достаточно, чтобы развеять все сомнения. Я думаю, что вы сами не очень понимаете, зачем и как это делать :)
И как я писал, ваш уютный нано мирок - это не все ИТ :) И даже не один процента одного процента
на уровне ядра: поясните мне, пожалуйста, каким образом файловый ввод-вывод относится к виртуальной памяти?
Вы сами то поняли. что спросили? Вот и мне интересно, как связана загадочная "виртуальная" память (кстати а что это с токи зрения ядра) и файловый ввод/вывод, он же read/write (я надеюсь вы тут про API).
Хотя если вам нужна хоть какая-то связь - /proc :) Но зачем - я так и не понял
"все - есть файл". виртуальная память В ЯДРЕ - не есть файл или какие-то файловые операции. при этом, виртуальная память складируется на диск.
нарушение в логике не улавливаете? я пытаюсь донести до вас идею, что не все операции с диском, даже в ядре ос - есть файловые.
вы либо троллите меня, либо не очень сообразительны. фраза "все - есть файл" называет операции с виртуальной памятью файловыми. разве нет?
виртуальная память складируется на диск
Какая "виртуальная" память??? Конечно, ядро оперирует процессами - нежданчик, да? Также ядро, как и любая программа имеет свою область памяти и даже несколько. Как и процессы
Вы просто не понимаете сути концепции, и более того, совершенно не желаете читать что вам пишут "от слова совсем"
Концепция "все есть файл" реализована как я вам написал и мне не лениво повторить
есть корень, он же "/"
все обьекты в файловом дереве - файлы
конкретная реализация обращения к чему бы то ни было (память, диск, раздел на диске, сокет, ...) реализована с помощью кокнретной файловой системы (для виндовозников упростим до слова "драйвер")
никто не запрещает дополнить абстрактную реализацию конкретной файловой системой (как пример, таже /proc, которая позволяет получить доступ к "внутреннему" знанию ядра о процессах в виде файлов
API стандартизировано, что позволяет использовать ЕДИНЫЕ вызовы для любого объекта, который доступен через файловое дерево посредством вызова реализации системного API конкретной файловой системой
Так как мир *nix'а огромен, человечество наплодило немеряно реализаций файловых систем
Если вам к примеру очень хочется представить любой объект в виде файла, то никаких проблем нет. Пишете свою реализацию файловой системы и добавляете как модуль
----------------
По сути еще в 70е люди совершенно спокойно использовали dependency injection и не только :)
Это вообще забавная тема, когда сейчас модными словами называют все тоже самое, что использовалось и тогда, просто никто не придуимал, что это надо назвать особенным образом
И кстати тот факт, что все это отлично работает и живет до сих пор под капотом огромного числа решения говорит от том, что концепция легко и непринужденно пережила своих создателей
я пытаюсь донести до вас идею, что не все операции с диском, даже в ядре ос - есть файловые
Я не знаю, что вы мне пытаетесь донести. Сорян, я первые программы под *nix писал еще в конце 90х, когда винда была нашлепкой над Досом и только пыталась как-то от него отделиться
Просто вы совершенно почему-то думаете, что ядро написано только с помощью open/close/read/write, а это не так :) Поэтому кому и что вы тут пытаетесь донести - я даже не знаю
По изучению статьи, пришел к выводу, что автору надо "модно, стильно, молодежно", в самом плохом смысле этой речевки.
И да, я тоже согласен, что надо на деле это будет трём с половиной калекам от видеоблоггерства. При просто невразумительно огромных затратах на разработку и внедрение, и буквально астрономических затратах на работу.
Предлагаю слегка подправить терминологию и на этом успокоиться. Для неофитов файл следует называть обьектом. Файловый дескриптор - указателем на обьект. open() и close() - это конструктор и деструктор. read() и write() - вызов стандартных методов взаимодействия. ioctl() - способ вызова кастомных методов для заданного обьекта. Обьекты можно клонировать и наследовать (dup() и dup2()). Вот вам обьектная модель. Всё, расходимся.
? уважаемый, какой ioctl в tls? я могу еще допустить мысль, что tls-не часть ядра линуха и ее тупо по этой причине не замечают. но виртуальную память не заметить в ядре - просто невозможно.
неофитом вы назвали человека, проработавшего 35 лет в разработке и аналитике it. возможно, вы чего-то не поняли? такая мысль вас не посещала?
комментируют те, кто хочет. никто никого не заставляет и тем более не собирает.
какой ioctl в tls
В смысле? А вы сначала поднимите tls, не используя ioctl (ну т.е. ручками, начиная с создания tcp сокета)
Хочу поинтересоваться, причем тут TLS вообще ? Это протокол верхнего уровня, реализуется как на дескрипторах, так и поверх любой другой низкоуровневой технологии потоково омбена данными.
Идею "файлы давно устарели" я слышу последние 25 лет, если не более. Но пока что чего-то более разумного и простого в применение не придумано. Тут в пример приводили OS/400 с её объектной моделью. Я имел честь постоять рядом AS/400 и посмотреть как люди с этим куском г@вна маются (точнее, маялись - списали её нафиг лет 15 назад). Спасибо, лучше уж с файлами, чем такое.
PS: OS/400 (IBM i) это виртуальная машина типа Java или Inferno (только в Inferno идея "все есть файлы" возведена в абсолют) и там под низом тоже есть файловая система и уши AIX-а (это такой Unix от IBM) торчат изо всех щелей.
Когда разрабатывали ядро Windows NT примерно также думали:
[Cutler] expressed his low opinion of the Unix process input/output model by reciting "Get a byte, get a byte, get a byte byte byte" to the tune of the finale of Rossini's William Tell Overture.
Если применить подход автора к изложению материала, то становится непонятно, в чем собственно проблема. Не устраивает концепция файлов с унифицированным интерфейсом обращения к ним? Ок, значит данный инструмент не подходит для решения вашей задачи. Очевидно, что вам виднее, как каким способом нужно реализовать хранение объектов и обращение к ним в вашем случае. А на этом самом месте уже вызывает удивление то, что автор вместо предложения концепта нового решения пишет о том, что нужно "пилить прогрессивный механизм". В результате всё выглядит как "мне где-то колется, сделайте что-нибудь".
Судя по смешению понятий и скачков с одной трактовки понятия файла к другой производная точки стояния автора на кривой Даннинга-Крюгера имеет сильно положительное значение.
Проблема не была озвучена, потому что ее нет. Цель статьи - не описание проблемы и тем более вариантов ее решения.
Вы когда-нибудь видели такую поделку? смотришь на нее с одной стороны - видно одно слово, смотришь с другой - появляется совсем другое слово.
Точка зрения важна. Она формирует идею, которая потом воплощается в реализации.
Смотря на проблему хранения только с точки зрения файлов, разработка напрочь отвергает иные, иногда интересные и более прогрессивные, варианты реализаций.
Вы видите, какое сопротивление встречает простая идея замены файла стримом? Ну был хендл файла, станет хендл стрима. А чем проблема? Но нет! Нельзя покушаться на святое! Автор нифига не понимает ни в архитектуре и ни в абстрактном мышлении.
И ничего, что сокет только в линухе как-то совместим с файловыми операциями, а винда не рассматривает сокет как файловый дескриптор. Да класть на винду и мак! "Сокет- это файловый дескриптор!" - громогласно провозглашает линуксовод. Даже не пытаясь вникнуть в суть и природу этого сокета.
Криптооперации есть и в ядре. Но мне очень сложно представить, что имея на входе криптооперации 10 байт строки 'аааа...', на выходе получаем 15 байт билиберды - это какая-то файловая операция. И это часть механизма ядра.
Еще там есть виртуальная память. которая тоже складируется на диск. Без файловых хендлов. Совсем. Это для вас новость?
Если уже на то пошло, доля файловых операций в любом драйвере, любой программе начинается от 10—15%. А все остальное что? Реализация паттернов проектирования (по современным представлениям так должно быть): фабрики и фабричные методы, стратегии и фасады, синглтоны и машины состояний и т.д. Где здесь файловый ввод? Нету его там. Только где-то в играх доля файловых операций может подняться до 45%. Ну еще файл-сервера.
Автор "прыгает" в попытке показать несколько разных примеров. Т.е. что это не единичный случай. А не оттого, что где-то колет.
Очевидно, что просто мысли автора до вас не дошли по какой-то причине. Но как есть..
«все есть объект»
Новые веяния- это очень хорошо. но скорее, речь шла об известном в linux утверждении.
Но!!! Никто не заметил маленькую хитрость? Много позднее Торвальд исправил это изречение на "все есть файловый дескриптор". Уже даже по этой причине фраза "все - есть файл" - устарела.
А "знатоки" тут с пеной у рта доказывают обратное. Казино никогда не проигрывает?
Спасибо всем за комментарии.
ps вспомнил, что кто-то таки упомянул фразу торвальда. Прости, друг, подзабыл.
Это ещё NT с такой идеологией. У Фантома, всё-таки, ещё персистентность.
А проект живёт.
Современные программные и аппаратные решения часто оперируют безразмерными потоками данных, т. е. стримами
На данный момент нет ни одной системы чтобы она оперировала «безразмерными» потоками данных.
Хотя здесь приврал, есть один пример – такой поток не усрался никому. Его не будут сохранять, его не будут обрабатывать (потому что итог обработки — это опять же - файл).
«потоки сейсмоданных» - архив по землетрясениям - https://ds.iris.edu/seismo-archives/quakes/
«курсы колебаний с биржи» - посмотрите на свои потоки в виде файлов- https://www.nasdaq.com/market-activity/stocks/aapl/historical
То есть даже если взять в качестве примера онлайн трансляцию, то и они в массе своей превращаются в файлы.
Строго говоря, поток может никогда не заканчиваться, пока работает железо и владелец готов оплачивать расходы на электроэнергию и связь. Это первое и основное отличие стрима от файла
Это нифига не отличие. Выше уже я привел примеры как потоки элегантно превращаются в файлы. И да, я хотел бы посмотреть на ученного для которого стрим это стрим, а не поток данных, которые нужно будет воссоздать или еще раз пересмотреть, проанализировать. То есть где-то зафиксировать. И фиксировать он его конечно будет не в файлах, а в потоках :-)
Разработчики Linux подобных систем (думали что) выкрутились, придумав концепцию файла устройства. Здесь весь поток разбивается на сообщения некой длины, не превышающей заранее известного определенного максимального значения.
Я так понимаю, возвращаясь к началу статьи, у автора есть понимание в реализации бесконечных и безграничных мощностях, хранилках, и сетевых устройств? Для сравнения возьмем решения типа Oracle Enterprise Database или Splunk. Вас не смущает что эти продукты свободно могут оперировать террабайтами и петабайтами данных и не просто показать, а еще и обработать и выдать результат анализа. Они не стали придумывать новую парадигму, а обошлись старой, где все есть файл. А ведь Splunk как раз работает в основном именно с потоками. Так же вся бизнес-аналитика Apple Store построена именно на Splunk.
Что породило такие вынужденные приемы, как циклическая перезапись файлов в видеорегистраторах. т. е. когда пространство на диске заканчивается, видеорегистратор затирает самые старые файлы и на их место помещает новую информацию
Насколько я понимаю, это как раз не основная причина циклической перезаписи, основная в том, что в массе своей эти видео не нужны. Более того, в тех же системах видеорегистрации есть возможность сохранения части видео как инцидента. И на минуточку – ОПППА в виде файла.
Смотря в настоящее, я вижу попытки создания подобных объектных систем хранения. Например, documentum — промышленное ПО для хранения документов представлено объектным движком с sql подобным языком объектных запросов. В данном случае, любые данные могут храниться послойно и слои представляют собой иерархию наследования объекта
И какое это имеет отношение к «Все есть файл»? Я тоже могу назвать классы систем, для которых потоки и файлы вообще не являются како-либо величиной – ГИС, СУБД. Но это не отменяет что под ними все же есть как правило БД для которой используются файлы на уровне ФС. Без которых они банально работать не будут. Или может быть произошел прорыв и documentum не использует файлы?
Но в контексте файла и ОС речь нужно вести о вводе такого стандарта хранения файла в ОС и обработку его средствами ОС. Насколько я знаю, та же microsoft не пошла этим путем, а просто сделала механизм стримов рядом с механизмом файлов. Почему — не знаю. Вероятно, посчитали, что так будет удобнее. Возможно, с годами планируют уйти от файлов и перейти на хранение в стримах.»
Потому что это такой мелочный и частный пример, что для него даже мелкомягкие не стали придумывать свой «новый и прорывной стандарт». Скорее всего они даже не рассматривают такую "проблему" как проблему
Конечно, можно что то накостылить, но все попытки примирить файловую систему с современностью, видимо, будут расцениваться как «костыли». Потому что летать это будет «ниже и ближе» альтернативных решений. Стримы дают нам возможность облачного хранения информации. Чтобы то же сделать в файлах, нужно очень сильно переработать концепцию файловой системы
ОК, все плохо, Вы не смогли посмотреть видео на ютубе или где еще современность Вам подставила подножку? Из того, что было написано совсем не выходит, что нужно переработать фундаментальную парадигму в целом семействе ОС (собственно, даже не семействе, а во всех ОС) чтобы в итоге переработки ФАЙЛОВОЙ системы у Вас получилась ФАЙЛОВАЯ система. Это же бред. Опять же маркетинговый бред об облачном хранении стримов не стоит даже об его упоминания в аспекте технической "проблемы". Какие облака или альтернативные решения летают "выше и дальше"?
Опять же в целой статье я увидел только нытье как все плохо в надуманной автором проблеме. Не нравиться – предлагайте альтернативу, делайте форк. Тем более исходный код доступен и открыт путь к звездам.
чего вы кипятитесь? я вам на мозоль наступил? вы расставили акценты совсем не туда. Вы упираете на безразмерность потока. И говорите о том, что ничего не вечно и все конечно.
Поток данных - это просто концепция. Ну получит отправитель в какой-то момент ошибку и что? Отправка то все-равно идет блоками. Т.е. периодически клиент может получать ответ. Данные устаревают и теряются. Обычное дело.
Акцент нужно было делать на то, что файлы в ос сейчас хранят НЕ структурированную с точки зрения ос информацию. А предлагается хранить структурированную, много более сложную.
И все к этому идет. В той же винде для подобных целей уже есть stg хранилища, см. https://learn.microsoft.com/ru-ru/windows/win32/stg/structured-storage-start-page
Но все это все-равно хранится внутри одного файла.
Идея была в том, чтобы существенно усилить этот механизм. По тем направлениям, о которых рассказал. А вы все твердите про бесконечны поток. Можно на уровне ОС заменить все файлы вот такими хранилищами, откуда будет удобно доставать тот или иной тип ресурса.
Волшебства в мире нет и я это понимаю не хуже вас.
Нужно обращать внимание на более практические темы, а не вдаваться в утопии.
И все к этому идет. В той же винде для подобных целей уже есть stg хранилища, см. https://learn.microsoft.com/ru-ru/windows/win32/stg/structured-storage-start-page
Очень странный аргумент. stg - это файловая система внутри файла. То, что директории названы коллекциями, а файлы - потоками, по сути ничего не меняет.
Всё есть файл это удобная концепция. Гораздо удобнее иметь единый интерфейс. Что угодно, хоть память программы, хоть медиа файл. Что-то из них для записи, что-то только для чтения. Некоторые имеют размер, некоторые не имеют размер пока не прочитаешь до конца (например файл на сжатом носителе, имеет реальный и хранимый размер). И это позволяет имеет единые инструменты для работы с файлами. Можно подключить файл как файловую систему - SquashFS, CDFS. Можно подключить сетевой диск как файловую систему - NFS, sshfd. Сетевое хранилище - s3fs, ipfs. Память процесса - procfs. Вполне возможно подключить mp4 файл как файловую систему и внутри неё будут как отдельные файлы, аудио- и видео-дорожка. Про стримы не понимаю в чём разница. Да медиа стрим это не файл, но стримы хранятся внутри файла. Например mp4 файл имеет аудио и видео стрим, но при этом и сам является стримом. Также и один поток может храниться в отдельных файлах-чанках. То есть если смешивать файлы и стримы, то граница стирается. Например каждый файл в архиве это свой поток. Пример про регистратор не верный, потому что регистратор записывает не стримы, а файлы, можно писать раздельно звуковую и видео дорожку, но циклическая перезапись файлов, а не потоков. Ничего не мешает, например прозрачно копировать в архив или в /dev/null. Поэтому гораздо удобнее представить любой файл/поток/устройство/сетевое устройство и получить кучу существующих утилит для работы с файлами, а ее изобретать на каждое понятие свой API и ждать пока появятся утилиты. Всё есть объект это тоже универсальный интерфейс, но такие операционные системы не распространены и меньше инструментов для работы с объектами. И мы не видим всплеска интереса к таким системам, не многие даже смогут назвать пару. Но как размышление статья хорошая.
Прежде всего, давайте вспомним, какими важными характеристиками обладает файл?
Размер. Любой классический файл имеет строго установленный и известный размер в произвольный момент времени. К файлам-устройствам вернемся позднее.
Файл хранится на одном логическом томе. Это следствие логической разбивки диска на тома, которые далее размечаются файловой системой. Другими словами, два обособленных куска на 2 физических машинах - это 2 файла.
В концепции "все есть файл" обе характеристики невалидны.
Навскидку:
Какой "установленный и известный размер" есть у /dev/null или /dev/urandom? На каком логическом томе они хранятся?
Еще и из виндового концепта "дисков" (C:,D: и т.д.) уши растут. С точки зрения FHS нет никаких "логических томов", есть файловая иерархия.
Т.е. берем концепцию "все есть файл" и доказываем, что она "устарела" на примере файловой системы, которая никогда в концепции "все есть файл" и не работала...
Сформулируйте так: "Файл - именованная область данных".
И все срастется, и концепция сразу станет "современной".
На безразмерности памяти когда-то сильно обжёгся Майкрософт... Всё имеет свой размер. Что до файлов, то если признать, что файл, это объект с именем и данными внутри, то тот же поток вполне подходит под это определение. Просто бывают разные типы, виды и семейства файлов :-)))
word‑документ представляет собой базу данных для текстового документа
Странно, что в комментариях до этого никто не обратил на это внимания, но давно ли zip-архив с набором xml стал «базой данных для текстового документа», и что вообще эта фраза в кавычках означает?
А если вспомнить классические doc/xls/ppt -- там файловая система (CFB format) внутри, с иерархическими каталогами, подобием FAT и прочими радостями..
Для начала должно концептуально поменяться железо для, хранения и тогда можно будет отказаться от файловой системы. Никто же не хранит данные в ОЗУ в виде файлов, а почему? Потому что можно быстро иметь доступ к любому байту и файловая система не нужна.
Я не понимаю, почему вы не упомянули простое и ясное определение файла как "Сущность операционной системы обладающая уникальным именем и предопределенными функциями чтения и записи". И все: не добавить ни прибавить. И исходя их этого определения половина вашиз рассуждений уже просто впадает т.к. это уже подробности конкретной реализации.
Автор прыгает по разным уровням абстракции, тем самым загоняет себя в неправильные вывоводы. В общем заигрался в философию, а точнее даже в софистику
Про концепцию "всё есть файл" лучше посмотреть на Plan 9, там это ключевое свойство (вместе с протоколом 9p). А про расширенные атрибуты - на файловую систему BeFS (BeOS, HaikuOS). Там, например, электронные письма выглядят как текстовые файлы, в атрибутах которых вся метаинформация - адреса, блоки mime и пр.
Это первоапрельский пост да? У файла есть конкретное обозначение начала, а конец может и вовсе не обязан быть и один файл прерывается лишь маркером следующего файла.
Концепция «все есть файл» — давно устарела