The OpenNET Project / Index page

[ новости /+++ | форум | теги | ]



Вариант для распечатки  
Пред. тема | След. тема 
Форум Разговоры, обсуждение новостей
Режим отображения отдельной подветви беседы [ Отслеживать ]

Оглавление

OpenNews: Надёжность Linux, Unix и Windows серверов в цифрах, opennews (ok), 17-Апр-08, (0) [смотреть все]

Сообщения [Сортировка по времени | RSS]


26. "глупость"  +/
Сообщение от Luke (??), 18-Апр-08, 23:50 
>Это мне напоминает про среднюю температуру в больнице. А может это просто
>опыт и знания админов выросли а не надёжность систем?

А если поговорить о надежности - в Windows как ни крути, а заменить выполняемое в данный момент файло без ребута проблематично.Особенно весело с DLL - они загружены кучей программ вплоть до процессов системы.Как ни крути а просто выгрузить и заменить - не выйдет.

Ответить | Правка | Наверх | Cообщить модератору

27. "глупость"  +/
Сообщение от vitek (??), 19-Апр-08, 13:55 
и все это связано с виртуальным адресным пространством. dll-ки являются swap'ом для себя. И при фрагментации все это работает все медленнее и медленнее.
Ответить | Правка | Наверх | Cообщить модератору

28. "глупость"  +/
Сообщение от Nickemail (??), 19-Апр-08, 13:59 
>и все это связано с виртуальным адресным пространством

не более чем с тупорылой политикой мягкотелой конторы.

В нормальных системах заюзанную шареную либу без проблем можно переписать,
а если она не полностью зачитана (и в таком случае не может быть переписана,
равно как и любой бинарь в подобном случае) - то уж переименовать ее и создать новую
с оригинальным именем - нет проблем.
Последующий рестарт ПРОГРАММ, использующих сию либу - уже будут с ее новой версией.

Так работают системы, от которых нужна работа, а не уровень продаж.


>dll-ки являются swap'ом для себя. И при фрагментации все это работает все медленнее и медленнее.

где таритесь?? ;)

Ответить | Правка | Наверх | Cообщить модератору

29. "глупость"  +/
Сообщение от nuclightemail (ok), 20-Апр-08, 00:25 
>[оверквотинг удален]
>не более чем с тупорылой политикой мягкотелой конторы.
>
>В нормальных системах заюзанную шареную либу без проблем можно переписать,
>а если она не полностью зачитана (и в таком случае не может
>быть переписана,
>равно как и любой бинарь в подобном случае) - то уж переименовать
>ее и создать новую
>с оригинальным именем - нет проблем.
>Последующий рестарт ПРОГРАММ, использующих сию либу - уже будут с ее новой
>версией.

Че? Каша какая-то в голове. В нормальных системах - это отделение файлового объекта от его имени в слое VFS, в результате чего имя файла отделено от него самого, и его можно удалять, vnode же останется, пока используется. А в винде жесткая привязка по имени, поэтому файл намертво залочен.

>>dll-ки являются swap'ом для себя. И при фрагментации все это работает все медленнее и медленнее.
>
>где таритесь?? ;)

В учебнике по операционным системам. Любая современная ось это использует - text-страницы бинарника мапятся непосредственно из его файла, данные процесса swap-backed. Text-страницы - file-backed, но механизм подкачки тот же самый.

Ответить | Правка | Наверх | Cообщить модератору

30. "глупость"  +/
Сообщение от _Nick_email (??), 20-Апр-08, 00:43 
>Че? Каша какая-то в голове. В нормальных системах - это отделение файлового
>объекта от его имени в слое VFS, в результате чего имя
>файла отделено от него самого, и его можно удалять, vnode же
>останется, пока используется. А в винде жесткая привязка по имени, поэтому
>файл намертво залочен.

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

>В учебнике по операционным системам. Любая современная ось это использует - text-страницы
>бинарника мапятся непосредственно из его файла, данные процесса swap-backed.
>Text-страницы - file-backed, но механизм подкачки тот же самый.

У кого еще каша...
своппинг и маппинг перепутать и обозвать одним и тем же...
Своппинг использует маппинг, но не наоборот. А раз не наоборот - то называть одно
другим во всех случаях нельзя. А именно этим товарисч и отметился:

"dll-ки являются swap'ом для себя"

не swap'ом они для себя являются, а мапятся в процесс.

Ответить | Правка | Наверх | Cообщить модератору

