LINUX.ORG.RU

2anonymous (*) (2003-02-07 16:52:16.193): я это здесь уже разъяснял...:) заколебался разъяснять если честно - видимо в начале каждой страницы присобачивать придется...:)
Затраты на write/read/seek в многопоточных FS отличаются от затрат в однопоточных только при очень тупой реализации многопоточности, как говорится "влоб" и в таком случае они составляют 2-3%... При нормальной реализации они конечно есть... Но на уровне погрешности измерения.
Что замедляется - выделение нового кластера из пула свободных, ибо надо обеспечивать не только непрерыность файла (что с использовании многопоточных файлов несколько более сложная задача чем при использовании однопоточных), но также и непрерывность потока... Но зато это компенсируется тем что все логически связанные данные оказываются в одном месте диска (в случае разделения их на отдельные файлы, в случае использования однопоточной FS они лехко оказались бы в разных) что сильно ускоряет доступ к оным... С учетом что практически всегда используется отложенная запись и упреждающие чтение, это приводит к росту производительности дисковой подсистемы.

2Led: Бритва Оккама гришь? Она мне тоже нравится... Ну скажи мне - зачем наплодили разных сушьностей для хранения объектов, всякие FS, DB... Задача одна, а сушьностей - дофига. Ну и накуя?.
На счет DB - я предлагал совсем отказаться от raw partition в больших DB? Я что с дубу по Вашему рухнул??? Я говорил что многопотчные FS подымают планку, за которой использование raw partition становится необходимостью, и не более того... Просто на многопотчных FS можно использовать DB того объема и того уровня сложности, которые уже не лезут на однопоточные FS И при отсутствиеи многопоточных требуют raw partition... Но и многопоточные FS разумеется имеют предел, за котором BD будет вынуждена использовать raw partition...

Irsi
()

2 Irsi

Вдогонку. Поблагодарил за разъяснение и только сейчас собразил как меня обманул "Sir Irsi".

Как это "не надо открывать"? Что эти потоки не такие объекты как и все остальные? То что они открываются все вместе при открытии файла (глупое решение, но с MS станется) или открываются-по-требованию при первой операции с ними не значит, что они не открываются вообще.

Так в этом случае остается вопрос: в чем преимущество в сравнении с opendir? В том, что вместо map vector?

anonymous
()

> Но зато это компенсируется тем что все логически связанные данные оказываются в одном месте диска (в случае разделения их на отдельные файлы, в случае использования однопоточной FS они лехко оказались бы в разных) что сильно ускоряет доступ к оным...

Да, это сильный аргумент. Но для ФС, которая не научилась бороться с дефрагментацией, он вряд ли применим.

P.S. Насчет идеи вы меня убедили, теперь можно начинать цепляться к реализации :)

anonymous
()

s/дефрагментацией/фрагментацией/

... но и родными дефрагментаторами тоже :)

anonymous
()

Irsi, а куда ты делся с ixbt-флейма по поводу создония бухгалтерии?
Классно ты их "развел"! Интересно было прочесть.

PitStop
()
Ответ на: комментарий от Irsi

2Irsi:
>зачем наплодили разных сушьностей для хранения объектов, всякие FS,
>DB... Задача одна, а сушьностей - дофига. Ну и накуя?.
ИМХО, "дофига", потому как для разных задач/данных нужна РАЗНАЯ
их организация хранения/одновления и т.п., а универсального алгоритма не существует!
Думаешь многопоточная ФС и есть тот самый "философский камень"?
Боюсь ты меня в этом не убедишь:)

Led ★★★☆☆
()

По поводу B-tree и линейного поиска: на небольших объемах линейный поиск выгодней, так как вставка и балансировка очень трудоемкие операции. john

anonymous
()
Ответ на: комментарий от Kba3iM0qo

Классные доводы. У меня сразу отпали все сомнения о качестве работы винды с VM :-D

P.S. Мне нравятся системы, которые при полном праве послать на # этого не делают, а дают возможность сделать работу.

asaw ★★★★★
()
Ответ на: комментарий от Irsi

2Irsi:
Про Оккама вспомнил, а про KISS? Впрочем это неудивительно: ты всегда
отвечаешь только на то, что тебе нравится:)
Набор небольших, тщательно отлаженных, проверенных, узко специализированных
утилит/драйверов/сервисов/библиотек, склеенных скриптами/потоками/т.п. ВСЕГДА
лучше и надёжнее, чем статический монстр, который "умеет всё"!
даже если за это приходится платить потерей 1-5-10% производительности... ИМХО:)

Led ★★★☆☆
()
Ответ на: комментарий от Irsi

2Irsi:
в догонку:
ну не бывает гениального гонщика Ф1 и механика/инженера/изобретателя в
одном лице! каждый должен заниматься своим делом: не только кухарка не
должна править страной, но и политик не должен заниматься приготовлением пищи (профессионально)... да и не сможет он:)

Led ★★★☆☆
()

2anonymous (*) (2003-02-07 17:29:15.729): что такое "открытие файла"? Что приисходит после того, как завершился поиск? :) Ну не надо проводить аналогии между тредами программ и потоками данных, это не рпаильно... Это бага перевода...:(
Так вот - (сильно огрубляя, обобщая и местами используя термины ext2 для простоты) после этого создается дескриптор файла, который содержит уникальный цифровой iD файла, который используется для дальнейшей работы с фалом и куча служебной инфы, в число который входит указаль на i-node связанной с файлом. Как я уже сказал выше простейшая реализация многопоточности - это грубо говоря добавление возможности для записи каталога содержать ссылку более чем на одну i-node. Тоже естейственно относится и к дескриптору файла, он содердит не одну ссылку на i-node, не один указатель позиции и т.д., а по одному комплекту всего этого добра на каждый из потоков.
Да, памяти это жрет больше разумеется... Но не стыдно - это при ~35$ за 256Mb RAM на текущий момент? ;)
Да, разумеется - чтения инфы о всех потоках разумеется происходит за один заход в простейшем случае... В теории - можно использовать "отложенное открытие", но не думаю что это будет эффективно...

