Здравствуйте, Pavel Dvorkin, Вы писали:

PD>Все, все, все. Больше у меня ни сил ни возможностей нет. При столь фантастическом непонимании основ современных ОС и файловых систем я больше никаких аргументов не имею и не могу иметь. Бессмысленно продолжать, так как надо читать целый курс, а на это у меня ни сил ни времени ни желания нет.
Как работают современные ОС я в курсе. Ни один толмуд на эту тему прочитал.
А еще я много думал на счет того как должны быть устроены правильные ОС.
А ты давай попробуй объяснить в чем принципиальная разница между файловой системой и SQL сервером?
Ибо и то и другое персистентные хранилище информации.
Единственная разница это способ структурирования этой самой информации.

Здравствуйте, WolfHound, Вы писали:

WH>А ты давай попробуй объяснить в чем принципиальная разница между файловой системой и SQL сервером?
Файловая система тесно интегрирована с ядерным менеджером кэша и системой виртуальной памяти. Т.е. фичи типа sendfile могут работать очень быстро.

И сделать такое обобщённо может и не получится — абстракции текут (к примеру, требуется особое выравнивание для того, чтобы работало DMA и т.п.).

Здравствуйте, WolfHound, Вы писали:

WH>Здравствуйте, Pavel Dvorkin, Вы писали:

PD>>Все, все, все. Больше у меня ни сил ни возможностей нет. При столь фантастическом непонимании основ современных ОС и файловых систем я больше никаких аргументов не имею и не могу иметь. Бессмысленно продолжать, так как надо читать целый курс, а на это у меня ни сил ни времени ни желания нет.
WH>Как работают современные ОС я в курсе. Ни один толмуд на эту тему прочитал.

Не знаю, что ты прочитал, но не в коня корм.

WH>А еще я много думал на счет того как должны быть устроены правильные ОС.

А то до тебя никто не думал.


WH>А ты давай попробуй объяснить в чем принципиальная разница между файловой системой и SQL сервером?

Объяснять я ничего не буду. Этот флейм тут уже не раз устраивался, да и Cyberax ответил, я мог бы добавить, но и этого не буду. Отмечу лишь маленькое такое передергивание. Если речь идет о файловых системах на основе SQL (вроде то ли закрытого, то ли нет проекта MS насчет SQL-файловой системы) — это может быть темой для реального проекта и темой для обсуждения. А вот представление о MySQL как о дисковой подсистеме есть, извини, чушь несусветная. И представление твое об отличии драйвере от программ есть то же самое. Элементарное непонимание основ реальной системы, с которой ты работаешь. И нежелание понять.

WH>Ибо и то и другое персистентные хранилище информации.
WH>Единственная разница это способ структурирования этой самой информации.

Фантастическая способность с апломбом говорить , не разбираясь совершенно в сути вопроса. Персистентное хранилище — и все. Вся история и вся практика развития ОС и ФС за 50 лет коту под хвост.

Вот до чего абстракции людей доводят, когда они не подкрепляются знанием конкретики.

Здравствуйте, Cyberax, Вы писали:

C>Файловая система тесно интегрирована с ядерным менеджером кэша и системой виртуальной памяти. Т.е. фичи типа sendfile могут работать очень быстро.
1)Что мешает тоже самое сделать с SQL сервером?
2)В правильных ОС фичи типа sendfile не нужны ибо они будут получатся автоматически.

C>И сделать такое обобщённо может и не получится — абстракции текут (к примеру, требуется особое выравнивание для того, чтобы работало DMA и т.п.).
Никуда оно не течет.
ОСь аля сингулярити. Следи за руками:
1)Приложение SQL среверу: Дай мне вон тот блоб на пару гигов.
2)SQL сревер файловой системе: Заверни кусок того файла от сих до сих в поток.
3)Файловая система драйверу винта: Вот тебе поток сложи в него такие то блоки.
4)Файловая система SQL среверу: держи поток.
5)SQL сревер приложению: держи поток.
6)Приложение сетевому соединению: Отправь поток.

Все! Вот тебе sendfile. И без единой протечки.
Драйвер винта будет запихивать в поток страницы, а драйвер сетевухи будет доставать из потока массивы которые выровнены драйвером винта.
Накладные расходы только на обслуживание потока. И проверку того что очередной кусок действительно выровнен. Иначе через DMA отправляем подмассив который выровнен, а начало и/или конец как придется. От современных ОС отличий никаких.
Приложение, SQL сревер и файловая система в передаче данных не участвуют.