33. "глупость"  +/
Сообщение от nuclightemail (ok), 20-Апр-08, 13:29 
>>Че? Каша какая-то в голове. В нормальных системах - это отделение файлового
>>объекта от его имени в слое VFS, в результате чего имя
>>файла отделено от него самого, и его можно удалять, vnode же
>>останется, пока используется. А в винде жесткая привязка по имени, поэтому
>>файл намертво залочен.
>
>и в каком же месте я противоречу вашим светлым мыслям, о великий?
>кашки вы где-то в другом месте хлебнули.

Каша и противоречие в том, что открывать исполняемый бинарник на запись для его замены - грзяный хак. Правильный способ апдейта - его unlink() и создание нового, что опирается на вышеуказанное отделение имени файла от самого файла. И, следовательно, это отделение в *nix, коли уж шло сравнение с виндой, должно было быть четко и ясно описано.

>[оверквотинг удален]
>
>У кого еще каша...
>своппинг и маппинг перепутать и обозвать одним и тем же...
>Своппинг использует маппинг, но не наоборот. А раз не наоборот - то
>называть одно
>другим во всех случаях нельзя. А именно этим товарисч и отметился:
>
>"dll-ки являются swap'ом для себя"
>
>не swap'ом они для себя являются, а мапятся в процесс.

Марш в учебник - все Mach-derived VM-подсистемы рассматривают ОЗУ лишь как кэш для дисковых объектов. У операционной системы метод един - paging. Будет ли это anonymous backing свопа или вполне себе именованный файл - без разницы. В обоих случаях ось может спокойно выкинуть страницы файла из ОЗУ и потом подгрузить их обратно при надобности.

Ответить | Правка | Наверх | Cообщить модератору

35. "глупость"  +/
Сообщение от _Nick_email (??), 20-Апр-08, 14:56 
>Каша и противоречие в том, что открывать исполняемый бинарник на запись для
>его замены - грзяный хак.

разговор был возможно или нет.
Кста, об исполнимых бинарях я действительно перегнул. Они блокирутся при exec()е.
Но либы - нет (хотя тут вопрос доступа и желаний самой программы).
Посему даже используемые либы можно открыть на запись и переписать.
Другое дело, что проги такого не ожидают и просто падают как только управление
доходит до подмененного объекта. Ессьно, это нельзя рассматривать как метод обновления,
а мы этого и не делаем.


>Правильный способ апдейта - его unlink()
>и создание нового, что опирается на вышеуказанное отделение имени файла от
>самого файла. И, следовательно, это отделение в *nix, коли уж шло
>сравнение с виндой, должно было быть четко и ясно описано.

эт все понятно.


>Марш в учебник

Так и добавляй же сразу, что в учебник по бздям.

>- все Mach-derived VM-подсистемы рассматривают ОЗУ лишь как кэш
>для дисковых объектов.

Ну вот и нашли разницу. Для Линуха ОЗУ - это как раз дом родной, т.к. это самая быстрая
память в системе (после кешей проца).


>У операционной системы метод един - paging. Будет
>ли это anonymous backing свопа или вполне себе именованный файл -
>без разницы. В обоих случаях ось может спокойно выкинуть страницы файла
>из ОЗУ и потом подгрузить их обратно при надобности.

Ну вот и славно. И ты прав - и я прав. Нужно было лишь изначально оговориться о чем речь.
У Линуха нет такой любви к свопингу. Работа с файлами и девайсами (даже тем же свопиком)
идет через буфера ОЗУ. Свопик (кстати, тоже буферизированный) используется лишь при нехватке ОЗУ. Если же ее хватает - своппинг не будет иметь место.

Ответить | Правка | Наверх | Cообщить модератору

39. "глупость"  +/
Сообщение от nuclightemail (ok), 23-Апр-08, 16:27 
>Посему даже используемые либы можно открыть на запись и переписать.
>Другое дело, что проги такого не ожидают и просто падают как только
>управление
>доходит до подмененного объекта. Ессьно, это нельзя рассматривать как метод обновления,
>а мы этого и не делаем.

Хехе. Вон, человек ниже доказывает, что так переписывать - и есть самый правильный способ :)

>Так и добавляй же сразу, что в учебник по бздям.
>>- все Mach-derived VM-подсистемы рассматривают ОЗУ лишь как кэш
>>для дисковых объектов.
>Ну вот и нашли разницу. Для Линуха ОЗУ - это как раз
>дом родной, т.к. это самая быстрая
>память в системе (после кешей проца).

