LINUX.ORG.RU

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

">Не понял. При чём тут vfs - раз. Ну как же? Например для доступа к устройствам и для назначения прав доступНу как же? Например для доступа к устройствам и для назначения прав на доступ" Ещё раз не понял. Единственный конкретный VFS, который я знаю - gnome-vfs. Или тут vfs в другом смысле прозвучало ?

"Ну это опять же дело вкуса. Я не имел в виду именно реестр. Это могла-бы быть, скажем, библиотека для работы с настройками сохранёнными в xml-файлах. Вообще, когда делали GConf, было очень много споров на эту тему. И в конце концов, GConf имеет гораздо меньше недостатков присущих реестру виндавс (надёжность например)."

Какая надёжность ? Это личный опыт ? Не аргумент. Для начала, в gconf хранятся пока настройки только GNOME-овского desktop-а и некоторых приложений, не ахти какая нагрузка (и критичность - если слетят настройки gnotepad, я сильно расстраиваться не буду). Опять же XML, конечно, дело благородное, но скорость доступа низкая. Значит как-то надо индексировать, по-моему до этого дело ещё не дошло. В реестре же хранится критическая информация (настройки драйверов, SRM), её много, к ней нужен обязательно быстрый доступ. Так что тут даже сравнивать нельзя.

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

Да, считаем что файл в /dev уже создан, почему мне из этого должно быть понятно почему так сделано в NT? И вообще разговор был на тему "предложи вариант лучше чем мапинг устройство->файл и об'ясни почему предложенный вариант лучше, удобнее и все такое".

Касательно принтера: print->write, read->read, manage printers/documents вообще свойства совершенно другие непосредственно к принтеру отношения НЕ имеющие, и там им не место. take ownership -> change owner, change permissions - это я незнаю что такое и почему оно вынесено в отдельный пункт, что оно делает то хоть? ;)

Если у нас ACL'и единые для всех - то нет ничего плохого в том чотбы кто угодно мог их менять.

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

"Да, считаем что файл в /dev уже создан, почему мне из этого должно быть понятно почему так сделано в NT?" Откуда он может быть создан, если мы не знаем заранее, какое устройство появится ? Мы что должны посоздавать-таки все файлы устройств заранее ?

"Касательно принтера: print->write, read->read, manage printers/documents вообще свойства совершенно другие непосредственно к принтеру отношения НЕ имеющие, и там им не место. take ownership -> change owner, change permissions - это я незнаю что такое и почему оно вынесено в отдельный пункт, что оно делает то хоть? ;) "

Что делает - понятия не имею. Я это к тому, что у разных устройств разные виды доступа, не обязательно сводящиеся к read/write. Да, можно грубо считать, что если есть устройство, в него можно писать, с него читать :) Но ведь не обязательно именно так, виды доступа можно прописать гораздо более детально. Как поступать - вопрос философский, в NT - выбрали самый общий случай.

Я могу написать драйвер устройства mydevice с доступами: drink beer, watch TV, sleep и попробуй мне это сопоставить с read/write 8))))).

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

"Если у нас ACL'и единые для всех - то нет ничего плохого в том чотбы кто угодно мог их менять"

Как их можно менять, если неизвестно заранее какие у устройства есть виды доступа ?

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

Sorry for my english - back to work, you know...

Well, this is really funny question. Well, I see a couple of variants (and their combinations). Probably there are more

1. The useage of the streams is fixed in the system doc. For example, thread #1 is always ACL, #2 is always icon(if present) and so on. Actually, Mac's 2 threads have fixed semantics.

2. "Thread set" per "document/mime type" agreement.

Probably, there can be more complex thread semantic discovery schemes - but too expensive, I'm afraid...

Just keep in mind - I am inventing things just on the spot, so probably these 2 ideas are absolutely dumb:)

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

"Zabila"??? What is the filesystem behind XBox? Why did MS care to add Fat32 support in Win2000? No, I never heard anything about MS wish to kill FAT. Any references?

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

Ну так ты не предоставил примера прав доступа, которые не ложатся на read/write модель.

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

Ну лично я не против иметь в /dev кучу файлов, мне они не мешают ;) А кто-то может создать его перед тем как вставлять устройство. Ведь то какое устройство мы купили - уже известно.