Причем все полностью safe.
А если не полениться и прикрутить зависимые типы то ВМ на этапе компиляции проверит что все состояния протоколов обработаны. А если еще немного подумать то проверит что все обработано правильно.
Причем все будет работать с минимумом проверок ибо нафига если почти все доказано?

Здравствуйте, Pavel Dvorkin, Вы писали:

WH>>А еще я много думал на счет того как должны быть устроены правильные ОС.
PD>А то до тебя никто не думал.
Мелкософты думали. Сингулярити получилась.
Там конечно нужно выкинуть ту тупую ВМ что они использовали и спроектировать нормальную но направление ребята угадали очень не плохо.
А остальные куда то не туда думают.

PD>Объяснять я ничего не буду. Этот флейм тут уже не раз устраивался, да и Cyberax ответил,
Я ему тоже.

PD>я мог бы добавить, но и этого не буду.
Попробуй.

PD>Отмечу лишь маленькое такое передергивание. Если речь идет о файловых системах на основе SQL (вроде то ли закрытого, то ли нет проекта MS насчет SQL-файловой системы) — это может быть темой для реального проекта и темой для обсуждения.
И про них тоже. Ибо они все те же персистентные хранилища данных вот и все.

PD>А вот представление о MySQL как о дисковой подсистеме есть, извини, чушь несусветная.
С точки зрения приложения которое этот самый MySQL пользует совсем даже не чушь.

PD>И представление твое об отличии драйвере от программ есть то же самое. Элементарное непонимание основ реальной системы, с которой ты работаешь. И нежелание понять.
Если это основы то их можно расписать несколькими предложениями.
Давай попробуй.

PD>Фантастическая способность с апломбом говорить , не разбираясь совершенно в сути вопроса.
Зеркало принести?

PD>Персистентное хранилище — и все.
А что это еще?

PD>Вся история и вся практика развития ОС и ФС за 50 лет коту под хвост.
Почему?

PD>Вот до чего абстракции людей доводят, когда они не подкрепляются знанием конкретики.
Знание конкретики есть. Просто я могу кучу конкретеки обобщить и вывести общие законы.

Здравствуйте, WolfHound, Вы писали:

C>>Файловая система тесно интегрирована с ядерным менеджером кэша и системой виртуальной памяти. Т.е. фичи типа sendfile могут работать очень быстро.
WH>1)Что мешает тоже самое сделать с SQL сервером?
Ничего особого. В теории.

WH>2)В правильных ОС фичи типа sendfile не нужны ибо они будут получатся автоматически.
Каким образом?

WH>ОСь аля сингулярити. Следи за руками:
WH>1)Приложение SQL среверу: Дай мне вон тот блоб на пару гигов.
WH>2)SQL сревер файловой системе: Заверни кусок того файла от сих до сих в поток.
WH>3)Файловая система драйверу винта: Вот тебе поток сложи в него такие то блоки.
WH>4)Файловая система SQL среверу: держи поток.
WH>5)SQL сревер приложению: держи поток.
WH>6)Приложение сетевому соединению: Отправь поток.
Мимо. Сетевому драйверу просто любой поток не подойдёт. Хотя бы потому, что в теории он может отдавать по байту в час, а нам нужна сразу как можно большая непрерывная область — чтоб можно было отдать её контроллеру DMA и забыть о ней.

Далее, как поток у нас будет информацию отдавать? Кто будет буффер для них распределять?

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

Линукс сейчас всё это делает, из-за чего возможно отдавать файлы из кэша прямо в сеть с нулевыми затратами. Буквально драйверу говорят "вот этот, этот и ещё вот этот блок отправить вот туда вот", драйвер как ему там нужно программирует сетевуху, запускает DMA и всё. Благодаря TCP offloading сейчас карточки вообще всё сами могут делать.

На Ethernet'е на это ещё всё можно наплевать, сейчас пара гигабит копирования процессоры не очень затруднит. А вот на FibreChannel или InfiniBand этот overhead уже весьма и весьма заметен.

Здравствуйте, Cyberax, Вы писали:

WH>>1)Что мешает тоже самое сделать с SQL сервером?
C>Ничего особого. В теории.
Расскажи это Дворкину. В его мире это всю историю ОС перечеркивает.

WH>>2)В правильных ОС фичи типа sendfile не нужны ибо они будут получатся автоматически.
C>Каким образом?
Я написал.