В учебник по операционным системам. Архитектурные принципы те же (ОЗУ лишь кэш для диска), и разница лишь в константах тюнинга (политиках замещения кэша).

>[оверквотинг удален]
>>ли это anonymous backing свопа или вполне себе именованный файл -
>>без разницы. В обоих случаях ось может спокойно выкинуть страницы файла
>>из ОЗУ и потом подгрузить их обратно при надобности.
>
>Ну вот и славно. И ты прав - и я прав. Нужно
>было лишь изначально оговориться о чем речь.
>У Линуха нет такой любви к свопингу. Работа с файлами и девайсами
>(даже тем же свопиком)
>идет через буфера ОЗУ. Свопик (кстати, тоже буферизированный) используется лишь при нехватке
>ОЗУ. Если же ее хватает - своппинг не будет иметь место.

Да есть, см. выше...

Ответить | Правка | Наверх | Cообщить модератору

40. "глупость"  +/
Сообщение от Nickemail (??), 24-Апр-08, 20:53 
>Хехе. Вон, человек ниже доказывает, что так переписывать - и есть самый
>правильный способ :)

видать, он ни разу не пробовал даже жалкую сошку находу переписать :)


>>Ну вот и нашли разницу. Для Линуха ОЗУ - это как раз
>>дом родной, т.к. это самая быстрая
>>память в системе (после кешей проца).
>
>В учебник по операционным системам.

учебники - хорошо :) но учебники далеко и серьезно отстают от _текущего_ ядра Линукс.
Ну что поделаешь, если его пишут/оптимизируют, не особо взирая на классические стандарты (с POSIX он тоже не полностью совместим), но с обратной совместимостью для user-level'a? :)
За сим, учебники стоит читать лишь по началу. Потом уже нужно читать только ядро.
Иначе, адекватность будет лишь мнимой.


>Архитектурные принципы те же (ОЗУ лишь кэш для диска)

нет. В корне не согласен :)
Это внешне невооруженным глазом так кажется, что ОЗУ лишь кеш.
И не вдаваясь в подробности можно так думать и все будет замечательно.
На работу системы такое расхождение мнения админа с работой ядра никак не скажется.
Но дело как раз в том, что архитектура рассматривает загрузку с диска как ситуацию,
когда нужного блока во внутренних структурах VFS нет.
Так он написано.
Чем оно кажется со стороны - дело десятое :)


>и разница лишь в константах тюнинга (политиках замещения кэша).

Ну, эти константы в Линухе и BSD разные, и их назначение разное.
Посему, не буду никак столь разные множества рулей коментировать :)

Ответить | Правка | Наверх | Cообщить модератору

41. "глупость"  +/
Сообщение от nuclightemail (ok), 25-Апр-08, 10:40 
>[оверквотинг удален]
>>В учебник по операционным системам.
>
>учебники - хорошо :) но учебники далеко и серьезно отстают от _текущего_
>ядра Линукс.
>Ну что поделаешь, если его пишут/оптимизируют, не особо взирая на классические стандарты
>(с POSIX он тоже не полностью совместим), но с обратной совместимостью
>для user-level'a? :)
>За сим, учебники стоит читать лишь по началу. Потом уже нужно читать
>только ядро.
>Иначе, адекватность будет лишь мнимой.

Вы путаете учебники с книгами по ядру конкретной ОСи или стандартами. Они да, устаревают. А фундаментальные архитектурные принципы, излагаемые в общих учебниках по операционным системам, они не меняются.

>[оверквотинг удален]
>Это внешне невооруженным глазом так кажется, что ОЗУ лишь кеш.
>И не вдаваясь в подробности можно так думать и все будет замечательно.
>
>На работу системы такое расхождение мнения админа с работой ядра никак не
>скажется.
>Но дело как раз в том, что архитектура рассматривает загрузку с диска
>как ситуацию,
>когда нужного блока во внутренних структурах VFS нет.
>Так он написано.
>Чем оно кажется со стороны - дело десятое :)

Это вам так со стороны кажется. Но архитектурно - это именно кэш, я выше по треду названия упоминал, куда смотреть.

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

Ответить | Правка | Наверх | Cообщить модератору

42. "глупость"  +/
Сообщение от Nickemail (??), 25-Апр-08, 10:54 
>Вы путаете учебники с книгами по ядру конкретной ОСи или стандартами. Они
>да, устаревают. А фундаментальные архитектурные принципы, излагаемые в общих учебниках по
>операционным системам, они не меняются.