anonymous (*) (2003-02-07 17:36:07.749): я уже говорил насчет фрагментации в NTFS - это выдумка производителей дефрагментаторов...:) Ну посмотри хоть раз полный отчет когда дефрагментатор орет о том что ситаема сильно фрагментирована...:) Посмотри какие файлы конкретно фрагментированы и сколько их... А потом сравни с общим числом файлов на диске...:)

2anonymous (*) (2003-02-07 17:42:41.522): угу... но в современном мире это неактуально увы...

2Led: разумеется нет - многопоточная FS это удачный компромис на пути полного отказа от FS и переходу к DB как основному и единственному хранилищу объектов...

PitStop: да не интерсно... все равно ничем не кончится...:(

Irsi
()

2Led: блин, просто происходит слияние искуственно разделенных понятий вот и все... Разделили еще в те времена когда майнфремы имели страшную емкость ОЗУ - аж до 16ти мегабайт!!! Знаешь какой объем тогда занимало 16ть мегабайт ОЗУ? ;)
Юникса тогда еще не было даже в плане, а машинка на котором он создавался сама еще разрабатывалась... И планировалсь в ней разумные объемы памяти - 32К 12ти разрядных слов... Правда на той машинке, куда потом юникс быстро перенесли было уже до целых 248Кб и она могла поддерживать толи 16, толи целых 32 АЦ-терминала...
Вот с тех пор мы и живем с хранилищем объектов, спроектированным под такие мощности... Не порали кое-что пересмотреть, а? А то на моем ПДА нынче памяти столько же, сколько на тогдашнем майнфрейме...;)

Irsi
()

to Irsi

" Прости, можно задать глупый вопрос (чиста для проформы, ответ я знаю), где хранятся права доступа в ext2 - в записи каталога или в i-node? То-то... А ведь реализация многопоточности для ext2 это просто добавлении возможности хранить в записи каталога ссылку более чем на одну i-node...:) "

Ты сам-то понял, что сказал? В Unix fs один и тот же файл может быть доступен из разных мест в иерархии директорий. Есть такое понятие DAG... А вся информация о файле, кроме имени хранится именно в inode.

anonymous
()

2anonymous (*) (2003-02-07 18:20:03.628): ну вот - ты и ответил на вопрос с разными правами на потоки одного файла...:)

Irsi
()

Думаю, вопрос в том, что если люди будут использовать open source NT, то все равно ведущей в мире будент microsoft - так как этому open source NT придется идти вслед за microsoft по пятам... если нет, то COOL Очень интересно, что Вы по этомму поводу думаете... Что касается меня, концептуально использую open source НЕ NT - Linux! Концептуально отдаю предпочтение всему open source, даже development tools, даже если они иногда уступают коммерческим. open source - это ЧЕЛОВЕЧЕСТВО, это охват всех вкусов и подребностей и независимость от фирм и коммерции. Поэтому, не знаю очень ли актуален open source NT??? Использовать большое количество NT софта??? may be... только бы не идти на поводу у MS

orik
()

Ирси, opensource лучший способ проверки бредовых идей теоретиков. Те же микроядра - opensource быстро показал, что нафиг они не нужны, и без них прекрасно можно обойтись.

А вот журналируемые fs хорошая штука, но только для больших файловых систем. Если бы потоки давали серьезное преимущество, их бы сделали. И не такие вещи делали. Тот же kde напорядок более сложная задача. Но ради пары приложений, где потоки могли бы чуть-чуть помочь, мешать всем остальным не имеет никакого смысла.

anonymous
()

2 Irsi (*) (2003-02-07 18:07:41.375)
Что верно, то верно. Даже эта хрень подохнет.
А вот мне позарез нужна Система Управления предприятием. А не еще один 1С. Самое печальное, что на Предприятие контора в которой я "пашу" не тянет, даже близко не стояла. А система нужна... задолбали эти "вордовые писюльки" и "эксельные почеркушки" никак друг с другом не связанные. Прав был Antihrist - офис не нужен, ни ОО ни МС. Это зло. Ну, за маленьким исключением...

PitStop
()
Ответ на: комментарий от Irsi

> 2anonymous (*) (2003-02-07 17:29:15.729): что такое "открытие файла"? Что приисходит после того, как завершился поиск? :) Ну не надо проводить аналогии между тредами программ и потоками данных, это не рпаильно... Это бага перевода...:(

Я не разу и не путал. Со своего поста про памятник.

> Так вот - (сильно огрубляя, обобщая и местами используя термины ext2 для простоты) после этого создается дескриптор файла, который содержит уникальный цифровой iD файла, который используется для дальнейшей работы с фалом и куча служебной инфы, в число который входит указаль на i-node связанной с файлом. Как я уже сказал выше простейшая реализация многопоточности - это грубо говоря добавление возможности для записи каталога содержать ссылку более чем на одну i-node. Тоже естейственно относится и к дескриптору файла, он содердит не одну ссылку на i-node, не один указатель позиции и т.д., а по одному комплекту всего этого добра на каждый из потоков.

Вопрос. А может запись в каталоге содержать ссылку на каталог, содержащий несколько записей с ссылками на inode? Единообразный интерфейс - великая вещь. Хотя людям, всю жизнь проработавшими с ФС, где _не_было_ нормальных каталогов, а был findfile, трудновато признать, что каталог - тоже файл.

> Да, памяти это жрет больше разумеется... Но не стыдно - это при ~35$ за 256Mb RAM на текущий момент? ;)

