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

N>Несерьёзно.

Ты просил два примера, я тебе назвал.

N> Вынеси видеодрайвер (в версиях начиная с NT4) или драйвер сетевухи

Выносить из ядра критичные к перформансу вещи — вряд ли имеет смысл. Да и суть не в том, что в каком кольце выполняется, а в модульности.

N>>>Что-то ни слова не видно про выгрузку собственно драйвера.
НС>>Disable драйвера в винде эквивалентен его выгрузке.

N>Он при этом физически удаляется из памяти?

Да.

N> И уверен ли ты в этом для случая драйвера FAT?

На 100% нет и пробовать лень, но, как тут уже сказали, при отсутствии FAT дисков он таки выгружается автоматично, так что не думаю что будут проблемы.

Здравствуйте, Ночной Смотрящий, Вы писали:

N>> Вынеси видеодрайвер (в версиях начиная с NT4) или драйвер сетевухи
НС>Выносить из ядра критичные к перформансу вещи — вряд ли имеет смысл. Да и суть не в том, что в каком кольце выполняется, а в модульности.

Твоё понимание явно не соответствует стандартному определению микроядра, для которого явно сказано:

If the hardware provides multiple rings or CPU modes, the microkernel is the only software executing at the most privileged level

Traditional operating system functions, such as device drivers, protocol stacks and file systems, are removed from the microkernel to run in user space.

Заменять это понятие на возможность собираемости из мелких модулей плохо, потому что
1) Противоречит принятому
2) Если его принять, то Linux (мы ведь с ним сравниваем?) ничем не будет отличаться. Самые тяжёлые части всё равно не HAL, его бессмысленно приводить в пример, а всякие Executive. И чтобы собрать целевую систему под какой-нибудь embedded, пилить компоненты на части, производя художественную резку лобзиком, придётся по любому. Но в Linux для этого есть готовое средство в виде конфигурации ядра, в которой можно убрать практически всё, а для Windows придётся таки резать сорцы. А драйвера идут практически все модулями, и ненужные не будут грузиться.

Кстати, классический SysV подход ещё показательнее в этом смысле — там при старте системы работал динамический линкер, который собирал ядро в памяти из отдельных модулей. Модульность современных юниксов в этом смысле — возврат к SysV, а не ориентация на другие системы, как тот же Windows.

N>>>>Что-то ни слова не видно про выгрузку собственно драйвера.
НС>>>Disable драйвера в винде эквивалентен его выгрузке.
N>>Он при этом физически удаляется из памяти?
НС>Да.
N>> И уверен ли ты в этом для случая драйвера FAT?
НС>На 100% нет и пробовать лень, но, как тут уже сказали, при отсутствии FAT дисков он таки выгружается автоматично, так что не думаю что будут проблемы.

Хотелось бы посмотреть на отчёт соответствующего инструмента.

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

D>>Да я в общем-то написал, что мне. Продолжает шуршать даже при запущенных приложениях. В результате, к примеру, DVD сразу после загрузки системы не посмотреть — лагает. Приходится ждать, пока эта дрянь закончит шуршать.
S>1. Procmon или монитор ресурсов, ищем виноватого, убиваем.

А он снова запускается, сколько ни убивай. И жрёт 99% CPU, работать невозможно, простейшее действие тормозило на минуты.
Называлась эта дрянь как-то похоже на WPF Font Cache Updater, проявлялось на XP. Причём была в двух версиях (3 и 4), приходилось раздельно каждую выключать в сервисах.
Да, это я не про Windows 8. Но случай аналогичный.

S>2. SSD + сэкономленные нервы.

SSD тут не помог бы, да и жалко его, если кто-то активно пишет ерунду вместо полезных данных.

S>3. Холивар ещё на N страниц.
S>Выбирайте

Тут за меня уже предложили самый правильный вариант пункта 4

O>Винда тоже не виснет намертво. А вот кривые 3rd party дрова — они запросто и зависнуть могут и бсоднуцца.
Мне иногда кажется, что они специально позволили дровам делать что угодно и не защитили систему от их неправильного функционирования чтобы в случае чего было на кого валить. Oтсутствие индикации, понятной обычному пользователю, о том какие именно дрова подвесили машину — тоже большой плюс

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

