понятно. хотя доля таких - не велика. править один вордовый файл несколькими юзерами одновременно - сильно устаревший архитектурный подход. напомню, что сам пакет офиса уже переполз в облако. и уже сам производитель не рекомендует так делать. иначе, есть ненулевая вероятность просто запортить файл, даже если он хранится на надежном файл-сервере. были случаи.
у figma есть серверная часть. как и у git. как и у других подобных корпоративных продуктов. здесь проблем быть не должно.
не очень понятно, зачем в многоюзеровском режиме рассчитывать значение индекса параллельно для разных юзеров. очевидно, что речь идет об учетной системе, где количество юзеров далеко не бесконечно. в warehouse индексы можно сделать, если они вообще используются, на этапе загрузки данных - здесь конкуренция минимальна.
для учетной системы, думаю, лучше рассчитывать значение индекса под блокировкой. это позволит в каждый момент времени иметь только один расчет и сократит длину значения индекса до минимально возможной. потуги юзеров разрулит другой механизм - блокировка ресурса.
а то получается, сначала вели разговор про 1 бит на вставку и меньше, а потом - бах и 25 бит timestamp на вставку, и то не факт, что 2 юзера в одну и ту же миллисекунду не вставят свои значения. хотя, вероятность, конечно. не большая. но по закону подлости в промышленной системе она наступит.
из недавних моих исследований следует, что при нагрузке 5-10 запросов в сек на операцию, блокировки справляются очень хорошо. особенно, если их очень правильно сделать. но это уже другая история😄
а че sys.com то не сработал? все-равно компилировал исходники, надо было проверку на версию dos отключить перед компиляцией. вроде, оно там все от mbr-а до файлов загрузки переносит.
чего вы кипятитесь? я вам на мозоль наступил? вы расставили акценты совсем не туда. Вы упираете на безразмерность потока. И говорите о том, что ничего не вечно и все конечно.
Поток данных - это просто концепция. Ну получит отправитель в какой-то момент ошибку и что? Отправка то все-равно идет блоками. Т.е. периодически клиент может получать ответ. Данные устаревают и теряются. Обычное дело.
Акцент нужно было делать на то, что файлы в ос сейчас хранят НЕ структурированную с точки зрения ос информацию. А предлагается хранить структурированную, много более сложную.
Но все это все-равно хранится внутри одного файла.
Идея была в том, чтобы существенно усилить этот механизм. По тем направлениям, о которых рассказал. А вы все твердите про бесконечны поток. Можно на уровне ОС заменить все файлы вот такими хранилищами, откуда будет удобно доставать тот или иной тип ресурса.
Волшебства в мире нет и я это понимаю не хуже вас.
Нужно обращать внимание на более практические темы, а не вдаваться в утопии.
Новые веяния- это очень хорошо. но скорее, речь шла об известном в linux утверждении.
Но!!! Никто не заметил маленькую хитрость? Много позднее Торвальд исправил это изречение на "все есть файловый дескриптор". Уже даже по этой причине фраза "все - есть файл" - устарела.
А "знатоки" тут с пеной у рта доказывают обратное. Казино никогда не проигрывает?
Спасибо всем за комментарии.
ps вспомнил, что кто-то таки упомянул фразу торвальда. Прости, друг, подзабыл.
уточните, на файловом дескрипторе или сокете? например, винда не рассматривает сокет как файловое устройство. там свое api чтения и записи в сокет. более того, в сокетах винды появились события. это-то кае укладывается на файловый ввод-вывод?
про io_uring и aio- ничего не знаю, не знаток архитектуры линухов. но если они древние, то почему древние?
не увидел, где я сказал, что мне oob не нравится. я сказал, что через файловый ввод-вывод нельзя протащить oob данные. это фишка только сокетов. с какого перепугу все решили, что файловый ввод-вывод так умеет?
ну так используется 2 дескриптора, а не один. пример не показателен. потому что внутри механизма существуют блокировки на параллельное использование каждого файлового хендла. А в вашем примере блокировка не сработает ввиду другого хендла.
ну, нередкость открыть 40 окон в браузере. каждое окно содержит ленту. если делать хендл на каждый элемент ленты, да еще те, которые скрыты вне экрана (а мы не знаем, так ли это, хотя такое- плохой паттерн), то легко вылезти за лимит хендлов.
любой поток винды, использующий com открывает скрытое окно, минимум одно. выяснил случайно. в винде есть функция переключения активных десктопов. она не работает, если в потоке было создано хоть одно окно. из потока, работающего с com объектами она тоже не работает. приходится запускать чистый поток и переключать оттуда. но эта фишка нигде в msdn не описана. отсюда - вывод: винда сама использует эти хендлы даже в вашем потоке, а не только в системных. и сколько из них она использует - фиг знает.
про хендлы: опытным путем проверял только хендлы кучи памяти и графические. но возможно, это на поток, а не на процесс. глубже не копал.
Проблема не была озвучена, потому что ее нет. Цель статьи - не описание проблемы и тем более вариантов ее решения.
Вы когда-нибудь видели такую поделку? смотришь на нее с одной стороны - видно одно слово, смотришь с другой - появляется совсем другое слово.
Точка зрения важна. Она формирует идею, которая потом воплощается в реализации.
Смотря на проблему хранения только с точки зрения файлов, разработка напрочь отвергает иные, иногда интересные и более прогрессивные, варианты реализаций.
Вы видите, какое сопротивление встречает простая идея замены файла стримом? Ну был хендл файла, станет хендл стрима. А чем проблема? Но нет! Нельзя покушаться на святое! Автор нифига не понимает ни в архитектуре и ни в абстрактном мышлении.
И ничего, что сокет только в линухе как-то совместим с файловыми операциями, а винда не рассматривает сокет как файловый дескриптор. Да класть на винду и мак! "Сокет- это файловый дескриптор!" - громогласно провозглашает линуксовод. Даже не пытаясь вникнуть в суть и природу этого сокета.
Криптооперации есть и в ядре. Но мне очень сложно представить, что имея на входе криптооперации 10 байт строки 'аааа...', на выходе получаем 15 байт билиберды - это какая-то файловая операция. И это часть механизма ядра.
Еще там есть виртуальная память. которая тоже складируется на диск. Без файловых хендлов. Совсем. Это для вас новость?
Если уже на то пошло, доля файловых операций в любом драйвере, любой программе начинается от 10—15%. А все остальное что? Реализация паттернов проектирования (по современным представлениям так должно быть): фабрики и фабричные методы, стратегии и фасады, синглтоны и машины состояний и т.д. Где здесь файловый ввод? Нету его там. Только где-то в играх доля файловых операций может подняться до 45%. Ну еще файл-сервера.
Автор "прыгает" в попытке показать несколько разных примеров. Т.е. что это не единичный случай. А не оттого, что где-то колет.
Очевидно, что просто мысли автора до вас не дошли по какой-то причине. Но как есть..
? уважаемый, какой ioctl в tls? я могу еще допустить мысль, что tls-не часть ядра линуха и ее тупо по этой причине не замечают. но виртуальную память не заметить в ядре - просто невозможно.
неофитом вы назвали человека, проработавшего 35 лет в разработке и аналитике it. возможно, вы чего-то не поняли? такая мысль вас не посещала?
комментируют те, кто хочет. никто никого не заставляет и тем более не собирает.
fifo и сокеты - это НЕ КЛАССИЧЕСКИЕ файлы. вы читаете не внимательно. в той же винде сокет не рассматривается как файл. только линух пытается работать с сокетами как файлами. классический файл имеет размер. точка.
разницу уже показал, но вы упорно ее не замечаете. ваш пример - это хафдуплекс. вы дуплексный пример мне покажите при работе с сокетами через файловые хендлы. коментировать вашу ссылку по этой причине нет смысла.
вы можете в какой-нибудь файловой системе никса поместить часть видеофайла на локальный hdd, а часть - в облако? ну или хотя бы в другую файловую систему на другом физическом диске того же компа? если спросите зачем, значит комменты вы не читали. или читали не внимательно. повторяться не буду.
на уровне ядра: поясните мне, пожалуйста, каким образом файловый ввод-вывод относится к виртуальной памяти?
про documentum - на вкус и цвет. однако, такая система есть и стабильно продается. ваш доход выше, чем у компании, продающей documentum? ну так и держите свое фи при себе
т.е. oob сокетов вы тоже причисляете к файловым механизмам?? а в каком толмуде написано, что по одному ФАЙЛОВОМУ дескриптору можно передавать параллельные потоки данных в одну сторону? А где написано, что файловые дескрипторы могут использовать дуплекс (одновременную передачу в разные стороны)? а где сказано, что при файловых операциях данные могут изменить длину и состав (tls и архивирование)?
не многовато ли нагрузок вы накладываете на понятие файла?
ну, ладно, а виртуальная память у вас тоже через файлы работает? это базовый механизм ядра.
банальная описка. смешно видеть снисходительные отзывы "гуру" абстрактного мышления. вы сами за деревьями леса не видите. столько примеров привел и ни одного контр-аргумента по теме.
такие попытки были. но бд не справились с объемами. практически все мега-хранилища документов терабайтных объемов используют бд только для хранения ссылок на файловую систему и метаинформации типа наследования документов. сами доки хранят в фс ос. что конкретно там произошло я не в курсе, но с тех пор попытки поутихли.
впрочем, я тоже недоумеваю, поскольку хранить терабайты документов обычному юзеру и не надо. и современные бд вполне могут хранить все файлы с машины среднестатистического пользователя.
возможно, тут действуют какие-то штатовские законы о конкуренции. т.е.получится, что какая-то одна бд получит конкурентное преимущество.
нет, речь о том, что вы покупаете дорогущий медиасервер. а завтра контора-разработчик помахала вам ручкой и забила на техсуппорт. и вы идете покупать следующий дорогущий медиасервер. я не предлагаю решение, а всего лишь указываю на проблему
вспомните принципы файлового ввода-вывода. сперва открывается файл с каким-то именем. всегда! это либо реальное имя файла, либо файла-устройства.
при открытии получаете дескриптор файла, который используете для операций записи и чтения.
виртуальная память работает совсем по-другому. сам процессор (на примере intel) поддерживает специальные структуры-таблицы gdt и ldt, которые описывают страницы-куски памяти дескрипторами (записями) этих таблиц. в дескрипторе есть бит- загружена страница в ram или выгружена на диск. когда ваша прога обращается к куску памяти по адресу, она использует не только адрес, но и селектор, в который помещен номер дескриптора gdt/ldt. например прочитать байт по ds:[edi]. в edi содержится смещение байта от начала области памяти. а сам физический адрес памяти проц определяет по номеру дескриптора в ds, затем лезет в gdt/ldt и оттуда определяет физический адрес начала блока памяти, который складывает со смещением из edi.
далее процессором происходит попытка чтения по рассчитанному адресу. ввиду того, что дескриптор пометил блок памяти выгруженным, генерируется аппаратное исключение(int). обработчик этого исключения разгребает проблему: определяет, что страница памяти выгружена и ее можно загрузить. освобождает кусок ram(возможно, выгружая другие страницы памяти), подгружает нужный блок с диска и возвращает управление на адрес кода, который читал этот байт. т.е. команда проца как бы рестартует заново с новым состоянием системы. теперь чтение байта проходит успешно.
Вот этот механизм очень похож на файловый ввод-вывод? Да даже не рядом..
понятно. хотя доля таких - не велика. править один вордовый файл несколькими юзерами одновременно - сильно устаревший архитектурный подход. напомню, что сам пакет офиса уже переполз в облако. и уже сам производитель не рекомендует так делать. иначе, есть ненулевая вероятность просто запортить файл, даже если он хранится на надежном файл-сервере. были случаи.
у figma есть серверная часть. как и у git. как и у других подобных корпоративных продуктов. здесь проблем быть не должно.
спасибо, интересно.
не очень понятно, зачем в многоюзеровском режиме рассчитывать значение индекса параллельно для разных юзеров. очевидно, что речь идет об учетной системе, где количество юзеров далеко не бесконечно. в warehouse индексы можно сделать, если они вообще используются, на этапе загрузки данных - здесь конкуренция минимальна.
для учетной системы, думаю, лучше рассчитывать значение индекса под блокировкой. это позволит в каждый момент времени иметь только один расчет и сократит длину значения индекса до минимально возможной. потуги юзеров разрулит другой механизм - блокировка ресурса.
а то получается, сначала вели разговор про 1 бит на вставку и меньше, а потом - бах и 25 бит timestamp на вставку, и то не факт, что 2 юзера в одну и ту же миллисекунду не вставят свои значения. хотя, вероятность, конечно. не большая. но по закону подлости в промышленной системе она наступит.
из недавних моих исследований следует, что при нагрузке 5-10 запросов в сек на операцию, блокировки справляются очень хорошо. особенно, если их очень правильно сделать. но это уже другая история😄
не существует единого значения G на земле. на экваторе - одно значение (9.82), в других широтах - другое (до 9.78).
pi*pi=9.86 так что на земле нет места с таким g?
а че sys.com то не сработал? все-равно компилировал исходники, надо было проверку на версию dos отключить перед компиляцией. вроде, оно там все от mbr-а до файлов загрузки переносит.
чего вы кипятитесь? я вам на мозоль наступил? вы расставили акценты совсем не туда. Вы упираете на безразмерность потока. И говорите о том, что ничего не вечно и все конечно.
Поток данных - это просто концепция. Ну получит отправитель в какой-то момент ошибку и что? Отправка то все-равно идет блоками. Т.е. периодически клиент может получать ответ. Данные устаревают и теряются. Обычное дело.
Акцент нужно было делать на то, что файлы в ос сейчас хранят НЕ структурированную с точки зрения ос информацию. А предлагается хранить структурированную, много более сложную.
И все к этому идет. В той же винде для подобных целей уже есть stg хранилища, см. https://learn.microsoft.com/ru-ru/windows/win32/stg/structured-storage-start-page
Но все это все-равно хранится внутри одного файла.
Идея была в том, чтобы существенно усилить этот механизм. По тем направлениям, о которых рассказал. А вы все твердите про бесконечны поток. Можно на уровне ОС заменить все файлы вот такими хранилищами, откуда будет удобно доставать тот или иной тип ресурса.
Волшебства в мире нет и я это понимаю не хуже вас.
Нужно обращать внимание на более практические темы, а не вдаваться в утопии.
Новые веяния- это очень хорошо. но скорее, речь шла об известном в linux утверждении.
Но!!! Никто не заметил маленькую хитрость? Много позднее Торвальд исправил это изречение на "все есть файловый дескриптор". Уже даже по этой причине фраза "все - есть файл" - устарела.
А "знатоки" тут с пеной у рта доказывают обратное. Казино никогда не проигрывает?
Спасибо всем за комментарии.
ps вспомнил, что кто-то таки упомянул фразу торвальда. Прости, друг, подзабыл.
"все - есть файл". виртуальная память В ЯДРЕ - не есть файл или какие-то файловые операции. при этом, виртуальная память складируется на диск.
нарушение в логике не улавливаете? я пытаюсь донести до вас идею, что не все операции с диском, даже в ядре ос - есть файловые.
вы либо троллите меня, либо не очень сообразительны. фраза "все - есть файл" называет операции с виртуальной памятью файловыми. разве нет?
никто ни с кем не воюет, если вы про это? идеальную статью тоже нет смысла писать. тогда никто комментировать не будет?
уточните, на файловом дескрипторе или сокете? например, винда не рассматривает сокет как файловое устройство. там свое api чтения и записи в сокет. более того, в сокетах винды появились события. это-то кае укладывается на файловый ввод-вывод?
про io_uring и aio- ничего не знаю, не знаток архитектуры линухов. но если они древние, то почему древние?
не увидел, где я сказал, что мне oob не нравится. я сказал, что через файловый ввод-вывод нельзя протащить oob данные. это фишка только сокетов. с какого перепугу все решили, что файловый ввод-вывод так умеет?
ну так используется 2 дескриптора, а не один. пример не показателен. потому что внутри механизма существуют блокировки на параллельное использование каждого файлового хендла. А в вашем примере блокировка не сработает ввиду другого хендла.
в том же линухе (и тем более в винде) есть отдельное понятие потока данных. и это не файл. хотя он может быть связан неким образом с файлом.
так что просто назвать файл стримом - уже, де-факто, нельзя. приходится оперировать устоявшимися терминами.
ну, нередкость открыть 40 окон в браузере. каждое окно содержит ленту. если делать хендл на каждый элемент ленты, да еще те, которые скрыты вне экрана (а мы не знаем, так ли это, хотя такое- плохой паттерн), то легко вылезти за лимит хендлов.
любой поток винды, использующий com открывает скрытое окно, минимум одно. выяснил случайно. в винде есть функция переключения активных десктопов. она не работает, если в потоке было создано хоть одно окно. из потока, работающего с com объектами она тоже не работает. приходится запускать чистый поток и переключать оттуда. но эта фишка нигде в msdn не описана. отсюда - вывод: винда сама использует эти хендлы даже в вашем потоке, а не только в системных. и сколько из них она использует - фиг знает.
про хендлы: опытным путем проверял только хендлы кучи памяти и графические. но возможно, это на поток, а не на процесс. глубже не копал.
Проблема не была озвучена, потому что ее нет. Цель статьи - не описание проблемы и тем более вариантов ее решения.
Вы когда-нибудь видели такую поделку? смотришь на нее с одной стороны - видно одно слово, смотришь с другой - появляется совсем другое слово.
Точка зрения важна. Она формирует идею, которая потом воплощается в реализации.
Смотря на проблему хранения только с точки зрения файлов, разработка напрочь отвергает иные, иногда интересные и более прогрессивные, варианты реализаций.
Вы видите, какое сопротивление встречает простая идея замены файла стримом? Ну был хендл файла, станет хендл стрима. А чем проблема? Но нет! Нельзя покушаться на святое! Автор нифига не понимает ни в архитектуре и ни в абстрактном мышлении.
И ничего, что сокет только в линухе как-то совместим с файловыми операциями, а винда не рассматривает сокет как файловый дескриптор. Да класть на винду и мак! "Сокет- это файловый дескриптор!" - громогласно провозглашает линуксовод. Даже не пытаясь вникнуть в суть и природу этого сокета.
Криптооперации есть и в ядре. Но мне очень сложно представить, что имея на входе криптооперации 10 байт строки 'аааа...', на выходе получаем 15 байт билиберды - это какая-то файловая операция. И это часть механизма ядра.
Еще там есть виртуальная память. которая тоже складируется на диск. Без файловых хендлов. Совсем. Это для вас новость?
Если уже на то пошло, доля файловых операций в любом драйвере, любой программе начинается от 10—15%. А все остальное что? Реализация паттернов проектирования (по современным представлениям так должно быть): фабрики и фабричные методы, стратегии и фасады, синглтоны и машины состояний и т.д. Где здесь файловый ввод? Нету его там. Только где-то в играх доля файловых операций может подняться до 45%. Ну еще файл-сервера.
Автор "прыгает" в попытке показать несколько разных примеров. Т.е. что это не единичный случай. А не оттого, что где-то колет.
Очевидно, что просто мысли автора до вас не дошли по какой-то причине. Но как есть..
? уважаемый, какой ioctl в tls? я могу еще допустить мысль, что tls-не часть ядра линуха и ее тупо по этой причине не замечают. но виртуальную память не заметить в ядре - просто невозможно.
неофитом вы назвали человека, проработавшего 35 лет в разработке и аналитике it. возможно, вы чего-то не поняли? такая мысль вас не посещала?
комментируют те, кто хочет. никто никого не заставляет и тем более не собирает.
fifo и сокеты - это НЕ КЛАССИЧЕСКИЕ файлы. вы читаете не внимательно. в той же винде сокет не рассматривается как файл. только линух пытается работать с сокетами как файлами. классический файл имеет размер. точка.
разницу уже показал, но вы упорно ее не замечаете. ваш пример - это хафдуплекс. вы дуплексный пример мне покажите при работе с сокетами через файловые хендлы. коментировать вашу ссылку по этой причине нет смысла.
вы можете в какой-нибудь файловой системе никса поместить часть видеофайла на локальный hdd, а часть - в облако? ну или хотя бы в другую файловую систему на другом физическом диске того же компа? если спросите зачем, значит комменты вы не читали. или читали не внимательно. повторяться не буду.
на уровне ядра: поясните мне, пожалуйста, каким образом файловый ввод-вывод относится к виртуальной памяти?
про documentum - на вкус и цвет. однако, такая система есть и стабильно продается. ваш доход выше, чем у компании, продающей documentum? ну так и держите свое фи при себе
т.е. oob сокетов вы тоже причисляете к файловым механизмам?? а в каком толмуде написано, что по одному ФАЙЛОВОМУ дескриптору можно передавать параллельные потоки данных в одну сторону? А где написано, что файловые дескрипторы могут использовать дуплекс (одновременную передачу в разные стороны)? а где сказано, что при файловых операциях данные могут изменить длину и состав (tls и архивирование)?
не многовато ли нагрузок вы накладываете на понятие файла?
ну, ладно, а виртуальная память у вас тоже через файлы работает? это базовый механизм ядра.
банальная описка. смешно видеть снисходительные отзывы "гуру" абстрактного мышления. вы сами за деревьями леса не видите. столько примеров привел и ни одного контр-аргумента по теме.
такие попытки были. но бд не справились с объемами. практически все мега-хранилища документов терабайтных объемов используют бд только для хранения ссылок на файловую систему и метаинформации типа наследования документов. сами доки хранят в фс ос. что конкретно там произошло я не в курсе, но с тех пор попытки поутихли.
впрочем, я тоже недоумеваю, поскольку хранить терабайты документов обычному юзеру и не надо. и современные бд вполне могут хранить все файлы с машины среднестатистического пользователя.
возможно, тут действуют какие-то штатовские законы о конкуренции. т.е.получится, что какая-то одна бд получит конкурентное преимущество.
нет, речь о том, что вы покупаете дорогущий медиасервер. а завтра контора-разработчик помахала вам ручкой и забила на техсуппорт. и вы идете покупать следующий дорогущий медиасервер. я не предлагаю решение, а всего лишь указываю на проблему
вспомните принципы файлового ввода-вывода. сперва открывается файл с каким-то именем. всегда! это либо реальное имя файла, либо файла-устройства.
при открытии получаете дескриптор файла, который используете для операций записи и чтения.
виртуальная память работает совсем по-другому. сам процессор (на примере intel) поддерживает специальные структуры-таблицы gdt и ldt, которые описывают страницы-куски памяти дескрипторами (записями) этих таблиц. в дескрипторе есть бит- загружена страница в ram или выгружена на диск. когда ваша прога обращается к куску памяти по адресу, она использует не только адрес, но и селектор, в который помещен номер дескриптора gdt/ldt. например прочитать байт по ds:[edi]. в edi содержится смещение байта от начала области памяти. а сам физический адрес памяти проц определяет по номеру дескриптора в ds, затем лезет в gdt/ldt и оттуда определяет физический адрес начала блока памяти, который складывает со смещением из edi.
далее процессором происходит попытка чтения по рассчитанному адресу. ввиду того, что дескриптор пометил блок памяти выгруженным, генерируется аппаратное исключение(int). обработчик этого исключения разгребает проблему: определяет, что страница памяти выгружена и ее можно загрузить. освобождает кусок ram(возможно, выгружая другие страницы памяти), подгружает нужный блок с диска и возвращает управление на адрес кода, который читал этот байт. т.е. команда проца как бы рестартует заново с новым состоянием системы. теперь чтение байта проходит успешно.
Вот этот механизм очень похож на файловый ввод-вывод? Да даже не рядом..