Не стыдно. Если n-кратное увеличение объема памяти требуется для обеспечения возможностей пяти процентов приложений. Не отрицая полезность для некоторых приложений такой ФС я не думаю, что ее стоит монтировать как /. Это всего лишь частное решение с ограниченной областью применения. Как xfs с acl - кому надо, тот поставит. Мне, например, оно не нужно.

> Да, разумеется - чтения инфы о всех потоках разумеется происходит за один заход в простейшем случае... В теории - можно использовать "отложенное открытие", но не думаю что это будет эффективно...

Но "открытие" все-таки есть? Так и не надо рассказывать про его отсутствие, а просто сказать про цену открытия.

anonymous
()

Кстати, отношение каталог-файл - это многие-ко-многим, а файл-поток - один-ко-многим. Поэтому их нельзя, в общем случае, уподоблять - появляются операции возможные в одном варианте и невозможные в другом: разделение файла между директориями или получение файла по потоку, например.

anonymous
()
Ответ на: комментарий от anonymous

> Кстати, отношение каталог-файл - это многие-ко-многим, а файл-поток - один-ко-многим. Поэтому их нельзя, в общем случае, уподоблять - появляются операции возможные в одном варианте и невозможные в другом: разделение файла между директориями или получение файла по потоку, например.

Простите, но что такое "многие-ко-многим"? Где вы такое увидели? В Acsess'е?

anonymous
()

2orik: уси-пуси...:) А ты не подумал о том что Linux это всего-навсего подобие коммерческого UNIX(tm)(c)AT&T (ныне принадлежит калдере если не ошибаюсь)... Значит все дружна равняемся на... кому там принадлежат права на UNIX(tm)? Caldera (AKA SCO Group) если не ошибаюсь? ;)

2PitStop: ну антихрист вообще не глупый мужик, даром что весьма радикален...:)

2anonymous (*) (2003-02-07 19:12:40.352): ну частично тебе уже ответил другой ананимус...:) Принципиально то, что потоки дают _унифицированный_ интерфейс для хоть какого-то структурирования данных в файле. История развития приблизительно такова грубо говоря - сначала сваливаем все данные в одну кучу на наситель, потом появляются файлы, потом каталоги, потом - древовидная иерархия каталогов, потом - многопоточные файлы, что будет потом выходи за рамки разговора имхо, но рекомендую посмотреть на AS/400...;) Посмотри сам - очень многие форматы данных пытаются эмулировать в себе возможности многопоточного файла. За примерами далеко ходить не надо - возми например такие популярные форматы как COFF, TIFF... Т.е. многие програмисты тужатся, пытаясь изобразить некой вариант многопоточности в своих форматах, в совершенно разных областях прошу заметить. Дай им многопоточный файл и им это не придется делать, что имхо изрядно сократит кол-во всевозможных форматов для хранения одного и тогоже (хотя первоночальный эффект будет обратным разумеется) и облегчит обмен данными между приложениями различных производителей.
К тому же еще один момент - если много людей делают схожие веши, не лучше ли сделать некий обобщенный интерфейс и включить его в ОС, чтоб облегчить им жизнь? ;)

Irsi
()

2 Irsi (*) (2003-02-07 20:20:44.068)
Да. Не один он тут не дурак. А толку что?
А так хоца! За деньги. За пристойные для небольшой фирмы, а не Предприятия.

ps А с ФС ты не совсем прав ИМХО. Здорово, но так ли это нужно? Как и крутой acl, кстати. Не должно это так строиться. Права там всякие юзерам и всё такое....

PitStop
()

2PitStop: если судить по пальцам, которые здесь многие кидают, то тут программеров жопой жуй и все поголовно если не kernel hackes, то завтра ими станут... А на проверку выясняется что не можем сказать с чего начинается открытие файла в любой ОС...:)
Еще раз - многопоточность сама по себе не дает никаких непосредственных преимуществ, это просто средство, очень удобное средство, для реализации многих полезных вещей, которые без нее либо гораздо сложней реализуются, либо вообще не реализуемы...
На счет ACL и их нужности/ненужности - это имхо классический пример преимущества связки микроядро+многопоточная FS. Нужны тебе ACL - загрузил сервер "file right manager with ACL" - не нужны, отстрелил этот сервер и загрузил "classic (unix-like) file right manager", если все правильно написано то даже перегружаться не придется, просто сделать reopen для открытых файлов...
Да, на всякий случай - здесь "сервер" это не то что многие подумали, это из терминологии микроядерных ОС, чем-то похоже на демона и модуль ядра в одном флаконе. :) Точнее нечто промежуточное... Ну не знаю как обяснить, rtfm короче! :)

Irsi
()

> 2anonymous (*) (2003-02-07 19:12:40.352): ну частично тебе уже ответил другой ананимус...:)

А я уже частично ответил частично ответившему тезке ;) Даже не вдаваясь в споры о существовании отношения "многие-ко-многим" каким образом клиент может не знать к какому каталогу относится файл если доступ к файлу он может получить _только_ через каталог? Короче ответ прост - через какой каталог получили доступ к файлу, тому каталогу он и принадлежит (даже если на него ссылаются несколько каталогов - это проблемы их, а не файла).