извиняюсь, но "уморил" :)

Если будет обнаружено, что нечто "вот это" если его сделать "вот так" и
все нечнет летать быстрее - то никто из разработчиков и ухом не моргнет заюзать
этот метод для внутриядерных делов, подходит сей метод к "фундаментальным архитектурным принципам" или нет и будет прав. Админу/клиенту/пользователю нужна производительность,
а не абстрактные науки.
Более того, я не берусь утверждать, что такого не было уже в истории Линукса.
Скорее наоборот, было (хотя бы потому, что он не полностью POSIX совместим).
И можете меня посылать в любые книги за любыми названиями, но работа Линукс ядра (которое есть авторити де-факто по архитектуре самого себя %) никуда не денется.


>Это вам так со стороны кажется. Но архитектурно - это именно кэш,
>я выше по треду названия упоминал, куда смотреть.

да все понятно. Сути это не меняет. Размер внутренних стурктур VFS даже считаются
в глобальный "Cache".
Вобщем, "называй меня как хочешь, мой господин" %)
Просто код Линуха построен на том, что все живет в памяти, а если чего нет - подгружается.
Это следует как минимум из названий функций и коменариев.
Остальное - кому как нравиться :)

Понимаете, у Линкса очень специфичный отец ;)
Ему главное - технологии, а не кто где что как назвал и какие права на это заимел.
И - как мы видим - это работает :)


>Если так не доходит, можете по аналогии посмотреть на кэш любого современного
>процессора - у него прямого доступа к памяти точно так же
>нет, все проходит через кэш.

1. я не утверждал, что данные файлов проходят НЕ через ОЗУ
2. вы ищете аналогию в архитектуре процессора и ядра. В данном случае оно совпало лишь по одной причине: буферизация - это путь ускорить работу. Это справедливо в очень многих системах. И, вообще, к данному спору никак не относится. Я не оспаривал пользу кеширования.

Может как раз в том и проблема, что непонятно ЧТО я оспаривал :)
Возможно, просто названия функций ядра Линуха :)

Ответить | Правка | Наверх | Cообщить модератору

36. "глупость"  +/
Сообщение от Luke (??), 21-Апр-08, 16:20 
>Каша и противоречие в том, что открывать исполняемый бинарник на запись для
>его замены - грзяный хак.

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

>Правильный способ апдейта - его unlink()
>и создание нового, что опирается на вышеуказанное отделение имени файла от
>самого файла.

Ага, конечно, хитрожопо прикрученый костыль теперь называется правильным решением.А все потому что это называется "двойные стандарты".Если в любомой системе, архитектуре и т.п. сделано через попу - надо сказать что на самом деле это рулез а через попу у всех кто не согласен.Гениальная логика в полном согласии с "каждый кулик хвалит свое болото".Лично я не вижу зачем плодить лишние сущности и все усложнять.Ничего кроме геморроя и глюков от этого не бывает.Что может быть проще обычной записи в файл без всякого траходрома???


>И, следовательно, это отделение в *nix, коли уж шло
>сравнение с виндой, должно было быть четко и ясно описано.

А в винде вообще нет нормального метода замены загруженного в данный момент файла без ребута.Особенно системных DLL касается.Как максимум, можно переименовать файло, передвинув его в другое место (при том только в пределах одного диска, между дисками двигать такие файлы нельзя - привет от нелинейной файловой системы) и положить на его место новый файл.Который однако никто кроме вновь запущенных программ юзать не будет до ребута.В итоге получается что ребут необходим чтобы все программы юзали новую версию ДЛЛ и чтобы завершить удаление файла (стереть переиенованный файл до ребуте ессно нельзя, он используется).

>>"dll-ки являются swap'ом для себя"

И exe-файлы тоже являются свопом для себя.

>>не swap'ом они для себя являются, а мапятся в процесс.

С целью замены своп-файла.Страницы вместо выгрузки в своп просто отбрасываются.Потом при нужде догружаются из образа EXE или DLL с диска.Потому и лочится намертво, собственно.А если б не лочилось - при удалении или замене такого файла все бы крашилось нафиг да и все дела.Довольно дурная затея в целом - получается очень фрагментированный фариант свопа, а экономия на сбросе страниц в своп не столь уж велика, а вот трах с апдейтами - знатный.Просто сие тупорыльство было придумано в те давние поры когда никто еще не собирался заменять системные файлы for security reasons на ходу.