Касательно твоего драйвера. Все мапится на read/write прекрасно. Все те три действия которые ты перечислил мапятся на write, если бы ты добавил какой-нить get_current_task() - это был бы read ;)

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

Я имел в виду vfs в том понимании, в котором это понятие существует когда речь идёт о ядре юниксоподобной ОС.

С надёжностью реестра виндавс - был печальный опыт. Одни раз накрылось несколько секторов на винте и (по закону подлости) именно в системной области реестра. В итоге секторы восстановились из резервной области диска, а систему пришлось переставлять т.к. не доходило даже до загрузки гуёв. На это ушёл день. Как вы думаете, долго бы я возился чтобы поднять в такой ситуации линукс?

asaw ★★★★★
()

   > То есть интероперабельность Вас что-ли вообще не интересует?
   Интересует  и  именно  поэтому  я  лично  против  потоков. Т.к. вместо
   простого  файла единообразно используемого всеми программами, появятся
   новые  сущности  "файл  для  nautilus'а", "файл для хрен знает чего" и
   т.п.  Хотя  при  наличии  документации  (ну или хотя бы хэдеров) можно
   будет разобраться что где лежит, но проблем будет ...
Я тоже против потоков.
Да, я вижу ограниченное применение EA - для хранения системных данных (acl'ы
и флаги шифрации), и очень ограниченное - для пользовательских данных потерять
которые совсем не жалко - всякие иконки, майм-типы и прочее. Даже в случае
иконок - что если Петя повесил на документ одну иконку, а Вася - другую -
как их хранить? Разве что извращаться давая атрибутам имена вида
"user.customicon.502" (где 502 - ИД юзера) вместо "user.customicon".
   >  В  случае  с  линуксом  (спасибо asaw) у атрибутов есть имена - что
   автоматически снимает все вопросы об интероперабельности.

   Ни  хрена  это  не  снимает.  У  атрибута  имя "XYZ", а там дрова. Чем
   отличается  "video/mpeg"  от  #define  NS_VIDEOSTREAM 4566 ? Кто будет
   проверять соответствие меток данным? ФС.
Ну если давать имена буквально "XYZ" то разницы нет.
Во-вторых - под виндой нельзя присвоить потоку индекс 4566 как я понимаю
(читать про этот аспект win32 мне лень) - так как для этого у файла должно быть
4567 потоков.
И имена атрибутов в линуксе по-умнее - типа "user.customicon" - и
соответственно никакого соответствия число<->смысл нигде регистрировать не
придется как в случае с 4566<->"application/x-mpg" так как всем и так понятно
что значит "customicon". Ведь майм-типы успешно используются, и никого
не ставит в тупик вопрос что такое "application/x-tar".

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

>Гемороя получается больше, значительно больше чем хочет нам показать господин svu

1. There is a lot of hemorrosis here, you're right. Nobody promised you easy life:) And probable, after deep investigations and thoughts, the humanity will throw multithreaded FS out. Or consider them obsolete. I am just not sure it already happened. And not sure LOR is the right place to make a FINAL verdict, you know?:)

2. Probably, the idea of "extended attributes" is more progressive than the idea of multiple threads. "Next generation", so to say. Looking by name aloways smells better than looking by number:) I am just not familiar with the API of these attributes - are there special read/write syscalls? How will developers access them? Just url with decent docs would be great to have a look at.

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

asaw (*) (2003-02-10 14:57:18.702)
Ха. Это как раз не закон подлости, а закономерность.
M$ туда постоянно что-то пишет и читает.
Так она восстановилась или нет ?
В Лине может быть не много проще...
Конфигурация системы раскидана по /etc.
И рухнули бы настройки только данной программки.
Да и скорее всего только в юзверском катологе.

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

так есть ведь разница в сложности :-)

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

>Так она восстановилась или нет ?
Пардон, не ответил. Восстановились только сами сектора (т.е. в них опять стало можно писать и читать оттуда), но данные кот. в них были пропали.

asaw ★★★★★
()

asaw (*) (2003-02-10 15:11:42.288)
Ну раз у тебя сложнее... Вот и переустанавливай M$..
А как говорят в народе -
все гениальное - просто.
ЗЫ. Красиво получилось.

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