> Принципиально то, что потоки дают _унифицированный_ интерфейс для хоть какого-то структурирования данных в файле. История развития приблизительно такова грубо говоря - сначала сваливаем все данные в одну кучу на наситель, потом появляются файлы, потом каталоги, потом - древовидная иерархия каталогов, потом - многопоточные файлы, что будет потом выходи за рамки разговора имхо, но рекомендую посмотреть на AS/400...;)

1. Многопоточные файлы _полностью_ определяются через каталоги/файлы. Вы же вроде упирали на лучшую производительность, а не качественные различия?

2. Вот про _унифицированный_ интерфейс подробнее. Где можно почиать стандарт (хотя бы драфт)?

> Посмотри сам - очень многие форматы данных пытаются эмулировать в себе возможности многопоточного файла. За примерами далеко ходить не надо - возми например такие популярные форматы как COFF, TIFF... Т.е. многие програмисты тужатся, пытаясь изобразить некой вариант многопоточности в своих форматах, в совершенно разных областях прошу заметить. Дай им многопоточный файл и им это не придется делать, что имхо изрядно сократит кол-во всевозможных форматов для хранения одного и тогоже (хотя первоночальный эффект будет обратным разумеется) и облегчит обмен данными между приложениями различных производителей.

Ну про это я "частично" ответил svu. В любом случае это можно реализовать как библиотеку.

> К тому же еще один момент - если много людей делают схожие веши, не лучше ли сделать некий обобщенный интерфейс и включить его в ОС, чтоб облегчить им жизнь? ;)

Разумеется _им_ жизнь нужно облегчить. Но не надо "счастье причинять" другим.

anonymous
()

Весело, весело, нечего сказать.
Предлагаю еще одну бредовую идею: а почему бы нам не сделать FS из одного файла a la XML, открыто, удобно, проблему с тредами решаем.
P.S. Касательно микроядра и портирования: Для хорошей портируемости не микрокернел нужен, а Clean Design (син. изящная архитектура, смотреть NetBSD (один SCSIPI чего стоит!!!)).

Avarielf
()

Нет, с точки зрения логики - многопотоковые файлы все таки лишнее, и никакая "дороговизна" open'а тут не аргумент: open _редкая_ операция (за исключением файл-сервера), ну а файл-сервер должен держать структуру каталогов в кэше, и упорядочивать содержимое файла-каталога в дерево на этапе загрузки каталога в кэш. И все! Более того, при введении в файловую систему многопоточности файл-сервер начинает расходовать ресурсы быстрее (или отъедать больше :-))... У вас не файл-сервер??? Тогда я уже написал - open редкая операция.

P.S.: третий день ковыряюсь в W2K DDK... Господи, какая жуть! Ну неужели нельзя было "вбить" DRIVER_/DEVICE_/FILE_OBJECT в этот чертов irp, и отдавать его в единый ioctl_proc?!

no-dashi ★★★★★
()
Ответ на: комментарий от Irsi

>2orik: уси-пуси...:) А ты не подумал о том что Linux это
>всего-навсего подобие коммерческого UNIX(tm)(c)AT&T (ныне
>принадлежит калдере если не ошибаюсь)... Значит все дружна
>равняемся на... кому там принадлежат права на UNIX(tm)? Caldera
>(AKA SCO Group) если не ошибаюсь? ;)
LOL!
Браво!
Вот в этом весь ирси. Воспринимайте его также серьёзно как и это его высказывание :-D
LOL!

asaw ★★★★★
()
Ответ на: комментарий от asaw

Виноват, не ответил на все возражения на мои предыдущие реплики (долго отсутствовал в он-лайне). Но г-н Irsi сделал это в большинстве случаев. Если все-таки кто-то очень хочет получить ответ от меня - можно повторить вопрос.

С точки зрения обсуждаемой темы - vfs linux - высказывание про unix является правдой. Потому как api этой vfs действительно практически тождествен тому самому старому доброму униху (а гарантом этого дела, как я понимаю, является позикс). А вот если бы линух, кроме позикса, расширил бы vfs и добавил _на_этом_уровне_ потоки - может, кто-нибудь бы и был бы доволен. Конечно, под это нужно положить бы многопоточную файловую систему на диске - для начала это могут быть NTFS, маковская fs (вроде, что-то такое к райзеру прикрутить хотели).

А про то, что частый open - это беда серверов - это еще статистически померять надо. Не с дуба же рухнули маковцы, забив в свою систему многопоточность (двухпоточность, спасибо г-ну Irsi за коррекцию).

Про KISS - действительно хороший принцип. Просто его безудержное применение тоже чревато. Кто сказал про "настолько просто, как только возможно, но не проще". Если некий уровень абстракции просто пытается взять минимальный общий набор свойств из возможных реализаций - получается плохо. Посмотрите на awt в java:) И если считать, что vfs должна стремиться к максимальному примитивизму - что ж, можно жить и так. Я очень люблю униховый принцип - мелкоблочное строительство - но доведенный до предела он убивает производительность на корню. Каждый интерфейс имеет свою цену. И, кстати, мне показалось, что тут одни и те же люди защищают монолитные ядра и нападают на многопоточные vfs. Это странно выглядит, господа:) Словом, высокоуровневый интерфейс vfs позволяет решить некоторое количество проблем унификации и производительности, которые в противном случае (в этой дискуссии их приведено немало) приходится решать в user space, при этом многократно дергая существующие системные вызовы и тем самым понижая производительность. Кстати, про мелкоблочное строительство. Кто из присутствующих станет заниматься 3d графикой через corba, если единственный доступный метод - поставить пиксел заданного цвета в заданном месте. А рисовать линии, круги и битмапы kiss не позволяет:)