>Марш в учебник - все Mach-derived VM-подсистемы рассматривают ОЗУ лишь как кэш
>для дисковых объектов.

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

>ли это anonymous backing свопа или вполне себе именованный файл -
>без разницы.

Смотря с какой стороны смотреть.Незаменяемость большого своп-файла всем до балды.Незаменяемость бинарника создает траходром с апдейтами.Ы?

Ответить | Правка | К родителю #33 | Наверх | Cообщить модератору

37. "глупость"  +/
Сообщение от nuclightemail (ok), 23-Апр-08, 16:16 
>О, писец, дожили.Просто запись в файл - это уже, оказывается, грязный хак
>называется!А костыльные методы - это оказывается правильно.А

[...]
>Ага, конечно, хитрожопо прикрученый костыль теперь называется правильным решением.А все потому что
>это называется "двойные стандарты".Если в любомой системе, архитектуре и т.п. сделано
>через попу - надо сказать что на самом деле это рулез
>а через попу у всех кто не согласен.Гениальная логика в полном
>согласии с "каждый кулик хвалит свое болото".Лично я не вижу зачем
>плодить лишние сущности и все усложнять.Ничего кроме геморроя и глюков от
>этого не бывает.Что может быть проще обычной записи в файл без
>всякого траходрома???

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

>[оверквотинг удален]
>А в винде вообще нет нормального метода замены загруженного в данный момент
>файла без ребута.Особенно системных DLL касается.Как максимум, можно переименовать файло, передвинув
>его в другое место (при том только в пределах одного диска,
>между дисками двигать такие файлы нельзя - привет от нелинейной файловой
>системы)
> и положить на его место новый файл.Который однако никто кроме
>вновь запущенных программ юзать не будет до ребута.В итоге получается что
>ребут необходим чтобы все программы юзали новую версию ДЛЛ и чтобы
>завершить удаление файла (стереть переиенованный файл до ребуте ессно нельзя, он
>используется).

Сколько умных слов, да вот только это уже было рассказано выше по треду. Лучше объясните-ка, что такое "нелинейная файловая система" ? Вы где такой термин нашли?

>>>"dll-ки являются swap'ом для себя"
>
>И exe-файлы тоже являются свопом для себя.
>
>>>не swap'ом они для себя являются, а мапятся в процесс.
>
>С целью замены своп-файла.Страницы вместо выгрузки в своп просто отбрасываются.Потом при нужде
>догружаются из образа EXE или DLL с диска.Потому и лочится намертво,
>собственно.А если б не лочилось - при удалении или замене такого
>файла все бы крашилось нафиг да и все дела.

И снова вы рассказываете банальности, которые и так известны либо были рассказаны выше по треду. Зачем? Хотите казаться умнее?..

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

Вещаете глупости с умным видом, да еще и без конкретных замеров в руках. Это не тупорыльство, а единая схема работы для всех видов отображения данных в память, будь то исполняемый код или просто mmap() фа

>[оверквотинг удален]
>попытаться ее в свопе накопать.А если уже и там нету -
>ой, приехали.Получается такая вот безразмерная оперативка в итоге которую при нужде
>можно расширить куда-то.Ну там на диск или еще в какое-то хранилище
>не адресуемое напрямую.
>
>>ли это anonymous backing свопа или вполне себе именованный файл -
>>без разницы.
>
>Смотря с какой стороны смотреть.Незаменяемость большого своп-файла всем до балды.Незаменяемость бинарника создает
>траходром с апдейтами.Ы?

Ответить | Правка | Наверх | Cообщить модератору

38. "глупость"  +/
Сообщение от nuclightemail (ok), 23-Апр-08, 16:17 
>О, писец, дожили.Просто запись в файл - это уже, оказывается, грязный хак
>называется!А костыльные методы - это оказывается правильно.А

[...]
>Ага, конечно, хитрожопо прикрученый костыль теперь называется правильным решением.А все потому что
>это называется "двойные стандарты".Если в любомой системе, архитектуре и т.п. сделано
>через попу - надо сказать что на самом деле это рулез
>а через попу у всех кто не согласен.Гениальная логика в полном
>согласии с "каждый кулик хвалит свое болото".Лично я не вижу зачем
>плодить лишние сущности и все усложнять.Ничего кроме геморроя и глюков от
>этого не бывает.Что может быть проще обычной записи в файл без
>всякого траходрома???

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