> Ну раз у тебя сложнее... Вот и переустанавливай M$..
Пусть этим знанимаются защитники виндов и фаны M$. Я это дело бросил с тех пор как на Линукс перешёл :-)

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

2ranckont: а у меня было веселее. вырубился свет, винт не заsync-ился, накрылся рутовый раздел. Бэкапа не было (машина домашняя). Пришлось переставлять. Мораль - нет серебряной пули (кроме бэкапа ;)

yakuza
()

   2.  Probably,  the  idea  of "extended attributes" is more progressive
   than the idea of multiple threads. "Next generation", so to say. Look-
   ing  by  name aloways smells better than looking by number:) I am just
   not  familiar  with  the  API  of these attributes - are there special
   read/write  syscalls?  How  will developers access them? Just url with
   decent docs would be great to have a look at.
Уже давали ссылку: http://acl.bestbits.at/cgi-man/getxattr.2

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

Looks good. There are 2 differences between EA and MTFS:

1. Access by name vs acces by number. I'd say this can be considered as an advantage os EA (well, taking the performance penalty is not too high:)

2. No direct access in EA. Well, can be annoying in some cases but for most of the application of MTFS (we listed them above) is should not be a real problem. Though, the serios problem will happen if I want to use some MPEG4 as an icon for some document:) The idea to read the whole attribute at once can be questionable...

So I nearly agreed to consider EA as rethinking of MTFS and be happy with them. The only problem remaining is EA are still destined to be lost on interfaces with the old world.

Just one little question - is this only for XFS or is it in vfs layer too?

svu ★★★★★
()

   2. No direct access in EA. Well, can be annoying in some cases but for
   most  of  the application of MTFS (we listed them above) is should not
   be a real problem. Though, the serios problem will happen if I want to
   use  some  MPEG4  as  an icon for some document:) The idea to read the
   whole attribute at once can be questionable...
Там в мане написано что длина значения EA не может быть более размера
блока (1/2/4кб - как ФС создана). Так что никакой проблемы нет.
   Just  one little question - is this only for XFS or is it in vfs layer
   too?
green по этому поводу ничего не ответил, а насколько я понял asaw - именно такой
и будет. Только патчи на acl.bestbits.at не только для XFS, но и для ext2/3.

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

Block size only? 4K? Really really sad. So people will have to invent some funny naming schemes for storing large data, like gnome.icon.data.0, gnome.icon.data.1, ... Well, EAs are not as good as I expected them to be:) Now, I know - in the ideal world I'd see the (v)fs as MTFS with "named" (but not numbered) threads. Why noone cares to implement?:)

svu ★★★★★
()

О пользе потоков в NTFS: как то проскальзывала информация (ссылку не помню), что существует вирус, который испоьзует потоки в NTFS. Он не заморачивается с анализом сегментов программы, а просто пишет свое тело в новый поток. А вы говорите, трудно найти применение. Хорошее начинание всегда будет поддержано ;-)

Насколько я понимаю потоки в файле представлены как вектор [] (0, 1 ...). А если для прикладной программы нужен двухмерный массив [][](свойства пикселей на экране), а если трехмерный...? То есть пытаться описывать структуру данных, необходимых для прикладной программы, средствами файловой системы - зараннее бесполезное занятие (структуры и потребности могут быть сколь угодно сложные).

anonymous
()

   Block  size only? 4K? Really really sad. So people will have to invent
   some   funny   naming   schemes   for   storing   large   data,   like
   gnome.icon.data.0, gnome.icon.data.1
А зачем хранить тело иконки? Наверно нужно хранить имя файла - а оно
влезет в 1k. Зато атрибуты могут храниться в иноде (см. тот man).

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

2hvv

> Ну если давать имена буквально "XYZ" то разницы нет.

Уели :) Не выйдет из меня юмориста.

> Во-вторых - под виндой нельзя присвоить потоку индекс 4566 как я понимаю (читать про этот аспект win32 мне лень) - так как для этого у файла должно быть 4567 потоков.

Ну. естественно, я взял и имя и номер от балды. Но если все форматы файдов будут укладываться, скажем, в 16 потоков?

> И имена атрибутов в линуксе по-умнее - типа "user.customicon" - и соответственно никакого соответствия число<->смысл нигде регистрировать не придется как в случае с 4566<->"application/x-mpg" так как всем и так понятно что значит "customicon". Ведь майм-типы успешно используются, и никого не ставит в тупик вопрос что такое "application/x-tar".

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

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

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

The path to the icon? Then we are loosing our the great advantage of MTFS - saving on "open" syscalls. And we do not allow the file (for example, some small app) to be self-contained. Also, same problem with ACLs and document metadata - 4k will not be enough for them:(

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

> Also, same problem with ACLs and document metadata - 4k will not be enough for them:(

Не вижу здесь никаких трудностей. Пример пожалуйста.

asaw ★★★★★
()

2svu

Хотел признать, что многопоточные ФС выиграли очко - есть стандарт, но ...

Вы же видите каков этот стандарт. Даже примитивнейшее разбиение ELF на секциии в разные потоки в рамках этого стандарта невозможно. Так что многопоточные ФС - все-таки "это фантастика".

anonymous
()

народ, а чего вы копья ломаете за потоки в файлах... индексы в НТФС не числовые, а как назовешь поток, так он и будет зваться... а само приложение будет разбираться - есть потоки или нет. Умолчательный поток :DATA будет отдаваться приложению, если оно не понимает потоки или принудительно не говорит какой ей нужен...

эксперимент:

echo Hello world data stream > myfile.txt
echo Hello world data stream more info >> myfile.txt:DATA
echo Hello world stream 1 > myfile.txt:stream1
echo Hello world stream 2 > myfile.txt:stream2

далее заходит в нотепад

notepad myfile.txt
notepad myfile.txt:DATA
notepad myfile.txt:stream1
notepad myfile.txt:stream2

и видем чего и как из потоков извлекается...

Потоками пользуется МС Офис весьма активно - свойства документа в них хранятся, индексная информация... иногда Explorer пользует потоки для хранения тумнайлов файлов

Потоки могут быть не только на файлы, но и на каталогах

PTO
()

2PTO (*) (2003-02-10 17:56:43.743) >echo Hello world data stream > myfile.txt >echo Hello world data stream more info >> myfile.txt:DATA >echo Hello world stream 1 > myfile.txt:stream1 >echo Hello world stream 2 > myfile.txt:stream2

нифига не получилось... 10.02.2003 17:18 26 myfile.txt Содержимое файла Hello world data stream

>далее заходит в нотепад >notepad myfile.txt Hello world data stream >notepad myfile.txt:DATA Cannot find the myfile.txt:DATA file >notepad myfile.txt:stream1 Cannot find the myfile.txt:DATA file >notepad myfile.txt:stream2 Cannot find the myfile.txt:DATA file

dead_knight
()

А, так всё таки никакой экономии нет! :)

Это просто гениальное решение MS записывать путь как

H:\hhh.jjj:\UUU.\yyyt\:uuuyt:\iiygb::\\\ggg::::.uutyytb:\\iiiii.txt:123.kkk

Зачем? Что бы никто не догадался! (c) Гайдай

anonymous
()

2PTO (*) (2003-02-10 17:56:43.743) Может стоило написать

more < myfile.txt more < myfile.txt:DATA more < myfile.txt:stream1 more < myfile.txt:stream2

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

Well, ACLs probably should be ok for most of the cases. In the end, it is just numbers and bitmasks - so for 99% sysadms 4K would be enough.

The metadata, keywords, authors and so on - they are strings. For a set of strings, it is not a problem to overcome 4K limit.

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

Yes!!! Thanks. I assumed (sorry for my ignorance) these streams were referenced by #. I was plainly wrong. They can be referenced by name. So now I can say I love NTFS way of MTFS much more than EA.

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

Из ссылки на документацию которая приводилась выше:

FILESYSTEM DIFFERENCES
The kernel and the filesystem may place limits on the max-
imum number and size of extended attributes that can be
associated with a file.

In the current ext2 and ext3 filesystem implementations,
all extended attributes must fit on a single filesystem
block (1024, 2048 or 4096 bytes, depending on the block
size specified when the filesystem was created). This
limit may be removed in a future version.

In the XFS filesystem implementation, there is no practi-
cal limit on the number of extended attributes associated
with a file, and the algorithms used to store extended
attribute information on disk are scalable (stored either
inline in the inode, as an extent, or in a B+ tree).

Я думаю, это снимает все вопросы касательно принципиальных трудностей с размерами EA.
На счёт теоретической возможности существования таких пределов для конкретной фс. Ну не всё-ли равно будет это 1K для фс которая плохо поддерживает EA или 0K для фс которая их не поддерживает вовсе? Если для вашей программы поддержка EA некритична, то должен быть некритичным и их размер. В противном случае вы всегда можете выбрать подходящую фс.

asaw ★★★★★
()

Попробуй cat вместо notepad. Все работает (только не на фате же :) )

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