Да, про то, что opensource доказало несостоятельность микроядерных систем. Это Вы серьезно, коллега? Мы имеем только один ФАКТ: ни одна из mainstream opensource os (которых мы можем пересчитать по пальцам одной руки) не использует minikernel (правда, не знаю, считать ли hurd mainstream). Возможные объяснения (кроме несостоятельности mkos):

- Модель разработки oss несовместима с разработкой mkos.

- Разработчики oss os не обладают квалификацией, необходимой для разработки mkos.

- Конкретные личности, определяющие архитектуру oss os, имеют _личные_ пристрастия, определяющие их решения (и статистика тут не причем - не так уж много этих личностей).

Возможно, можно найти и другие объяснения. Заметьте, я не утверждаю, что какое-то из них истинно (тем более - все). Но из данного факта делать столь однозначный вывод, какой сделали Вы - очень странно. Даже не являясь большим фанатом mkos - я удивлен немало такой предвзятостью...

svu ★★★★★
()
Ответ на: комментарий от Avarielf

Коллега, а вам xpath случайно униховую файловую систему не напоминает? Хотя бы символом разделителя? Если серьезно - мне кажется, если бы кто-то сделал os, в которой vfs + fs давали бы полную поддержку xpath и еще поддерживали типы в духе xschemes, и это все с производительнностью нормальной современной быстрой fs (я уж не говорю про мелочи типа журналов и пр.) - он бы стал богатым и знаменитым очень быстро. Я только боюсь, что это невозможно:)

svu ★★★★★
()

> которые в противном случае (в этой дискуссии их приведено немало) приходится решать в user space, при этом многократно дергая существующие системные вызовы и тем самым понижая производительность.

Ну ведь вроде договорились, что не многократно, а лишь несколько лишних вызовов open. Читать-писать все равно придется.

> Кстати, про мелкоблочное строительство. Кто из присутствующих станет заниматься 3d графикой через corba, если единственный доступный метод - поставить пиксел заданного цвета в заданном месте. А рисовать линии, круги и битмапы kiss не позволяет:)

Имхо аналогия неточна. Моя версия: есть 2d система, позволяющая рисовать линии и дуги. В системе часто рисовались прямоугольники, поэтому их тоже добавили в примитивы. Кто-то обнаружил, что прямоугольники со скругленными углами рисуются недостаточно быстро (в его реализации) и потребовал введения нового примитива. Все бы ничего, но он потребовал _заменить_ старый примитив "прямоугольник" на свой новый и ему все равно, что большинство будут использовать его примитив с 0 радиусом скругления.

anonymous
()
Ответ на: комментарий от anonymous

Ну, да, именно несколько open. Про цену open уже было высказано ранее. Но ведь и всякие структурированные форматы файлов типа pe/coff/elf стали бы читаться несколько легче. Очень возможно, что и тут удалось бы сэкономить на вызовах - за счет отсутствия "перемоток" между разными фрагментами.

Да, аналогии мы можем сочинять долго:) Моя аналогия была к тому, что сознательное уменьшение количества фич системы ниже некоего предела (KISS до предела) приводит к неюзабельным системам. Да, конечно, я имел в виду 2d, а не 3d:) Короче, моя идея: "as simple as possible but not simpler". А Ваш лозунг в студию можно (относительно KISS)? "KISS uber alles"? Да, насчет "большинство будут использовать с 0 радиусом" - это еще посчитать надо. На первых порах - да, конечно. А потом, когда народ разрюхает - будут пользовать. Особенно если форматы системных файлов на это дело завязать.

svu ★★★★★
()
Ответ на: комментарий от svu

> Ну, да, именно несколько open. Про цену open уже было высказано ранее. Но ведь и всякие структурированные форматы файлов типа pe/coff/elf стали бы читаться несколько легче. Очень возможно, что и тут удалось бы сэкономить на вызовах - за счет отсутствия "перемоток" между разными фрагментами.

Уменьшилось бы число lseek за счет того , что пришлось бы хранить контексты не для одного файла, а для нескольких потоков. Потом, если мне не изменияет память в "большинстве операционных систем" бинарники загружаются не через open/read/close, а с помощью различных реализаций mmap, значит нужно будет несколько мапов вместо одного.

> Да, конечно, я имел в виду 2d, а не 3d:) Короче, моя идея: "as simple as possible but not simpler". А Ваш лозунг в студию можно (относительно KISS)? "KISS uber alles"?

Нет мои девизы "Faith no more" и "Гитлер капут" :)

А если серьезно, то своего отношения у меня тут нет, т.к. я и пытаюсь уяснить нужно ли поднимать "порог возможного упрошения" в данном случае. Пока думаю, что цена за предлагаемые удобства великовата. Одно я знаю точно: расплачиваться ресурсами за _возможность_ нельзя, можно только за то чем пользуешься постоянно.

> А потом, когда народ разрюхает - будут пользовать. Особенно если форматы системных файлов на это дело завязать.

Ну откуда такое стремление загнать народ штыками к счастью? :) Если и есть достойный лозунг, то это "Не завязывайся" :)

anonymous
()
Ответ на: комментарий от anonymous

> ничо вы в ОС не понимаете... самая классная ОС -- plan 9. Всем срочно читать! http://ask.km.ru/plan9/

а вот это интересно. никогда не знал, что на постсоветском пространстве есть любители. А еще линки знаешь?

ivlad ★★★★★
()
Ответ на: комментарий от svu

> 6. Different views of the document for different users.

> Points 4+ were never implemented (AFAIK) but they are possible and save some sense in some environments.