C>Мимо. Сетевому драйверу просто любой поток не подойдёт. Хотя бы потому, что в теории он может отдавать по байту в час, а нам нужна сразу как можно большая непрерывная область — чтоб можно было отдать её контроллеру DMA и забыть о ней.
Ты вообще читаешь то что я пишу?
Буквально в следующем абзаце я все расписал.
А ты его проигнорировал.

C>Далее, как поток у нас будет информацию отдавать? Кто будет буффер для них распределять?
Зачем распределять?
У нас в потоке уже буферы есть.
Вот прямо из них и отдавать.
На одном конце драйвер винта или там демон кеша складывает страници, а на другом драйвер сетевухи те же самые страници достает.
В чем проблема то?

C>Далее, чтоб отдать область напрямую контроллеру DMA — нужно чтобы все фрагменты были выровнены по границе страницы. А на время траснфера нужно ещё блокировать все эти страницы в физической памяти.
Ни разу не проблема.

C>Линукс сейчас всё это делает, из-за чего возможно отдавать файлы из кэша прямо в сеть с нулевыми затратами. Буквально драйверу говорят "вот этот, этот и ещё вот этот блок отправить вот туда вот", драйвер как ему там нужно программирует сетевуху, запускает DMA и всё. Благодаря TCP offloading сейчас карточки вообще всё сами могут делать.
Ну и тут все тоже самое.

Здравствуйте, WolfHound, Вы писали:

WH>>>1)Что мешает тоже самое сделать с SQL сервером?
C>>Ничего особого. В теории.
WH>Расскажи это Дворкину. В его мире это всю историю ОС перечеркивает.
Не, я боюсь с Дворкиным спорить

C>>Далее, как поток у нас будет информацию отдавать? Кто будет буффер для них распределять?
WH>Зачем распределять?
WH>У нас в потоке уже буферы есть.
Плохие буфферы.

Для полного DMA твой вариант со специальной обработкой невыровненного начала/конца не подойдёт. В случае с Infiniband я точно знаю, что он не умеет копировать половину страницы (за исключением последней) в scatter-gather режиме. Т.е. из-за невыровненного начала тебе придётся в две транзакции копирование делать.

Плохо.

А ешё если посмотреть взаимодействие всего этого с подсистемой VM... В общем, не так тут всё просто.

Здравствуйте, Cyberax, Вы писали:

WH>>У нас в потоке уже буферы есть.
C>Плохие буфферы.
Почему?

C>Для полного DMA твой вариант со специальной обработкой невыровненного начала/конца не подойдёт.
А что современные ОС в этом смысле чем-то отличаются?

C>В случае с Infiniband я точно знаю, что он не умеет копировать половину страницы (за исключением последней) в scatter-gather режиме. Т.е. из-за невыровненного начала тебе придётся в две транзакции копирование делать.
C>Плохо.
И в современных ОС будет абсолютно тоже самое.
Те отправляя HTTP ответ нам по любому нужно будет сформировать заголовки которые и в обычной ОС с высокой вероятностью будут не выровнены на границу страницы. А то и через какойнить writev будут отправлены.
А потом отправляем файло. А там уже все хорошо. Ибо один драйвер получает выровненые данные с винта, а другой те же самые данные без единого копирования отдает в сеть.
Короче не вижу причин по которым ситуация в данном случае в управляемой ОС будет хуже чем в не управляемой.
Почему может быть лучше я написал.

C>А ешё если посмотреть взаимодействие всего этого с подсистемой VM... В общем, не так тут всё просто.
А ВМ и ОСь тут одно и тоже. Так что ВМ будет сделана с учетом всей этой низкоуровневой возни.
В смысле реализация ВМ, а модель будет без единого гвоздя.

Здравствуйте, WolfHound, Вы писали:

C>>Плохие буфферы.
WH>Почему?
Выровненность не сохраняется. Впрочем, можно реализовать что-то типа NIO в Java. Это посложнее потоков будет, но там можно требования выровненности сохранять.

C>>Плохо.
WH>И в современных ОС будет абсолютно тоже самое.
WH>Те отправляя HTTP ответ нам по любому нужно будет сформировать заголовки которые и в обычной ОС с высокой вероятностью будут не выровнены на границу страницы. А то и через какойнить writev будут отправлены.
AFAIR, nginx их выравнивает.