>[оверквотинг удален]
>А в винде вообще нет нормального метода замены загруженного в данный момент
>файла без ребута.Особенно системных DLL касается.Как максимум, можно переименовать файло, передвинув
>его в другое место (при том только в пределах одного диска,
>между дисками двигать такие файлы нельзя - привет от нелинейной файловой
>системы)
> и положить на его место новый файл.Который однако никто кроме
>вновь запущенных программ юзать не будет до ребута.В итоге получается что
>ребут необходим чтобы все программы юзали новую версию ДЛЛ и чтобы
>завершить удаление файла (стереть переиенованный файл до ребуте ессно нельзя, он
>используется).

Сколько умных слов, да вот только это уже было рассказано выше по треду. Лучше объясните-ка, что такое "нелинейная файловая система" ? Вы где такой термин нашли?

>>>"dll-ки являются swap'ом для себя"
>
>И exe-файлы тоже являются свопом для себя.
>
>>>не swap'ом они для себя являются, а мапятся в процесс.
>
>С целью замены своп-файла.Страницы вместо выгрузки в своп просто отбрасываются.Потом при нужде
>догружаются из образа EXE или DLL с диска.Потому и лочится намертво,
>собственно.А если б не лочилось - при удалении или замене такого
>файла все бы крашилось нафиг да и все дела.

И снова вы рассказываете банальности, которые и так известны либо были рассказаны выше по треду. Зачем? Хотите казаться умнее?..

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

Вещаете глупости с умным видом, да еще и без конкретных замеров в руках. Это не тупорыльство, а единая схема работы для всех видов отображения данных в память, будь то исполняемый код или просто mmap() файлов с данными.

>>Марш в учебник - все Mach-derived VM-подсистемы рассматривают ОЗУ лишь как кэш
>>для дисковых объектов.
>
>Не знаю, винда и т.п. скорее рассматривают диск как оперативку.Пусть и медленную.Собственно
>идея свопа проста как топор - если возникло исключение "страницы нет",
>попытаться ее в свопе накопать.А если уже и там нету -
>ой, приехали.Получается такая вот безразмерная оперативка в итоге которую при нужде
>можно расширить куда-то.Ну там на диск или еще в какое-то хранилище
>не адресуемое напрямую.

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

>>ли это anonymous backing свопа или вполне себе именованный файл -
>>без разницы.
>
>Смотря с какой стороны смотреть.Незаменяемость большого своп-файла всем до балды.Незаменяемость бинарника создает
>траходром с апдейтами.Ы?

Кому создает? Винде? Так это только винды проблема, в нормальных системах все просто.

Ответить | Правка | К родителю #36 | Наверх | Cообщить модератору

31. "глупость"  +/
Сообщение от _Nick_email (??), 20-Апр-08, 00:55 
>В учебнике по операционным системам

кста, смотрю человек грамотный, книжки читает...

А не скажет ли сей грамотный гражданин всегда ли можно открыть бинарник,
исполняющегося из него процесса на запись? :) Речь будем вести о 2.6 линухе
(относительно свежем: >=2.6.9)

Ответить | Правка | К родителю #29 | Наверх | Cообщить модератору

32. "глупость"  +/
Сообщение от nuclightemail (ok), 20-Апр-08, 13:15 
>>В учебнике по операционным системам
>
>кста, смотрю человек грамотный, книжки читает...
>
>А не скажет ли сей грамотный гражданин всегда ли можно открыть бинарник,
>
>исполняющегося из него процесса на запись? :) Речь будем вести о 2.6
>линухе
>(относительно свежем: >=2.6.9)

Не знаю, как у вас в линухе, а системы на базе 4.4BSD возвращают ETXTBSY в таких случаях от рождения (т.е. более 13 лет).

Ответить | Правка | Наверх | Cообщить модератору

34. "глупость"  +/
Сообщение от _Nick_email (??), 20-Апр-08, 14:41 
>Не знаю, как у вас в линухе, а системы на базе 4.4BSD
>возвращают ETXTBSY в таких случаях от рождения (т.е. более 13 лет).

чем больше тем лучше? ;)

не баись, Линух тоже самое делает ;)  уже более 15 лет!! :D

Ответить | Правка | Наверх | Cообщить модератору

Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема




Партнёры:
PostgresPro
Inferno Solutions
Hosting by Hoster.ru
Хостинг:

Закладки на сайте
Проследить за страницей
Created 1996-2024 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру