Вышла первая версия opensource клона Windows NT

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

Или я чего-то не понимаю?

2green: Extended Attribute это частный и весьма ограниченный вариант более общего поняти multiple data stream per file... Второй вариант ограниченной реализации - data fork & resource fork в HFS/HFS+.
На счет исходников дарвина (и не только) - начни с сайта с оригинальным названием, а именно www.opensource.apple.com ;) Там не только исходники дарвина найти можно, но и другие, не менее интересные вещи...:) Open Directory например (что-то типа конкурента виндовой Active Directory, но для юниксов).

2svu: на маках файлы были двухпоточными...:) Дико удобно, несмотря на все ограничения.
Блин, интересно - для кого-нибуть допрет что при осуществлении вызова open (filename) первое что делает любоая ОС это осуществляет ПОИСК соответствующий записи в каталоги для filename? ;) И что это операция ОЧЕНЬ дорогая и к слову - в ntfs она осуществляется однозначно быстрее чем в ext2... Почему... блин, я боюсь что рассказать здесь про b-tree у меня не хватит сил...;)

2Led: а мы же тогда и выяснили как - с помошью ACL, реализованных в виде одного из тредов... ;)

anonymous (*) (2003-02-07 02:40:39.974): про иконку никто не шутил - это действительно удобная фича многих современных гуев, а именно - возможность назначить любому файлу, любую иконку. Т.е. есть как бы два типа иконок - одна дефолтовая, выводится на основе БД x-mime type если не определена другая, произвольная, назначаемая юзером. Возми поставь BasiliskII, поставь на него MacOS 8.1 и посмотри как это там реализовано... впечатляет...:) И сравни как это сделано в наутилусе и какие накладные расходы это влечет и там и там...

Создать ещё одну группу и всех кому этот файл нужен туда добавить.

так блин, так же группы плодятся немеряно...

anonymous (*) (2003-02-07 12:06:27.846)
Используй ACL...
А если всех пользователей нужно поместить в один каталог с одним расширением
Так не не используй...
Свобода выбора однако...

Про демагогию возвращаю. Тем более что ни на один вопрос ответа я так и не получил.

Если бы в Линуксе права доступа небыли свойством любого "объекта" (процесса, файла, сокета, канала, и т.п.) то никакой контроль доступа вообще не работал бы. То что это организовано не так как Вам хочется ещё не значит что это организовано плохо.

И мне уже надоело доказывать здесь простую истину, что если что-то работает и работает хорошо, то от этого не стоит отказываться. То что NT сделали "с чистого листа" ещё не значит что её сделали хорошо. И вообще, есть много методологий проектирования ПО и это не значит что одни из них "устаревшие и неправильные", а другие "современные и единственно верные".

2Irsi:
>а мы же тогда и выяснили как - с помошью ACL, реализованных в виде одного из тредов... ;)
Не помню, чтоб мы до этого договаривались:)
ок, значит, чтоб получить атрибуты/права доступа к файлу драйвер ФС
должен будет открыть этот файл? ничего не скажешь, очень "экономично":)

"А вот у меня вопрос (быть может такой же глупый как и я): Какого хрена 10гиговый раздел с НТФС5 видится в дискдряке как почти 10гиговый раздел нтфс + маленький раздельчик на 200 метров без фс??? Что бы это значило??? С тех пор как я удалил нтфс и вернул туда фат32 раздел обратно стал 10гиговым."

Ну может там журнал на 200 метров валяется? :)

Да-да, конечно же multiple data streams.

что-то на www.opensource.apple.com я не нашел сырцов кернела. Как модуль называется?

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

2green: здесь хорошо смотрел? http://www.opensource.apple.com/projects/darwin/6.0/projects.html
Зарегистриться не забыл? Регистрация бесплатная - просто требуют подтвердить свое согласие с APSL...

2green: "как они будет переживать рестарт системы. " Hint: не все объекты хранятся на диске и должны переживать старт системы. Вот ты в NT в памяти создаёшь объект и через его security descriptor даёшь на него прав. Напротив, в unix объекты создают на диске. Например, очень часто создаются временные пайпы в /tmp. Вот и вся разница.

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

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

Внимание, повторяю вопрос. В случае когда об'ект должен переживать систему, как это должно происходить?