T>Нет, не путаю. Да, висли иксы. Но какая нафиг рабочая станция или домашний комп без ГУИ? Если в линуксе нет нормального роботающего ГУИ — это ось для серверов, для десктопов это говноось, место которой на помоичке. Именно поэтому я расматриваю линукс вместе с иксами, потому что насколько бы надежным он небыл без иксов — он нафиг такой ненужен.

Тупление Х у меня — было всегда связано с видео драйверами. С одной стороны — технически это не проблемма линукса — с другой, пользователей на ней не будет пока так. Впрочем в последние два года я ничего подобного не наблюдал(драйвер интела). Но линукс — это еще и мобильная ось, и встроенных систем.

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

O>>Винда тоже не виснет намертво. А вот кривые 3rd party дрова — они запросто и зависнуть могут и бсоднуцца.
Q>Мне иногда кажется, что они специально позволили дровам делать что угодно и не защитили систему от их неправильного функционирования чтобы в случае чего было на кого валить. Oтсутствие индикации, понятной обычному пользователю, о том какие именно дрова подвесили машину — тоже большой плюс

Гм... а почему ты думаешь, что такая индикация в принципе возможна? Если можно идентифицировать, кто виноват, то понятно, и в чём он виноват, а тогда можно и исправить его последствия.
Вот представь себе, что драйвер принял строку как указатель и намутил чего-то в левом (для него) куске памяти, который принадлежит другому драйверу. Тот второй драйвер от этого упал. И как ты выяснишь, кто виноват?

Не надо искать злого умысла там, где достаточно лени или внешних обстоятельств. Полная защита это очень дорого. Микроядро (в стандартном смысле), где всё кроме проверенного и доказанного куска сидит в своих клетках, это очень дорого — соответственно это медленно.
Почитайте великий флейм Торвальдса с Таненбаумом.

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

N>Несерьёзно. Вынеси видеодрайвер (в версиях начиная с NT4) или драйвер сетевухи, вот тогда можно будет частично приблизиться к понятию микроядра.

Надо бы сперва gdi вынести из ring0 с его ограничением 16K дескрипторов.

Здравствуйте, Ночной Смотрящий, Вы писали:

D>> Почему у меня лялих ничего не ngen-ит

НС>Потому что не умеет

Нет, скорее потому что ему это не надо.

НС>У меня тоже восьмерка сразу после старта готова, а возможные обращения к системному винту меня не колышат, особенно с учетом SSD.

Боюсь, твой SSD подохнет втрое раньше под восьмёркой, чем под лялихом.

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

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

N>>Несерьёзно. Вынеси видеодрайвер (в версиях начиная с NT4) или драйвер сетевухи, вот тогда можно будет частично приблизиться к понятию микроядра.

_>Надо бы сперва gdi вынести из ring0 с его ограничением 16K дескрипторов.

и получить такой же тормозящй гуй, как в линуксе? Спасибо, не надо.

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

S>>Зато большой файл удаляет минутами — один.
MTD>И не краснеет же

В общем, так и есть (было).
Вот замечательная история: http://www.depesz.com/2010/04/04/how-to-remove-backups/
100G файл удаляется 8 минут! Это типичное поведение ext3 из-за долбанутой системы косвенного маппинга дисковых блоков, которое иногда может достигать 3-х уровней.
В итоге админ нашел костыль. Он отрезал файл по частям с помощью truncate() с засыпаниями в промежутках, что позволило избежать слишком уж резких провалов, но растягивало удаление на оооочень долго.

ext4 изменил ситуацию к лучшему, потому что там (наконец!) появились extents, а поддержка косвенной адресации осталась для совместимости для файлов, мигрировавших из ext3/ext2.

Но даже в ext4 удаление 60G файла хавало примерно 8 секунд процессорного времени на MIPS машине. 4 секунды на сам вызов unlink() и 4 секунды съедал jbd2 во время коммита транзакции. Беда в том, что серваки обычно поставляются с невытесняющим ядром, а значит эти два этапа намертво вывешивают ядро процессора 2 раза несколько секунд каждый. На одноядернике, например в каком-нибудь простеньком армовом NAS — это пичалька.
Фиксы вышли в 3.7 для unlink() части, и в 3.11 для jbd2 части. (оптимизация по cpu на два-три порядка).

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

N>>>Несерьёзно. Вынеси видеодрайвер (в версиях начиная с NT4) или драйвер сетевухи, вот тогда можно будет частично приблизиться к понятию микроядра.
_>>Надо бы сперва gdi вынести из ring0 с его ограничением 16K дескрипторов.
eqw>и получить такой же тормозящй гуй, как в линуксе? Спасибо, не надо.