WH>А потом отправляем файло. А там уже все хорошо. Ибо один драйвер получает выровненые данные с винта, а другой те же самые данные без единого копирования отдает в сеть.
WH>Короче не вижу причин по которым ситуация в данном случае в управляемой ОС будет хуже чем в не управляемой.
WH>Почему может быть лучше я написал.
Да, ты прав. Только абстракцию более мощную надо выбрать, чем поток.

C>>А ешё если посмотреть взаимодействие всего этого с подсистемой VM... В общем, не так тут всё просто.
WH>А ВМ и ОСь тут одно и тоже. Так что ВМ будет сделана с учетом всей этой низкоуровневой возни.
WH>В смысле реализация ВМ, а модель будет без единого гвоздя.
Не забывай, что в FS оно ещё и с файловым кэшем интегрировано. Т.е. при давлении на память менеджер VM лишние страницы будет выкидывать.

Здравствуйте, Cyberax, Вы писали:

C>Выровненность не сохраняется.
С какого перепугу?

C>AFAIR, nginx их выравнивает.
Рад за него.
А в случае с управляемой ОС можно реализовать поток так что он при записи будет склеивать маленькие буферы в большой выровненный буфер.

C>Да, ты прав. Только абстракцию более мощную надо выбрать, чем поток.
Не надо.
Ведь мы из потока можем забирать данные разными способами.
Можем сказать дай следующие Н байт.
А можем сказать дай следующий блок такого размера какой получился.
И все! Какие блоки сложили на одной стороне такие (или лучше за счет склеивания мелочи и хвостов не выровненных) получили на другой.

C>Не забывай, что в FS оно ещё и с файловым кэшем интегрировано. Т.е. при давлении на память менеджер VM лишние страницы будет выкидывать.
И в чем проблема?
В данном случае менеджер виртуальной памяти интегрирован в саму виртуальную машину и повязан с мусорщиком.

Здравствуйте, WolfHound, Вы писали:

C>>AFAIR, nginx их выравнивает.
WH>Рад за него.
WH>А в случае с управляемой ОС можно реализовать поток так что он при записи будет склеивать маленькие буферы в большой выровненный буфер.
Это вообще-то умеет делать и libc

C>>Да, ты прав. Только абстракцию более мощную надо выбрать, чем поток.
WH>Не надо.
WH>Ведь мы из потока можем забирать данные разными способами.
WH>Можем сказать дай следующие Н байт.
Вот это поток.

WH>А можем сказать дай следующий блок такого размера какой получился.
А это уже не совсем поток.

WH>И все! Какие блоки сложили на одной стороне такие (или лучше за счет склеивания мелочи и хвостов не выровненных) получили на другой.
Надо ещё управление буфферами туда пришпилить. Т.е. я могу сделать memory mapped file, взять от него буффер (который на уровне системы будет синхронизироваться с кэшем) и отдать его передавальщику в сеть. Передавальщик посмотрит, что буффер имеет все нужные возможности — и пойдёт по fastpath'у без всякого копирования.

C>>Не забывай, что в FS оно ещё и с файловым кэшем интегрировано. Т.е. при давлении на память менеджер VM лишние страницы будет выкидывать.
WH>И в чем проблема?
WH>В данном случае менеджер виртуальной памяти интегрирован в саму виртуальную машину и повязан с мусорщиком.
Как определять когда неплохо бы из кэша чего-нибудь выбросить?

Здравствуйте, Cyberax, Вы писали:

WH>>А можем сказать дай следующий блок такого размера какой получился.
C>А это уже не совсем поток.
Ну и пусть не совсем. Короче спор о терминах нужно послать лесом.
Главное что мы получаем все удобства потока и не теряем ни в скорости ни в безопасности.

C>Надо ещё управление буфферами туда пришпилить. Т.е. я могу сделать memory mapped file, взять от него буффер (который на уровне системы будет синхронизироваться с кэшем) и отдать его передавальщику в сеть. Передавальщик посмотрит, что буффер имеет все нужные возможности — и пойдёт по fastpath'у без всякого копирования.
Это само получится.
Ибо по любому нужно интегрировать менеджер виртуальной памяти и ФС. Там конечно есть скользкие моменты но ИМХО все решаемо. Особенно если не забывать включать голову.
А все что действительно нужно потоку это заниматься склейкой мелочи и хвостов.

C>Как определять когда неплохо бы из кэша чего-нибудь выбросить?
ХЗ. Я так с ходу всю СОь с нуля спроектировать не могу.
Но не думаю что возникнут неразрешимые проблемы.

Здравствуйте, Pavel Dvorkin, Вы писали:

PD>Объяснять я ничего не буду. Этот флейм тут уже не раз устраивался, да и Cyberax ответил, я мог бы добавить, но и этого не буду.

Cyberax упомянул только оптимизации, но ничего принципиального. А оптимизации как известно имеют тенденцию устаревать и отсыхать. Вчера мы оптимизировали наши программы под 640 KB памяти, завтра будем оптимизировать под 640 ядер процессора.

Здравствуйте, Cyberax, Вы писали:
C>Плохие буфферы.
Прекрасные буферы. Главная их красота — в том, что не нужно заниматься каким-то особенным маршаллингом и договариваться о чём-то. Благодаря отсутствию аппаратной изоляции, адрес буфера можно безопасно передавать между приложениями и пользоваться им без малейших потерь.

C>Для полного DMA твой вариант со специальной обработкой невыровненного начала/конца не подойдёт.
А зачем нам полный DMA? Если мы отдаём empty.gif, то он со всеми хидерами вместе взятыми не займет и одной страницы; боттлнеком будет быстродействие сети.
А для мегабайтного pdf мы вполне можем себе позволить пару раз обратиться к драйверу сети — один раз запихать хидеры, другой раз запихать весь файл. Главное, что весь мегабайт уедет как есть — без копирования между адресными пространствами.
C>В случае с Infiniband я точно знаю, что он не умеет копировать половину страницы (за исключением последней) в scatter-gather режиме. Т.е. из-за невыровненного начала тебе придётся в две транзакции копирование делать.
Всё равно это бесконечно выгодно по сравнению с циклом file.Read(myBuffer, out readLength); socket.Send(myBuffer, readLength).
C>А ешё если посмотреть взаимодействие всего этого с подсистемой VM... В общем, не так тут всё просто.
Ага. Ну то есть получаем всего-то ничего 0.95 скорости света. По сравнению с первой космической. Ужас просто.

Здравствуйте, Sinclair, Вы писали:

C>>Плохие буфферы.
S>Прекрасные буферы. Главная их красота — в том, что не нужно заниматься каким-то особенным маршаллингом и договариваться о чём-то. Благодаря отсутствию аппаратной изоляции, адрес буфера можно безопасно передавать между приложениями и пользоваться им без малейших потерь.
Ладно, у меня ещё примеры есть Скажем, для графического ускорителя неплохо бы сразу уметь байндить текстуры (и прочие объекты, у нас же GPGPU и всё такое) в видеопамять.

Но там опять есть проблемы — нужно байндить их в специальную область физической памяти, отображаемую на видеопамять (GART Aperture), т.е. опять течёт абстракция. А ещё память в GART весьма странно ведёт себя с кэшированием — кэши надо явно сбрасывать (командой процессора cflush), иначе видеокарта их не увидит.

C>>Для полного DMA твой вариант со специальной обработкой невыровненного начала/конца не подойдёт.
S>А зачем нам полный DMA? Если мы отдаём empty.gif, то он со всеми хидерами вместе взятыми не займет и одной страницы; боттлнеком будет быстродействие сети.
А если мы занимаемся HPC (который сейчас пишут на суровом C++) и нам надо минимальную латентность иметь?

C>>В случае с Infiniband я точно знаю, что он не умеет копировать половину страницы (за исключением последней) в scatter-gather режиме. Т.е. из-за невыровненного начала тебе придётся в две транзакции копирование делать.
S>Всё равно это бесконечно выгодно по сравнению с циклом file.Read(myBuffer, out readLength); socket.Send(myBuffer, readLength).
Да кто же спорит-то? Но сейчас (да-да, вот прямо сейчас) в том же Линуксе это уже сделано нормально (с полным zero-copy в fastpath) и работает быстро. Но там и не пытались делать текущие абстракции.

C>>А ешё если посмотреть взаимодействие всего этого с подсистемой VM... В общем, не так тут всё просто.
S>Ага. Ну то есть получаем всего-то ничего 0.95 скорости света. По сравнению с первой космической. Ужас просто.
По сравнению с текущим 2*c...