Аргумент про "пайпы в /tmp" не принимается - mount none /tmp -t tmpfs и ничего на диске не создается.

"Если бы в Линуксе права доступа небыли свойством любого "объекта" (процесса, файла, сокета, канала, и т.п.) то никакой контроль доступа вообще не работал бы". Пример - процесс. Одна степень свободы - рут может убить любой процесс, остальные пользователи могут только свои. В NT по-другому. Каждому процессу - по security descriptor-у с ACL. Разница видна ?

На вопросы отвечу, на все, на которые могу ответить. Вроде бы я на все до последнего момента отвечал.

2green:
честно говоря, не знаю. Надо почитать. Посмотрю - отвечу.

А какие объекты переживают систему, если объекты - не файлы ?

Пайпы, но не временные. Всякие устройства (винчестеры, сканнеры и тп). (это то что сразу подумалось)

2yakuza "Вот ты в NT в памяти создаёшь объект и через его security descriptor даёшь на него прав. Напротив, в unix объекты создают на диске. Например, очень часто создаются временные пайпы в /tmp. Вот и вся разница."

Так ведь в unix есть такое понятие shared memory как средство IPC. Насколько я знаю там тоже устанавливаются права для доступа. Зачем делать в /tmp?

2dead: нуу, и shared memory тоже есть. Кто-то использует shared memory, а кто-то пайпы. Xmms, помню, создавал пайп, в который можно было писать команды и им управлять.

2green: насчёт устройств - посмотрю, завтра отвечу.

Это не совсем так. Из man 2 kill: "For a process to have permission to send a signal to process it must either have root privileges, or the real or effective user ID of the sending process must equal the real or saved set-user-ID of the receiving process". Некоторая свобода всё же есть. Почему в этом механизме не используется GID или ACL я сказать не могу, но мне это совсем не мешает. Посылка сигналов между процессами это довольно особый случай, IPC принято осуществлять другими способами.

Эта. Я вообще-то про NTFS ничего сказать не могу, ибо малообразован в этой области. Я про WinNT и Linux. У меня тут непроизвольно получилось их сравнение. Значит условия проведения опыта таковы:

Мне было надо отсортировать по алфавиту словарь (обычный русский грамматический). Сортировал методом qsort. Но вот беда - словарь величиной 70 Mb, а на машине физически было 48 Mb. Под Linux все прошло без приключений. Но тут черт меня дернул перетащить исходники в Виндуза и прогнать эту программу там. Сначала Винда стала скрипеть винтом, потом попросила закрыть все ненужные программы, потом стала прямо-таки угрожающе скрипеть винтом. В конце концов она на чистом английском языке сказала что-то вроде "отстаньте от меня все, че вы мне такие сложные задачи даете", и таки сняла мою замечательную программу из 10 строчек. Вооот. Короче я на нее обиделся.

Wolf68 он же Дима Анисимов.

У меня похожая история была когда я на w2k большие картинки пытался редактировать:-) В линуксе всё гладко прошло.

linux рулёз! но вот кстати пример получения кеrnel panic на ядрах 2.4.18 - 2.4.20:

ip -f ipx tunnel add tnl0 mode gre remote 10.0.2.1 local 10.0.1.1 ipx_interface add -p eth0 0x100 802.3 ipxd ifconfig tnl0 up ipx_interface add tnl0 0x200 802.3

и всё( при получении первогоже ipx пакета всё валится в kernel panic((

Щас вылезет ирси и скажет, что у вас винда ворованная, железо жёлтое и сборка кривая.

Sorry for English. Circumstances, you know....

1. "Open" is expensive because it has to walk through the directory tree. There are some sophisticated caches in modern OSes - but it is still expensive. And this is the logic of vfs (which just calls concrete filesystem to read the directories, inodes). You cannot do much about its complexity. References? "Unix internals". Very good book (well, at least for me it was)

http://www.amazon.co.uk/exec/obidos/ASIN/0131019082/ref=sr_aps_books_1_2/026-...

2. vfs is not only wrappers. There are many generic algorythms. In Java terms, "not all methods are abstract there":)

3. I do not bet on syscalls:) Definitely, you can always create/find an OS and a benchmark for proving me the speed of "open" and slowness of multi-threaded files. But AFAIK the subject is statistically proven (otherwise OS designers would forget about threaded files long ago...)

4. Probably you can optimize it this way: opendir + readdir(s). But you have to take special care about this. Actually, you will be implementing "threaded files in user space":) This is more expensive because of the price of syscall. So why not implement it entirely in kernel?

