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

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.

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

2svu

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

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

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

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

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

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

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

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

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

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

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

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