Yes but:

1. You have to read the whole bastard into the memory. Even in XFS.

2. No mmap:(

Sergey

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

По моему в NT4 уже встроенная в ядро графика

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

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

Вообще, это много где есть. В том же UML, например. А в Access'е как раз этого и нет, ибо в РДБ отношение многие-ко-многим реализуются через вспомогательную таблицу. В данном же случае, это значит что файл может принадлежать нескольким каталогам, а каталог содержит несколько файлов. Не более и не менее :)

anonymous
()

В общем который раз оказалось что Irsi ничего не понимает из того что говорит. Глупо было ожидать обратного от дауна.

anonymous
()

Ну так что там насчёт notepad ?
Не работает ни хрена!

PitStop
()

2anonymous (*) (2003-02-11 12:19:17.838): тявкнул для успокоения своей убогой головки и для поднятия флейма типа? Ну и хрен с тобой...
К сожалению работы подвалило и некогда здесь разубеждать некоторых товарищей и доказывать им что они заблуждаются, да я и смотрю что со фремен последнего флейма на эту тему, людей разобравшихся с многопоточными фс прибавилось...:)
Нет, разумеется есть и упертые... Я знаю одного маньяка, который до сих пор уверен что древовидная структура каталогов это излишество, ведь на RSX-11M и без нее прекрасно жили...
Да, раз пошла такая пъянка - наткнулся я на замечательный ресурсик, а именно http://pdp11.org.ru, там есть ссылки на бесплатные шеллы RSX-11M, эмуляторы и где скачать разные ОС для этих эмуляторов, в том числе - и самые первые версии UNIX(tm). Рекомендую ознакомится чтоб оценить пропасть...;)

Irsi
()

Irsi, идиот, ты хоть понял что все время гнал пургу - что в NTFS потоки адресуются не по индексу, а по произвольному строковому ключу?

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

Прикольно.

echo Hello > aa:stream1 пишет в поток stream1 файла aa.

echo Hello > a:stream1 пишет в файл stream1 на дискету.

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



2anonymous (*) (2003-02-10 12:42:34.01)
>sco-killer! Мне кажется ты один из тех кто сидит на Advanced server-e и который думает что ...
Неправильно кажется, я нигде не говорил, что сижу на Advanced Server, я сказал, что у меня только ядро от AS, причем самособранное. Кста, в поставке RHAS 2.1 идет ядро 2.4.9, так шта учите матчасть.
[oracle@server oracle]$ uptime
2:40pm up 145 days, 2:37, 6 users, load average: 0.36, 0.22, 0.13
[oracle@server oracle]$ uname -a
Linux server 2.4.9 #1 SMP Пнд Июн 24 14:40:24 EEST 2002 i686 unknown

Драйвера для health (под компак) не идут в исходнике, учите матчасть.
По поводу остального, каждый сам себе доктор. Придет новый сервак с 4 гигами, будем посмотреть.
Насчет сравнения Compaq & Sun - если не трудно, приведите конфигурацию обоих машин, параметры ядра, параметры Оракла, можно посравнивать.

sco-killer
()

2anonymous (*) (2003-02-11 13:18:00.461): ты идиот, ты не заметил что в NTFS нет и i-node как таковых? Ты вообще понимаешь что такое намеренное упрощение для простоты объяснения? И если уж нато пошло, то я не говорил о том как реализованы потоки конкретно в NTFS, я говорил об неком обобщенном и упращенном подходе, для простоты понимания...

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

> а писать

> echo Hello > .\a:stream1

> религия не позволяет?

А что делать с программой, автор которой забыл про такую возможность, и не воткнул этот твой .\?

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