Здравствуйте, Cyberax, Вы писали:
C>Ладно, у меня ещё примеры есть Скажем, для графического ускорителя неплохо бы сразу уметь байндить текстуры (и прочие объекты, у нас же GPGPU и всё такое) в видеопамять.
Не очень понятно, что такое "сразу".
C>Но там опять есть проблемы — нужно байндить их в специальную область физической памяти, отображаемую на видеопамять (GART Aperture), т.е. опять течёт абстракция.
Гм. Это как бэ проблемы драйвера видеокарты, разве нет? В том смысле, что он может озаботиться выделением текстуры таким образом, что нужный виртуальный адрес отмаплен внутрь апертуры. Тогда я могу делать вещи типа file.Read(myGARTBuffer) в своём приложениии, и обходиться минимумом копирований.

S>>А зачем нам полный DMA? Если мы отдаём empty.gif, то он со всеми хидерами вместе взятыми не займет и одной страницы; боттлнеком будет быстродействие сети.
C>А если мы занимаемся HPC (который сейчас пишут на суровом C++) и нам надо минимальную латентность иметь?
А какое отношение HPC имеет к сети? Если мы обращаемся к файлухе, то за DMA-friendly выравниванием будет следить её драйвер.

C>Да кто же спорит-то? Но сейчас (да-да, вот прямо сейчас) в том же Линуксе это уже сделано нормально (с полным zero-copy в fastpath) и работает быстро. Но там и не пытались делать текущие абстракции.

C>По сравнению с текущим 2*c...
Текущий 2*c, как я понял, мгновенно просасывает на сценариях, чуть выходящих за пределы sendfile. Для этого конкретного случая и в винде fastpath предусмотрен.
Речь-то идет о том, как юзермодным приложениям вроде SQL Server получить бенефит, аналогичный этим ядерным сервисам.

Здравствуйте, Cyberax, Вы писали:

C>Но там опять есть проблемы — нужно байндить их в специальную область физической памяти, отображаемую на видеопамять (GART Aperture), т.е. опять течёт абстракция. А ещё память в GART весьма странно ведёт себя с кэшированием — кэши надо явно сбрасывать (командой процессора cflush), иначе видеокарта их не увидит.
1)Приложение графической системе: Нужна память под текстуру.
2)Графическая система видеодрайверу: Нужна память под текстуру.
3)Видеодрайвер графической системе: Забирай.
4)Графическая система приложению: Забирай.
5)Приложение: Гружу текстуру.
6)Приложение графической системе: Забирай.
7)Графическая система видеодрайверу: Забирай.
8)Видеодрайвер графической системе: Текстура загружена.
9)Графическая система приложению: Текстура загружена.
И опять без единой протечки.
И при разборе полетов так будет со всем.

C>А если мы занимаемся HPC (который сейчас пишут на суровом C++) и нам надо минимальную латентность иметь?
Ты же вроде уже согласился что оно будет как минимум не хуже чем сейчас.

C>Да кто же спорит-то? Но сейчас (да-да, вот прямо сейчас) в том же Линуксе это уже сделано нормально (с полным zero-copy в fastpath) и работает быстро. Но там и не пытались делать текущие абстракции.
Опять 25. Куда и чего протекло?

Здравствуйте, Cyberax, Вы писали:

C>Но там опять есть проблемы — нужно байндить их в специальную область физической памяти, отображаемую на видеопамять (GART Aperture), т.е. опять течёт абстракция. А ещё память в GART весьма странно ведёт себя с кэшированием — кэши надо явно сбрасывать (командой процессора cflush), иначе видеокарта их не увидит.
Или даже так:
1)Приложение графической системе: Держи поток с текстурой.
2)Графическая система видеодрайверу: Держи поток с текстурой.
3)Видеодрайвер графической системе: Текстура загружена.
4)Графическая система приложению: Текстура загружена.

Здравствуйте, IT, Вы писали:

IT>Cyberax упомянул только оптимизации, но ничего принципиального. А оптимизации как известно имеют тенденцию устаревать и отсыхать. Вчера мы оптимизировали наши программы под 640 KB памяти, завтра будем оптимизировать под 640 ядер процессора.

Тот факт, что MS начала разработку SQL FS, говорит о том, что такая задача может быть поставлена. Вряд ли они бы начали эту разработку, не продумав идею.
Тот факт, что эта FS так и не появилась и теперь неясно, когда появится, говорит о том, что имеются , по-видимому, достаточно серьезные проблемы в ее реализации.

Обсуждать же вообще возможность такой FS в деталях я просто не имею никакого желания. Мои замечания относились просто к утверждениям WolfHound о MySQL, который к SQL FS и вообще к какой бы то ни было FS не имеет ни малейшего отношения.