Это не совсем так. В HP-UX с security pack (если я не ошибаюсь на счет имени) есть возможность разным пользователям отдавать разное содержимое одного и того-же файла (или вообще не отдавать никакого).

Впрочем, это было до переезда HP-UX на Veritas, и в 11 такого, возможно, больше и нет. Кроме того, я не уверен, что "внутри" оно было реализовано через потоки; более того - скорее всего нет.

Пункты 4 и 5 вытекают из пункта 6 более-менее.

ivlad ★★★★★
()

Господину, который упомянул про количество вызовов lseek():

Взгляните на реализацию. Это _очень_ дешёвый вызов.

Всем и особенно Irsi:

1. Господа, ратующие за многопоточные файлы, вы не учитываете множество связаных с этим проблем. Например, при необходимости передать файлы по сети, нужно этот файл сначала упаковать в поток, а потом грамотно его оттуда вытащить, т.е. как минимум составить и прицепить заголовок со смещениями, и запаковать потоки по очереди. Ну и как вы это видите в реализации и использовании? В виде отдельной утилиты, патча к tar, или как? А ведь мне просто надо сделать 'scp user@host/file .' Есть правда совсем утопичный вариант: поддежка единого интерфейса доступа к потокам файла на всех платформах. Но обсуждать возможность этого -- сущее безумие.

2. Далеко не всем форматам файлов, имеющим несколько потоков, подойдет общая схема доступа с локального хранилища. Например, MPEG4 требует специальной паковки всех потоков в поток октетов для передачи по сети, чтобы фрагменты потоков не слишком далеко отстояли друг от друга.

3. Прочие форматы файлов прекрасно обходятся с со своими нуждами используя библиотеки.

4. Поддержка потоков практически не востребована.

5. Ну хватит уже колесо то изобретать в плане представления файлов!

6. Irsi, взял бы и написал (ну или хотя бы придумал) _приличную_ библиотеку, если уж так неймется. Делов то. lseek-ов жалко?

Weaver.

anonymous
()
Ответ на: комментарий от anonymous

2Weaver

> Господину, который упомянул про количество вызовов lseek():

> Взгляните на реализацию. Это _очень_ дешёвый вызов.

Спасибо, огромное (особенно за господина). Если вы обсужденее прочитали то знаете, что anonymous'ы в моем лице утверждали:

1. Экономия при использовании потоков вместо файлов - величина весьма спорная (и от Irsi я добивался точной цены).

2. В разговоре со svu речь шла о _числе_вызовов_ lseek, а не об их стоимости.

Если вы считаете, меня настолько умственно обделённым, что я не могу найти /usr/src/linux*, то почему вместо подробного описания того, что происходит при вызове lseek, вы предлагаете мне "взглянуть на реализацию"? Вы уверены, что я вообще пойму что такое реализация?

anonymous
()
Ответ на: комментарий от anonymous

2Weaver

> Господину, который упомянул про количество вызовов lseek():

> Взгляните на реализацию. Это _очень_ дешёвый вызов.

Спасибо, огромное (особенно за господина). Если вы обсужденее прочитали то знаете, что anonymous'ы в моем лице утверждали:

1. Экономия при использовании потоков вместо файлов - величина весьма спорная (и от Irsi я добивался точной цены).

2. В разговоре со svu речь шла о _числе_вызовов_ lseek, а не об их стоимости.

Если вы считаете, меня настолько умственно обделённым, что я не могу найти /usr/src/linux*, то почему вместо подробного описания того, что происходит при вызове lseek, вы предлагаете мне "взглянуть на реализацию"? Вы уверены, что я вообще пойму что такое реализация?

Вот видите, я даже Preformatted text от TeX para with quoting отличить не могу ;)

anonymous
()
Ответ на: комментарий от anonymous

Да, нужно было бы реализовать многопоточный mmap. А что тут сложного?:) Шутка.

Гитлер, безусловно, капут. Про faith ничего не знаю - атеист-с:)

Про то, что порог упрощения многонитевые файловые системы поднимают - это правда. Только во многих случаях это оправдано. И, как ОЧЕВИДНО следует из замечаний г-н Irsi об исходном разделении хранилищ на fs/dbms, надо бы его (уровень абстракции) подымать с развитием выч. техники. Т.е. если допустить, что массовой системой станет система раз в 10 мощнее текущих десктопов (по объемам памятей, скорости передачи данных, производительности) - действительно, хорошо бы срастить файловые системы и БД. Кстати, если я ничего не путаю, Мелкософт именно это и хочет сделать в следующих версиях своих ОС. Это не только маркетинговый ход - в этом есть очень серьезный архитектурный резон.

Стремление "штыками к счастью" у советских людей в крови:) Если серьезно, архитекторы ОС должны работать на будущее, а не идти на поводу у консерватизма существующих пользователей и разработчиков. Учитывать консерватизм - да. Но с правом "совещательного голоса". А иначе новые ОС просто не появятся - не зачем. Вот залатают все дыры в Вистлере и линухе - и хватит:) Мне кажется, сейчас работа на будущее вполне оправдывает использование небольших дополнительных ресурсов памяти (дешевых) для поднятия производительности (которой всегда не хватает) и для поднятия уровня абстракции (которое, в конечном итоге, выгодна прикладным программистам).

svu ★★★★★
()
Ответ на: комментарий от anonymous

1. Да, все системные утилиты потребуют модификации. Это правда. На то они и системные. Новые опции придется запоминать. И т.д. А что - Вы думали, выучили tar -xjvf и этого на всю жисть хватит?:)