Ты даже приблизительно не знаешь, где и почему у тебя тормозит гуй, раз пишешь такое. Hint: почитай про Wayland.

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

S>>>Зато большой файл удаляет минутами — один.
MTD>>И не краснеет же
AD>В общем, так и есть (было).
AD>Вот замечательная история: http://www.depesz.com/2010/04/04/how-to-remove-backups/
AD>100G файл удаляется 8 минут! Это типичное поведение ext3 из-за долбанутой системы косвенного маппинга дисковых блоков, которое иногда может достигать 3-х уровней.

Что за чушь? При чём тут косвенные блоки? Во-первых, косвенные блоки существовали ещё в V6 Unix, и с тех пор существуют практически во всех юниксовых FS. Во-вторых, с ними подобное освобождение крупных ресурсов проходит значительно быстрее. И FS, где они есть, ведут себя очень по-разному (например, таких задержек нет на UFS, хотя там те же косвенные блоки).
Я понял, что статью Вы не читали, ограничившись проездом по первому, что взбрело в голову. А там, между прочим, сказано:

ext3, when freeing disk space is doing some kind of defragmentation, which moves some data around to maximize continuous free disk space.

К косвенным блокам этот механизм не имеет ни малейшего отношения.

AD>В итоге админ нашел костыль. Он отрезал файл по частям с помощью truncate() с засыпаниями в промежутках, что позволило избежать слишком уж резких провалов, но растягивало удаление на оооочень долго.

AD>ext4 изменил ситуацию к лучшему, потому что там (наконец!) появились extents, а поддержка косвенной адресации осталась для совместимости для файлов, мигрировавших из ext3/ext2.

Если ext4 это улучшил, то только потому, что изменил политику отношения к фрагментации. Политика в ext3 действительно была примером не вполне понятного подхода.

AD>Но даже в ext4 удаление 60G файла хавало примерно 8 секунд процессорного времени на MIPS машине.

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

AD> 4 секунды на сам вызов unlink() и 4 секунды съедал jbd2 во время коммита транзакции. Беда в том, что серваки обычно поставляются с невытесняющим ядром, а значит эти два этапа намертво вывешивают ядро процессора 2 раза несколько секунд каждый. На одноядернике, например в каком-нибудь простеньком армовом NAS — это пичалька.
AD>Фиксы вышли в 3.7 для unlink() части, и в 3.11 для jbd2 части. (оптимизация по cpu на два-три порядка).

3.11 чего, простите? На сейчас последнее доступное ядро — 3.10-rc1. У Вас машина времени?
Про недоработки в ядре в плане оптимизации этих операций — верю. Но "невытесняющее" ядро есть сильно шире, чем только на NASах.

Здравствуйте, Ночной Смотрящий, Вы писали:

НС>Какой то малолетний дурачок.

Увы, уровень аргументации не очень умного человека.

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

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

N>>>>Несерьёзно. Вынеси видеодрайвер (в версиях начиная с NT4) или драйвер сетевухи, вот тогда можно будет частично приблизиться к понятию микроядра.
_>>>Надо бы сперва gdi вынести из ring0 с его ограничением 16K дескрипторов.
eqw>>и получить такой же тормозящй гуй, как в линуксе? Спасибо, не надо.

N>Ты даже приблизительно не знаешь, где и почему у тебя тормозит гуй, раз пишешь такое. Hint: почитай про Wayland.
У меня он не тормозит, он тормозит у линуксоидов. И тормозит в том числе потому, что графическая подсистема там сделана «правильно» (овердмзайн иксов) и не засунута в ядро.
Wayland является убогой попыткой сделать это более эффективно, но находится в зачаточном состоянии и неизвестно когда будет в состоянии заменить иксы

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


AD>>100G файл удаляется 8 минут! Это типичное поведение ext3 из-за долбанутой системы косвенного маппинга дисковых блоков, которое иногда может достигать 3-х уровней.

N>Что за чушь? При чём тут косвенные блоки? Во-первых, косвенные блоки существовали ещё в V6 Unix, и с тех пор существуют практически во всех юниксовых FS. Во-вторых, с ними подобное освобождение крупных ресурсов проходит значительно быстрее. И FS, где они есть, ведут себя очень по-разному (например, таких задержек нет на UFS, хотя там те же косвенные блоки).

60G — это третий уровень косвенности. Ты представляешь каковы накладные расходы на то, чтобы пробраться через три уровня, собрать все (вполне вероятно) разбросанные по группам оконечные листья и сами косвенные блоки, зажурналировать и освободить все это дело???
Если на каких-то системах с косвенной адресацией удаление 60G файла не тормозит, то только потому, что реальное освобождение отложено во времени, либо выполнялось в фоне.
Все современные и даже не очень ФС (ext4, jfs, xfs, ntfs, hfs) используют экстенты, потому что косвенная адресация сосет на больших файлах.

N>Я понял, что статью Вы не читали, ограничившись проездом по первому, что взбрело в голову. А там, между прочим, сказано:
N>

ext3, when freeing disk space is doing some kind of defragmentation, which moves some data around to maximize continuous free disk space.

N>К косвенным блокам этот механизм не имеет ни малейшего отношения.
Статью я читал. Дефрагментация — это заблуждение автора статьи, который где-то что-то слышал.
Тормоза из-за косвенной адресации и фрагментации.

AD>>ext4 изменил ситуацию к лучшему, потому что там (наконец!) появились extents, а поддержка косвенной адресации осталась для совместимости для файлов, мигрировавших из ext3/ext2.
N>Если ext4 это улучшил, то только потому, что изменил политику отношения к фрагментации. Политика в ext3 действительно была примером не вполне понятного подхода.

Что есть "политика отношения к фрагментации"?
ext4 стал гораздо быстрее из-за поддержки экстентов (т.е. отсутствия косвенности), multi-block аллокатора (в ext3 место выделяется поблочно, даже если запросить стопицот мегабайт сразу), и delalloc (отложенное выделение места, чтоб снизить фрагментацию).

AD>>Но даже в ext4 удаление 60G файла хавало примерно 8 секунд процессорного времени на MIPS машине.
N>Простите, а что Вы ещё хотели? И журнал чего-то стоит, и запись факта свободного места в таблицы распределения, и обновление суммарных данных — это всё чего-то стоит.
В случае ext4 это был пузырек, который я заменил на quick sort.

N>3.11 чего, простите? На сейчас последнее доступное ядро — 3.10-rc1. У Вас машина времени?
3.10, опечатался.

Здравствуйте, netch80, Вы писали:
AD>>Но даже в ext4 удаление 60G файла хавало примерно 8 секунд процессорного времени на MIPS машине.

N>Простите, а что Вы ещё хотели? И журнал чего-то стоит, и запись факта свободного места в таблицы распределения, и обновление суммарных данных — это всё чего-то стоит.

Почему мелкософт еще 20 лет назад смогла сделать надежную быструю ФС, не страдающую подобными проблемами, а линукс досихпор не может родить что-нить юзабельное?

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

T>Почему мелкософт еще 20 лет назад смогла сделать надежную быструю ФС, не страдающую подобными проблемами, а линукс досихпор не может родить что-нить юзабельное?

Это какая?

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

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

T>>Почему мелкософт еще 20 лет назад смогла сделать надежную быструю ФС, не страдающую подобными проблемами, а линукс досихпор не может родить что-нить юзабельное?

MTD>Это какая?
NTFS

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

T>Здравствуйте, netch80, Вы писали:
AD>>>Но даже в ext4 удаление 60G файла хавало примерно 8 секунд процессорного времени на MIPS машине.

N>>Простите, а что Вы ещё хотели? И журнал чего-то стоит, и запись факта свободного места в таблицы распределения, и обновление суммарных данных — это всё чего-то стоит.

T>Почему мелкософт еще 20 лет назад смогла сделать надежную быструю ФС, не страдающую подобными проблемами, а линукс досихпор не может родить что-нить юзабельное?

У Вас есть опыт использования NTFS на MIPS машине средней производительности с файлами по 60GB?
Если да — поделитесь. Если нет — Вашим утверждениям и Вашему пафосу цена ноль целых хер десятых.

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

AD>>>100G файл удаляется 8 минут! Это типичное поведение ext3 из-за долбанутой системы косвенного маппинга дисковых блоков, которое иногда может достигать 3-х уровней.
N>>Что за чушь? При чём тут косвенные блоки? Во-первых, косвенные блоки существовали ещё в V6 Unix, и с тех пор существуют практически во всех юниксовых FS. Во-вторых, с ними подобное освобождение крупных ресурсов проходит значительно быстрее. И FS, где они есть, ведут себя очень по-разному (например, таких задержек нет на UFS, хотя там те же косвенные блоки).
AD>60G — это третий уровень косвенности. Ты представляешь каковы накладные расходы на то, чтобы пробраться через три уровня, собрать все (вполне вероятно) разбросанные по группам оконечные листья и сами косвенные блоки, зажурналировать и освободить все это дело???

Представляю, чего тут не представлять. Предположим 1KB блок (сейчас такое редко увидишь, но пусть). 60 миллионов блоков данных — 240 тысяч косвенных блоков (для простоты, уровни дальше последнего не считаем), а в общем случае это 4/1024 == 1/256 от всех занятых блоков, то есть меньше процента — можно их не учитывать. Теперь в таблицах занятости надо поставить признаки свободности всех этих блоков. Предположим, что это всё битовые карты. Тогда они потратят 8000 блоков этих самых карт. Теперь оценим, сколько займут 1) 240000 чтений блоков, 2) 8000 чтений и записей блоков? Даже такое дорогое чтение это пара секунд. Запись свободных — ещё быстрее.

Я не против экстентов, я против взваливания проблем ext3 на механизм, который не способен их обеспечить. Ещё на UFS1 (FreeBSD) у нас были файлы ну не по 100, но по 10GB. По-Вашему они должны были удаляться около минуты, потому что идёт очень много возни с косвенными блоками? А на практике файл удалялся практически мгновенно (задержка не замечалась человеком). Разумеется, часть затрат сокращалась за счёт более разумного размера блока (8KB по умолчанию), но даже это не сократило бы время менее чем до 10 секунд, если бы Ваши оценки источников затрат были адекватными.

Так что болезни ext3 в чём-то другом. Например, в неадекватной работе с журналом или, в общем случае, в чрезмерной грануляции операций.

AD>Если на каких-то системах с косвенной адресацией удаление 60G файла не тормозит, то только потому, что реальное освобождение отложено во времени, либо выполнялось в фоне.
AD>Все современные и даже не очень ФС (ext4, jfs, xfs, ntfs, hfs) используют экстенты, потому что косвенная адресация сосет на больших файлах.

Ещё раз: что значит "тормозит"? Удалять такой (60, 100GB), файл пусть даже 10 секунд — я согласен, накладные расходы хоть как-то, но связаны именно с косвенными блоками. 8 минут — нет, ищите причину в другом.

N>>Я понял, что статью Вы не читали, ограничившись проездом по первому, что взбрело в голову. А там, между прочим, сказано:
N>>

ext3, when freeing disk space is doing some kind of defragmentation, which moves some data around to maximize continuous free disk space.

N>>К косвенным блокам этот механизм не имеет ни малейшего отношения.
AD>Статью я читал. Дефрагментация — это заблуждение автора статьи, который где-то что-то слышал.

Пусть так.

AD>Тормоза из-за косвенной адресации и фрагментации.

Первое мы уже разобрали и я с ним не соглашусь. Второе — что Вы имеете в виду под фрагментацией? То, что файл разбросан по диску, или что-то другое?

AD>>>ext4 изменил ситуацию к лучшему, потому что там (наконец!) появились extents, а поддержка косвенной адресации осталась для совместимости для файлов, мигрировавших из ext3/ext2.
N>>Если ext4 это улучшил, то только потому, что изменил политику отношения к фрагментации. Политика в ext3 действительно была примером не вполне понятного подхода.
AD>Что есть "политика отношения к фрагментации"?

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

AD>ext4 стал гораздо быстрее из-за поддержки экстентов (т.е. отсутствия косвенности), multi-block аллокатора (в ext3 место выделяется поблочно, даже если запросить стопицот мегабайт сразу), и delalloc (отложенное выделение места, чтоб снизить фрагментацию).

AD>>>Но даже в ext4 удаление 60G файла хавало примерно 8 секунд процессорного времени на MIPS машине.
N>>Простите, а что Вы ещё хотели? И журнал чего-то стоит, и запись факта свободного места в таблицы распределения, и обновление суммарных данных — это всё чего-то стоит.
AD>В случае ext4 это был пузырек, который я заменил на quick sort.

Ну я бы не сказал, что пузырёк был жёстко обусловлен использованием концепций ext3.