5. Keeping desktop-related metadata in files is a common thing. Sir Irsi already answered on this.

6. Sorry, I did not participate in the previous discussion. At least, I do not remember myself talking about these things...

Sorry for English again.

2 Irsi

> Блин, интересно - для кого-нибуть допрет что при осуществлении вызова open (filename) первое что делает любоая ОС это осуществляет ПОИСК соответствующий записи в каталоги для filename? ;) И что это операция ОЧЕНЬ дорогая и к слову - в ntfs она осуществляется однозначно быстрее чем в ext2... Почему... блин, я боюсь что рассказать здесь про b-tree у меня не хватит сил...;)

Ну конечно, как B-tree, так сравниваем NTFS с ext2 ;) А я хочу Reiser с FAT сравнивать.

Про поиск опять общие слова. Интересует конкретно:

а) Почему все-таки эта операция ОЧЕНЬ дорогая и нет ли способов сделать ее дешевле.

б) Мы говорим о open не абстрактных файлов находящихся х.з. где, а о файлах находящихся в одном, известном каталоге. Поддаётся это оптимизации если возникнет необходимость? Никакого walk-path в данном случае нужно ведь не будет (кроме поиска самого каталога)?

в) Интересно не то как дорог open в абсолютных цифрах, а то насколько дешевле его "файлы-лайт" (кстати интересна цена и других операций с ними).

P.S. Значит эти целью создания этих потоков является назначение файлам произвольных иконок? Или есть другие применения.

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

2svu

Благодарю за ответ.

1. Ну да. Но зачем проходить его (дерево каталогов) три раза для файла из одного каталога? По моему оптимизируется путем кэширования имен использовавшихся каталогов.

2. Я и не говорю, что чистые. Но добавления чисто служебные.

3. Для чистоты эксперимента надо проводить его на одной машине под одной осью на ФС с потоками и без них. Когда вы мне скажите где взять NTFS без потоков я попробую потестить ;)

4. Не знаю, может не всем это нужно. Почему в ядре linux нет, скажем, тредов?

5. Если мне это не нужно могу я это не использовать?

> 4. Не знаю, может не всем это нужно. Почему в ядре linux нет, скажем, тредов?

Там нет и процессов как таковых ;-) И всё получается довольно просто и элегантно.

2Irsi:
>> Кстати, оболочка виндов увы пока почти не использует возможности многопоточности из-за требований совместимости с полудохлой веткой 9х/Ме...:( Ну ничего - этой ветке год жить осталось, потом и Ме станет end of support и тогда-то начнется веселье...:)

Если ты так хорошо осведомлен о планах МС, может подскажешь и планы Эпл? с какой бы радости они отказались от тредов в Х например? наверное твоих постов тут не читали

> P.S. Значит эти целью создания этих потоков является назначение файлам произвольных иконок? Или есть другие применения.

Possible applications:

1. Icons :)

2. ACLs

3. Document metadata (authors/keywords/subjects) for indexing

4. Multiple binaries for different platfors (with same GUI resources as separate thread!). Actually, treating GUI resources as separate distinct part of executable file was not that bad idea of Microsoft.

5. Multiple scripts (cmd/sh)

6. Different views of the document for different users.

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

Enough?

2svu:
OK, тогда почему сама MS не использует "потоки" хотя бы для т.н.
многоверсионности библиотек? Проблема-то ведь существует (ИМХО)

2 svu (*) (2003-02-07 15:08:16.92)

После этого хочется спросить. А на фига козе баян?
Может оставить fs её родное - обслуживание именно файловой системы? Может не будем напрягать ее всякой хренью с "потоками" для " Multiple binaries for different platfors " или " Different views of the document for different users " Ипануться можно! И чего это из стиральной машины миксер не делают? И стоит ли так "трахаться" ради " Icons " ?

2asaw: ну, хорошо, для посылки сигнала должны uid совпадать, я об это м знаю. Только это совсем не ACL.

Фууу, дискуссия зашла в тупик, ушли в какие-то частности. К слову говоря, ReactosOS, которая стала причиной трёпа - сырое глюкало, похлеще Linux 0.01 из 91-го года. Там в новостях один из девелоперов писал, что начал разрабатывать поддержку скроллбара в win32k.sys. Прогресс, блин.

2 svu

1. :)

2. "..." - кричали пьяные гости.

3. Документ с метаданными = метадокумент? Метаданные для метадокумента - метаметаданные. Метадокумент с метаметаданными - ... и т.д. Вы уверены что все это нужно решать средствами ФС?

4. Секции в разных потоках - зачем? Что туда часто будет запись? Да и для read-only это имело бы смысл лишь в отcутствие lseek. (Кстати ФС - с многопоточными файлами без случайного доступа - красивая мысль)

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

6. Опять же разве это задача ФС?

Пункты 3, 4, 6 весьма убедительны. Пожалуй достстачно.

а в чём проблема (пример)?

Никаких проблем. В Linux 9 бит прав - основной механизм системы безопасности, в NT - ACL. Согласен ?

да

В реальности когда надо открывать все треды файла намного более редкая операция (3 open), чем открыть один тред файла (1 open).

Иконки - файл-менеджер не открывает сам файл, а тред с иконкой. ACL - точно так же, проверка идет на одном уровне, а тред открывает программа.

В результате мы получаем более дорогой open. Никакой экономии на замене 3 open на 1 open просто не существует, за отсутствием в этом реальной необходимости.

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

> Там нет и процессов как таковых ;-) И всё получается довольно просто и элегантно.

Не надо издеваться над убогими и слабоумными и выдергивать фразы из контекста.

svu сказал, что если возможно сделать поддержку потоков на уровне библиотек, то почему нельзя сделать ее на уровне ядра. Я ответил (ну может приплетя дурацкую аналогию), что поддержка тредов тоже осуществляется на уровне библиотек, а не ядра и никому это не мешает (а тем кто их не использует даже ндравится ;) ).

ну да, я о том же

Ну блин, НЕТ ТАКОГО ПОНЯТИЯ - ОТКРЫТИЕ/ЗАКРЫТИЕ ПОТОКА В ФАЙЛЕ, ЕСТЬ ПРОСТО ОТКРЫТИЕ/ЗАКРЫТИЕ ФАЙЛА!!!! А уж потом - read/write/seek для _конкретного_ потока в открытом файле! Если номер потока в этих операциях не указан - считается что работаем с нулевым (он же основной) поток.
В абсолютных цифрах - поиск файла занимет до 95% всего времени, требующихся на открытие файла. Конкретные цифры зависят от организации конкретной FS и реализации алгоритма поиска, для ext2 они кстати далеко не самые маленькие...
Сами подумайте, блин... Ну рапишите шаги по которым будет происходить скажем открытие файла /usr/home/anonimaus/testfile... И ужаснитесь...:)
На счет того что "каждый должен заниматься своим делом" - дело FS это хранить объекты, фактически FS это кастрированный вариант DB (кто сказал SQL??? УДАВЛЮ!!! CODASIL мать вашу!!!) и при проектировании FS надо исходить именно из этого... Понятия файл не сушествует, оно устарело, есть понятие объект, котрый может жить как в ОЗУ, так и на диске.
Мелкософт увы практически не использует возможности потоков потому что они вынуждены поддерживать совместимость с FAT/FAT32, которые эти потоки не поддерживают. К сожалению, алгоритмы (и соответственно возможности) которые черезвычайно эфективны на многопоточной FS, начинают на обычных FS жрать просто немерянное кол-во ресурсов что хорошо показывает например пример наутилуса. Скажем проще - некоторые вещи, в часности относящиеся к реализации возможностей таких вещей как GUI & DB, просто невозможно реализовать на однопоточных FS из-за того что они будут либо неэффективны, либо весьма сложны в реализации. Очень рекомендую подумать зачем большим DB нужны raw partition... Правильно - чтоб организовать данные на ней по своему вкусу...:) Соответственно приходится реализовывать в DB практически свою FS, свой механизм выделения блоков и т.д. Переход на многопоточные FS сильно увеличивает эффективность DB, работающих с файлами и соответственно - позволяет более эффективно использовать относительно просты DB, такие как например Postgres, для обработки существенно большего объема данных, одновременно - упращая их реализацию...

> Ну блин, НЕТ ТАКОГО ПОНЯТИЯ - ОТКРЫТИЕ/ЗАКРЫТИЕ ПОТОКА В ФАЙЛЕ, ЕСТЬ ПРОСТО ОТКРЫТИЕ/ЗАКРЫТИЕ ФАЙЛА!!!! А уж потом - read/write/seek для _конкретного_ потока в открытом файле! Если номер потока в этих операциях не указан - считается что работаем с нулевым (он же основной) поток.

Ясно, спасибо за разъяснение.

> В абсолютных цифрах - поиск файла занимет до 95% всего времени, требующихся на открытие файла.

Кто бы спорил ;) Но тогда не подскажете (в абсолютных же цифрах) сколько времени занимает открытие файла по сравнению с остальными операциями с ним? Так ли уж важна проблема open или read/write/seek тоже как бы важны? И как с их эффективностью у многопотоковых ФС?

Кстати если вы задумаетесь о способах управления дисковым пространством то поймете, что по сравнению с этой задачей затраты на tree-walk - детский лепет.

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

Верно ли обратное? ;)

Ну так кто-нибудь покажет данные экспериментов по использованию "потоков" в ФС? Как здорово станет людям начни это применяться? Как будут "летать" "десктопы" и прочие "воркстэйшены" ? Или вся эта хрень полезна для 1% пользователей? Для БД?
Что там насчёт баяна?

2Irsi: Заколебал... Скажи, на дискетах тоже будет стоять NTFS? А как насчет файлов в сети? В том числе не только по SMB, но и по FTP, и по NFS - используя получивший приз продукт MS? А как насчет средств bakup'а? Или ограничимся WinZip?

NailTS.

> Щас вылезет ирси и скажет, что у вас винда ворованная, железо жёлтое и сборка кривая.

Это не винда ворованная и не железо желтое. Это руки из жопы растут. Я сортировал 1G файл при 128 оперативки на 2k винде. Да, винт рычал, да, больно было на это смотреть, но все нормально отработало. Если вы не умеете программировать в экстренных условиях (например, при катастрофической нехватке оперативки), то это проблемы не ОСи, которая имеет свои системные требования и имеет все права послать вас с такими запросами на ..., а ваши. Другое дело, если бы алгоритм убивал систему из под юзера... конструктивнее, ребята, конструктивнее надо быть :)

А NTFS очень хорошая система. У меня машина по 10 раз в день ресетом перегружается (условия такие), и я еще ни одного фафла за 2 года не потерял. Ни одного. это про что-нибудь говорит?

2Irsi:
>дело FS это хранить объекты, фактически FS это кастрированный вариант DB
дело ФС - быть прослойкой (посредником, ещё одним абстрактным уровнем)
между пространством на диске (разделом) и фактическими данными
(в т.ч. и различными DB). Зачем ей приписывать несвойственные ей функции?
Для чего в сложный продукт (в данном случае ОС) добавляются уровни
абстракции надеюсь объяснять не нужно (принцип KISS, бритва Оккама и т.д.)
Странно слышать это от тебя, как я понял, приверженца микроядерных архитектур...
>зачем большим DB нужны raw partition... Правильно - чтоб
>организовать данные на ней по своему вкусу
Правильные фразы - неправильные выводы (ИМХО): DB НЕ НУЖНЫ сложные
ФС! Для них чем проще - тем лучше! ФС не может предусмотреть все
возможные варианты организации/оптимизации размещения/избежани фрагментации
данных, "крутые" DB сами об этом должны позаботиться, а задача ФС - как можно меньше мешать им в этом!
Если нужна сложная органиция данных на разделе - ставим на него DB
(без всякой ФС) настраиваем её КАК НАМ НУЖНО и используем!
Для таких случаев Antichrist прав на все 100% - ФС нафиг не нужна:)
А изготовлять гибрид ФС и ДБ - зачем? Получится переФС и недоДБ:)

> Кто бы спорил ;) Но тогда не подскажете (в абсолютных же цифрах) сколько времени занимает открытие файла по сравнению с остальными операциями с ним?

Да-да! Именно об этом! Или будем говорить о тестах типа, а вот если открыть 2000000 "файло-потоков" на NTFS, то это быстрее, чем ....

Ну куй мне 2000000 всякой муйни?