2. Разумеется, общая схема подойдет не всем. Но если будет хотя бы 80/20 - этого уже будет достаточно.

3. Про то, что user space libs могут решить эту проблему - уже говорили. И про потерю производительности - тоже (не говоря уже про дупликацию кода, если каждый будет делать это индивидуально для себя).

4. Где? В os/vfs, где их нет? Или в os/vfs, где они есть?

5. Почти бессмысленный лозунг в рамках данной дискуссии. Или требует разъяснения.

6. show me the code - безусловно, хорошее требование. Но плохой способ затыкать оппоненту рот:) Мы уже говорили - user-space lib решает проблему плохо. Так зачем писать заведомо плохой код? К тому же - вот напишет г-н Irsi библиотеку, постарается. Кто ее использовать будет? Кто про нее узнает? Наверняка же другой программер из какой-нибудь Австралии, даже если узнает про эту либку, скажет (обуреваемый NIH-синдромом): "Ой, это написал кто-то, кого я не знаю, лучше я напишу это сам". Если же это станет частью vfs - вряд ли люди будут создавать свои версии. Будет единый для всех API, единый стабильный интерфейс и единая его реализация (не зависящая от жизненных перипетий г-на Irsi). Будет СТАНДАРТ де-факто. Чисто организационно - написание г-ном Irsi либки имеет мало смысла (разве что он собирается работать над неким приложением, которое будет активно ее использовать).

svu ★★★★★
()

2svu. Вы уж извените, но не могу с вами согласиться по поводу: "Мне кажется, сейчас работа на будущее вполне оправдывает использование небольших дополнительных ресурсов памяти (дешевых) для поднятия производительности (которой всегда не хватает) и для поднятия уровня абстракции (которое, в конечном итоге, выгодна прикладным программистам).".
Это не выгодно программистам т.к. в на данный момент эти фишки нужны только 5% задачам. Это выгодно производителям харда и ОС - просто напросто наглое высасывание денег.

Зачем??? Задачи решаемые с помощью компютеров очень медленно меняются. Все та же печатная машинка, все тотже калькулятор, все тотже инструмент для подготовки изображений/звука/видео. По сути своей мощностей которые предлагают сейчас уже достаточно для львиной доли всех задач включая работу по созданию реалистичной 3D графики и проч. расчетным задачам. В итоге люди стали меньше покупать/менять железо. Даже софт стали меньше покупать, т.к. текущие уже имеют больше функций чем оно того требует.

Вывод: надо придумать что-то, что позволит поднять планку минимальной производительности. И начинают придумывать микроядро, поточные ФС...

А ведь есть куда расти и без этого! Вот к примеру пользовательский интерфейс основанный на принципах рабочего стола клерка 80-х годов уже во многом себя не оправдывает. Или появление Интернет ставит под вопрос защищенность данных при их глобализации и много прочих действительно интересных и насущных проблем, а так получается придумаем себе сами грабли и будем их обходить.

Ведь никогда при усложнении кода/конструкции надежность не будет повышаться а равно как и стоимость владения.

Korwin ★★★
()

2 svu

Кстати по пункту 2 - а ведь Weaver привел сильный аргумент. Если уж появились файлы, содержащие много потоков, то где гарантия, что этим дело и ограничится? Что не появятся файлы, оптимизированные для хранения MPEG4 и т.п.? Может нужно сразу (революция, так революция) вводить понятие "файл, который пользователь мажет расширить как хочет"?

anonymous
()
Ответ на: комментарий от anonymous

Ответ на это я уже приводил, когда меня спрашивали про xml. Замечательно, но нереально (по производительности и затрате ресурсов). Многопоточные файлы "общего вида" - _реально_ по всем параметрам. Дает пользу для нескольких классов приложений (включая десктопные) - конечно, при последовательном и разумном применении, без доведения "до маразма". Конечно, всегда найдутся приложения (типа mpeg4), для которых этого уровня абстракции будет мало|узко|медленно... Да, физическое хранилище "настоящих" СУБД, возможно, лучше будет делать на "классической ФС" (т.е. vfs в этом месте будет считать, что поток 1 - как константа). А еще лучше - просто на отдельном "персональном" разделе диска. Но это уже обсуждали выше.

svu ★★★★★
()
Ответ на: комментарий от Korwin

ИзвИняю:)

Про 5% задач - это Вы где померяли? Взяли какую-то систему с поточностью на уровне vfs (и без болезней совместимости с допоточными версиями) и набрали статистику на приложениях? Если да - очень интересно было бы посмотреть полный отчет. Если это экспертная оценка - можно привести список экспертов?

Насчет "кому выгодно" - я, как программист, всегда предпочитал высокоуровневый интерфейс низкоуровневому. И интерфейсы своих прог (особенно - либов) пытаюсь "поднимать" насколько можно. Мне кажется, это естественный процесс, естественное желание. Только не надо путать "поднятие уровня абстракции" и "бессистемное расширение", хорошо?:)

Задачи, решаемые микроядрами обсуждались выше. И задача "отбить бабки за новый проц" среди них не значилась. Помнится мне, потоки в файлах на Маке появились, когда ресурсы были еще достаточно дороги и проблемы "куда девать лишние гигагерцы" еще не было. А ведь сделали! И использовали достаточно разумно!

Кстати, про осовремениванье десктопа - многопоточные файлы могут помочь и тут. Посмотрите на то, сколько файлов несет в себе инсталлированое приложение для гнома. Сколько из них могут быть спокойно слиты в одну кучу, потому что по отдельности бессмыслены? Хотя бы .desktop и его .png (в этой дискуссии иконкам везет:). Про защиту - уже обсуждали рассмотрение acl как отдельного потока. Да, еще (и к десктопу и немного к Интернету) - наличие метаданных о документе сделало бы практически ненужными (вернее, значительно более шустрыми и незаметными) такие противные и громоздкие вещи, как fast find/updatedb и прочие индексаторы (в том числе для вещей типа htDig). Согласитесь, что поиск документов по ключевому слову - полезен. А хруст винюковского fast find раздражает многих. А что делать - он офисные форматы разбирает, бедненький...

svu ★★★★★
()
Ответ на: комментарий от svu

> Ответ на это я уже приводил, когда меня спрашивали про xml. Замечательно, но нереально (по производительности и затрате ресурсов).

Да? Жаль - идея действительно богатая. Каталог бы знал как найти файл и передать его дескриптор приложению, приложение бы знало, как получить от файла его специфичный интерфейс, файл знал бы как оптимально для этого с.и. обмениваться данными с диском. Была бы возможность сосуществования разных типов файлов и регистрации новых. Несмотря на возможную тормознутось - после нескольких лет использования такой ФС можно было бы достоверно (а не путем передположений и догадок) сказать какие типы файлов пользуются реальным спросом у приложений.

Мечты-мечты.

> Многопоточные файлы "общего вида" - _реально_ по всем параметрам. Дает пользу для нескольких классов приложений (включая десктопные) - конечно, при последовательном и разумном применении, без доведения "до маразма".

Где работающая многопоточная fs под linux? ;) Где стандарт api этой системы? Где приложения, разумно применяющие её? По _этим_ параметрам многопоточные файлы - "это фантастика".

> Конечно, всегда найдутся приложения (типа mpeg4), для которых этого уровня абстракции будет мало|узко|медленно... Да, физическое хранилище "настоящих" СУБД, возможно, лучше будет делать на "классической ФС" (т.е. vfs в этом месте будет считать, что поток 1 - как константа). А еще лучше - просто на отдельном "персональном" разделе диска. Но это уже обсуждали выше.

Да вопрос в общем-то не в том для всех ли приложений подходит многопоточная ФС, а в том будет ли это гениальное решение, требующие переписывания половины программ и заучивание новых ключей для tar ;), последним или последуют другие?

anonymous
()
Ответ на: комментарий от anonymous

Многопоточные файлы общего вида реальны из следующих соображений:

- известны их реализации (не под линухом) - т.е. известны примерные параметры памяти, производительности ... И эти параметры вписываются в то, что доступно в нынешних системах, в разумные границы требований.

- известны некоторое множество областей применения

По первому признаку xml fs не проходит:)

Новые ключи tar учить придется. И, более того, я могу обещать: "последним" это изменение не будет. И никакое другое - тоже не будет (даже уничтожение tar как явления:). Прогресс неостановим. Изменения будут. Нужно привыкнуть к этому, научиться радоваться этому и, по возможности, влиять на направление изменений в сторону улучшений (ой, не хочу начинать глубокую дискуссию о том, что такое улучшение - увольте, пожалуйста, от этой беды).

svu ★★★★★
()

> - известны их реализации (не под линухом) - т.е. известны примерные параметры памяти, производительности ... И эти параметры вписываются в то, что доступно в нынешних системах, в разумные границы требований.

Ну они (параметры) известны в абсолютных цифрах, а не в относительных - каковы были бы эти параметры параметры для аналогичной ФС без многопоточности.

> - известны некоторое множество областей применения

Но не известно большого количества приложений в этих областях применения, активно использующих возможности многопотоковости (поправьте если известно). И не проводилось сравнения, как эти же приложения работают на ФС без поддержки многопотоковости.

> По первому признаку xml fs не проходит:)

Правильней было бы её называть ФС, монтирующей файлы :)

> Новые ключи tar учить придется. И, более того, я могу обещать: "последним" это изменение не будет. И никакое другое - тоже не будет (даже уничтожение tar как явления:). Прогресс неостановим. Изменения будут. Нужно привыкнуть к этому, научиться радоваться этому и, по возможности, влиять на направление изменений в сторону улучшений (ой, не хочу начинать глубокую дискуссию о том, что такое улучшение - увольте, пожалуйста, от этой беды).

Изменение, не закреплённое в стандарте - не прогресс, а путь к хаосу и всеобщему безумию. Общепринятые соблюдаемые стандарты - вот, что отличает человека от (слово подберите по вкусу). :)

anonymous
()

2Irsi

Постмотрел про ФС AS/400.

IMHO, налицо кривой процедурный подход :) Каталог (именуемый зачем-то библиотекой) хранит знания о нескольких файлах, которые могут принадлежать к какому-то типу (из фиксированного множества). Какие тут особые преимущества - неясно.

Если я неправильно понял - ткните, пожалуйста, ссылкой на подробное описание, а то я нашел лишь голословные высказывания на каком-то форуме и FAQ с парой приложений по теме.

anonymous
()
Ответ на: комментарий от anonymous

Ваша честь, я протестую!:) "Аналогичная ФС без многопоточности" - бессмысленное сочетание слов. Многопоточность слишком сильно влияет на организацию ФС (и vfs, и os, и физического расклада), чтобы считать возможным употребление слова "аналогичная".

Изменение, не закрепленное в стандарте, - норма жизни. Стандарты появляются на основе уже сделанных изменений. Просто нужно вовремя переводить полезные изменения в открытые стандарты. Или Вы серьезно думаете, что стандарты появляются на пустом месте?

Вообще, я всегда считал себя БОЛЬШИМ любителем стандартов. Оказалось, есть фанаты и покруче меня...:)

svu ★★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.