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

Нет, это отдельная ИС.

В общем-то, навскидку, ему нужно всего ничего: 2-4 байта на каждый кластер (не знаю какая там минимальная единица данных с точки зрения контроллера, допустим 4 кб) - это для того что бы при каждом обращении к ячейки увеличивать счечик, и когда число приближается к «критической точке» - надо поменять его с редко используемым кластером местами. 2 байта на 4 кб - это всего несколько десятков мегабайт на весь SSD.

Всё не так просто. В процессор заложены алгоритмы обновления ячеек, распределения данных (основная нагрузка при таком > 100 МБ/сек потоке данных) равномерно «по поверхности» и другие «сервисные» функции для SSD.

>Каким образом? Дать мобильные телефоны знакомых системных администраторов, которые меняли/сдавали их по гарантии??? Вы же не школьнег чтобы «чушь про Пруф» спрашивать?! Насколько я понял. Или же ошибся?

Я думаю, если бы такие проблемы были, причем в массовом порядке, как вы говорите, то это неизбежно всплыло бы на форумах, блогах и т.д. Я такого не слышал, потому и спрашиваю.

Вы же не школьнег чтобы «чушь про Пруф» спрашивать?!

А почему Вас так удивляет просьба подтвердить свои слова ссылкой? По моему, вполне нормально относится к подобной информации со здоровым скептицизмом, или вы предлагаете любому анонимусу с ЛОРа верить на слово? :)

Формула неверна по сути. Посудите сами - 64ГБ х 1 ячейку (100000 циклов = надёжность 1-ой ячейки!). Это если вы будете хранить 1 байт!!!! А если раз в неделю перезаписывается 10-12 ГБ? Кроме того, ячейка (физический размер) может отличаться (и скорее всего, отличается) от 1 байта.

Я так понимаю, 10К (или там 1 млн) циклов перезаписи, означает что ячейку можно переписать столько-то раз, а потом видимо будет резко повышаться вероятность ошибки. А по вашему получается, что надежность записи 1 байта в SSD - 1/10000? Сильно сомневаюсь, ведь это означает что на каждый мегабайт будут сотни ошибок, если бы это было так то ни одна программа бы не загрузилась с SSD.

А если раз в неделю перезаписывается 10-12 ГБ?

В общем, если я правильно понял принцип действия SSD, то там есть «виртуальные» адреса блоков (секторов или кластеров, хз), т.е. это то что видит «извне» контроллер SATA. И есть «физические» адреса тех же блоков - физические номера этих блоков. Их извне никак не видно, это «вещь в себе». Есть соответственно таблица для преобразования физических адресов в виртуальные и обратно. (Похоже на трансляцию физических и виртуальных адресов памяти). Так вот. Пусть изначально физические и виртуальные адреса совпадают. Пусть пользователь хранит на SSD один-единственный файл, и постоянно его переписывает. Контроллер будет постепенно увеличивать счетчики записи соттв. блоков, и когда счетчики будут подбираться к критической отметке - в таблице трансляции адресов он просто поменяет местами элементы так, что часто используемый физический блок станет редко используемым, а данные будут записываться в «свежий». (Ну и сами эти блоки надо местами поменять). «Снаружи» пользователь это никак не заметит, с его точки зрения ничего не изменится. Поэтому блоки «изнашиваются» более-менее равномерно, так что даже если винт на 3/4 забит файлами которые лежат и никогда не меняются, а 1/4 переписывается по десять раз на дню, все равно равномерно изнашивается весь винт. Теперь понятно откуда такая формула? число циклов умножаем на объем винта - вот это и будет объемом данных, которые надо записать до полной смерти винта. Это - петабайты. Делим на скорость записи, получаем время жизни.

> уже пофикшено
Status: REOPENED

Да и сам лично никаких улучшений не замечал, как тормозило все, когда кторрент проверяет файл, так и тормозит до сих пор.

> приходиться работать в каком-то античном говне
Я так понимаю что это определение в первую очередь касается самого ноутбука?

Поэтому блоки «изнашиваются» более-менее равномерно, так что даже если винт на 3/4 забит файлами которые лежат и никогда не меняются, а 1/4 переписывается по десять раз на дню, все равно равномерно изнашивается весь винт.

Весьма сомнительное утверждение...

>>Каким образом? Дать мобильные телефоны знакомых системных администраторов, которые меняли/сдавали их по гарантии??? Вы же не школьнег чтобы «чушь про Пруф» спрашивать?! Насколько я понял. Или же ошибся?

Я думаю, если бы такие проблемы были, причем в массовом порядке, как вы говорите, то это неизбежно всплыло бы на форумах, блогах и т.д. Я такого не слышал, потому и спрашиваю.

Для того, чтобы был «массовый» шум, надо: 1. Массовая закупка, всё-таки цена еще кусается для рядового потребителя, а ставить 16GB не все целесообразно. 2. Исходя из п.1 должна быть и статистика, а сравнительно доступные SSD пошли не так давно - < 3 лет. 3. Еще плюс один важный психологический эффект - мало, очень мало людей признают, что купили «гавно» да еще и за большие деньги. Вот вам третья причина.

А почему Вас так удивляет просьба подтвердить свои слова ссылкой? По моему, вполне нормально относится к подобной информации со здоровым скептицизмом, или вы предлагаете любому анонимусу с ЛОРа верить на слово? :)

Смотря какой вопрос имеется ввиду конкретно. Порой такие вещи про «пруфлинк» элементарно раздражают. Вы же не будете просить пруфлинк того, что «чиновник хх-ранга Пуританов М.М. при очередной госзакупке убздел 25% от оборота»? :) Он что, сам себе враг чтоли?

По моему, вполне нормально относится к подобной информации со здоровым скептицизмом, или вы предлагаете любому анонимусу с ЛОРа верить на слово? :)

Это не только нормально, но и очень правильно, со скептицизмом относиться к какой-либо информации, но и не только на ЛОРе, а, так сказать,... :) Но есть много информации, пруфлинк по которой искать в тырнете, по крайней мере, глупо. В конце концов, есть просто практика определённых людей. Есть и статистика. Касаемо SSD можете уточнить в сервис-центрах, как вариант. Только весь вопрос в том, «КАК СПРОСИТЬ». Если уж припрёт. :)

Я так понимаю, 10К (или там 1 млн) циклов перезаписи, означает что ячейку можно переписать столько-то раз, а потом видимо будет резко повышаться вероятность ошибки.

Да, так оно и есть.

А по вашему получается, что надежность записи 1 байта в SSD - 1/10000?

Байт мы взяли условно, из той «глупой формулы» как удельную единицу, когда умножали надежность 1-й ячейки на 64ГБ. В этом «разводка» и заключается, так как размер ячейки врядли 1 байт. Скорее всего, производитель имеет ввиду 100000 циклов (или 1-5 млн. циклов) на устройство в целом, т.е. каждая (любая из рассматриваемых) ячейка устройства гарантированно выдержит минимум 1-5 млн. циклов перезаписи. Т.е. это и есть надежность всего устройства (1-5 млн. циклов) в целом. Причём здесь размер? Да, если записывать (хранить) только 1 байт уникальной информации (условно считаем, что это физический размер ячейки) на SSD размером в 64 ГигаБайт, тогда да, действительно контроллер будет сначала записывать этот 1 байт в ячейку №1, затем этот другой (изменённый) 1 байт в соседнюю ячейку №2 и в таком же духе. Тогда формула верна. Но, простите, КТО ХРАНИТ 1 БАЙТ????? Это ж - бред! А так да, формула красивая и цифры впечатляющие, >50 лет, ах, ах! ;)

>В общем, если я правильно понял принцип действия SSD, то там есть «виртуальные» адреса блоков (секторов или кластеров, хз), т.е. это то что видит «извне» контроллер SATA. И есть «физические» адреса тех же блоков - физические номера этих блоков. Их извне никак не видно, это «вещь в себе». Есть соответственно таблица для преобразования физических адресов в виртуальные и обратно. (Похоже на трансляцию физических и виртуальных адресов памяти).

Да, именно этим контроллер и занимается, в том числе.

Так вот. Пусть изначально физические и виртуальные адреса совпадают. Пусть пользователь хранит на SSD один-единственный файл, и постоянно его переписывает.

Вот об этом и речь. Нет такого в реальных условиях, чтобы был единственный файл перезаписываемый файл. Но даже если 1 файл, то, опять таки, каких размеров? Файл размером 2КБ, 10КБ или 8,4ГБ (не смейтесь, обычный .mkv на 1080p)? Или SSD используется как /Windows/temp при подготовке видео проектов (25ГБ - легко!). Про своп же я вообще молчу. Тут не всё так очевидно.

Контроллер будет постепенно увеличивать счетчики записи соттв. блоков, и когда счетчики будут подбираться к критической отметке - в таблице трансляции адресов он просто поменяет местами элементы так, что часто используемый физический блок станет редко используемым, а данные будут записываться в «свежий». (Ну и сами эти блоки надо местами поменять). «Снаружи» пользователь это никак не заметит, с его точки зрения ничего не изменится.

Да, если испорченный блок - небольшого размера.

Поэтому блоки «изнашиваются» более-менее равномерно, так что даже если винт на 3/4 забит файлами которые лежат и никогда не меняются, а 1/4 переписывается по десять раз на дню, все равно равномерно изнашивается весь винт.

Вот здесь по точнее, пожалуйста, с моей Т.З. 1/4 винта (SSD) будет запорота (стремиться «к нулю»), остальные же данные и 3/4 на винта (и место под ними) будет конечно намного дольше рабочими (опять зависит от циклов перезаписи).

Теперь понятно откуда такая формула? число циклов умножаем на объем винта - вот это и будет объемом данных, которые надо записать до полной смерти винта. Это - петабайты. Делим на скорость записи, получаем время жизни.

Нет, не понятно. Исходя из того, что данные - разные (уникальные) да и разного объема хранения (> 1 условного байт) вот и не ясно!

Вот вы, на самом деле, очень хороший вопрос подняли!!!

А почему Вас так удивляет просьба подтвердить свои слова ссылкой? По моему, вполне нормально относится к подобной информации со здоровым скептицизмом, или вы предлагаете любому анонимусу с ЛОРа верить на слово? :)

Смотря какой вопрос имеется ввиду конкретно. Порой такие вещи про «пруфлинк» элементарно раздражают. Вы же не будете просить пруфлинк того, что «чиновник хх-ранга Пуританов М.М. при очередной госзакупке убздел 25% от оборота»? :) Он что, сам себе враг чтоли?

В действительности, как это ни прискорбно, история на самом деле развивается по спирали. Для старшего поколения радио-телевидение СССР было всегда достоверным источником непреложной информации, для молодежи сейчас почему-то такой источник информации, как интернет рассматривается как 100% гарантия точности (правдивости и т.п.). Те же, простите, помидоры, вид сбоку. Всё повторяется, а люди так и не хотят учиться на чужих ошибках, повторяя одну и ту же глупость из века в век.

Тырнет что, сам по себе что-ли наполняется? Теже люди с «теми же намерениями». Чем отличается от газеты или желтого журнала?

Это к вопросу «размышления на тему пруфлинков»

Не угадал.

приходиться работать в каком-то античном говне

Я так понимаю что это определение в первую очередь касается самого ноутбука?

Не угадал. Ноутбук-то новый :-р

На 2.4 уже можно переходить?

>Для старшего поколения радио-телевидение СССР было всегда достоверным источником непреложной информации,

Ой, да ладно. Уж не знаю про какое вы «старшего поколения», судя по рассказам родителей (50 и 55 г.р.) никто ни на грош не верил официальным новостям (газетам, ТВ), зато вовсю верили слухам и сарафанному радио (хотя в этих слухах бреда и туфты было ничуть ли не меньше, если не больше, чем в официальной информации).

для молодежи сейчас почему-то такой источник информации, как интернет рассматривается как 100% гарантия точности (правдивости и т.п.).

Дело не в этом. Разумеется, если в бложике Васи Пупкина или на сайте желтой газетки напишут что то, это не значит что надо сразу верить. Но тут ситуация другая. В инете прикрыть сайт с «неудобной» инфой на много порядков сложнее, чем газету прикрыть. Поэтому, если некоей инфы нет ВООБЩЕ, то это повод задуматься, «а был ли мальчик». Именно поэтому отсутствие пруфлинков настраживает.

Вот об этом и речь. Нет такого в реальных условиях, чтобы был единственный файл перезаписываемый файл. Но даже если 1 файл, то, опять таки, каких размеров? Файл размером 2КБ, 10КБ или 8,4ГБ (не смейтесь, обычный .mkv на 1080p)? Или SSD используется как /Windows/temp при подготовке видео проектов (25ГБ - легко!). Про своп же я вообще молчу. Тут не всё так очевидно.

Это без разницы сколько файлов, принцип один. Один файл я привел просто для примера.

Тут есть правда одна тонкость, которую я не упомянул. Даже если размер файла 1 байт. то при изменении надо скорректировать метаданные, а тут в зависимости от FS может быть немало данных. К тому же, запись 1 байта все равно требует записи целого блока.

Контроллер будет постепенно увеличивать счетчики записи соттв. блоков, и когда счетчики будут подбираться к критической отметке - в таблице трансляции адресов он просто поменяет местами элементы так, что часто используемый физический блок станет редко используемым, а данные будут записываться в «свежий». (Ну и сами эти блоки надо местами поменять). «Снаружи» пользователь это никак не заметит, с его точки зрения ничего не изменится.

Да, если испорченный блок - небольшого размера.

ПОхоже, вы все таки принцип не поняли. Блоки все одинаковые.

Вот здесь по точнее, пожалуйста, с моей Т.З. 1/4 винта (SSD) будет запорота (стремиться «к нулю»), остальные же данные и 3/4 на винта (и место под ними) будет конечно намного дольше рабочими (опять зависит от циклов перезаписи).

Тут уже особенности алгоритма. Думаю, контроллер не будет ждать пока некоторые блоки полностью запорятся. Он видит, например, что на одном - 1000 перезаписей, а на другом 2. И меняет их местами, заодно скорректировав таблицу трансляции адресов.

на современный дистр никак не воткнуть? типа убунты 10.04

Именно что второе.

на современный дистр никак не воткнуть? типа убунты 10.04

На современных дистрах - glibc, тебующая ядро >= 2.6.12

>2.4 пробовал - подтормаживало ... в кедах (%

Кросафчег! У мну самопильный musiicbox+файлопомойка на таком крутяццо.

Тут уже особенности алгоритма. Думаю, контроллер не будет ждать пока некоторые блоки полностью запорятся. Он видит, например, что на одном - 1000 перезаписей, а на другом 2. И меняет их местами, заодно скорректировав таблицу трансляции адресов.

А куда денется ранее записанная в блок «2» информация?

>А куда денется ранее записанная в блок «2» информация?

Блоки поменяются местами.

Поясняю еще раз на пальцах

Есть таблица трансляции адресов из виртуальных в физические.

Контроллер винта посылает команду записи в блок с адресом X

Контроллер SSD смотрит в таблицу: A[X] = Y, и пишет в физический блок Y. При этом инкрементирует элемент другой таблицы, N[Y]++ (таблица содержит информацию о том сколоько раз в n-й блок была произведена запись)

Через энное число операций контроллер смотрит и видит, что N[10] == 1000 (в десятый блок писали 1000 раз), а N[5] == 2 (в пятый блок писали всего 2 раза). Он меняет местами блок 5 и 10, и корректирует таблицу трансляции адресов, что бы пользователь ничего не заметил: если раньше было допустим A[5] == 5 и A[10] == 10. Теперь будет A[5] == 10 и A[10] == 5. Пользователь продолжает работать со своим файлом, перезаписывает его, но физически файл лежит уже в другом месте диска, свежем.

Хорошо, а куда тогда денутся данные из блока, который уже был 1000 раз перезаписан?

Что значит «куда денутся»? Ничто никуда не денется, данные из блока который переписан 1000 раз запишутся в блок который записан 2 раза, а из того который 2 раза - в тот который 1000 раз.

Что значит «куда денутся»? Ничто никуда не денется, данные из блока который переписан 1000 раз запишутся в блок который записан 2 раза, а из того который 2 раза - в тот который 1000 раз.

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

Да, если испорченный блок - небольшого размера.

ПОхоже, вы все таки принцип не поняли. Блоки все одинаковые.

Да, или говорим о разных вещах. Попробую на примере «тапок»:

Для начала, отойдём от мнимых «петабайтов» и перейдём к реальной практике:

Для простоты рассмотрения приравняем 1 ячейку (у которой надёжность 1-5 млн. циклов) = 1 колесу (покрышке). Автор «формулы» рассматривает ситуацию (при SSD 64GB), когда «машина» ездеет на 1-м колесе (!), а в запасе лежат еще 63 (миллиарды убрал для наглядности).

Но, на практике, «машина» ездеет как минимум на 1/4 или 16 «колёсах» и, за счет остальных 48, возможно продление срока службы всего комплекта (64) колёс. Как минимум 16 (т.е. 1/4 SSD), а то и больше.

Более того, в реалиях адекватный водитель (который разумно относится к своей жизни и жизни окружающих) при полном повреждении 1-й покрышки меняет целиком весь комплект из 4-х шт.

Нечто подобное происходит и со структурой полупроводников -> если идёт деградация, то она не «точечная», а в «объёме», т.е. «страдают» и соседние структуры (читай «ячейки»).

Вот тут некоторые, не буду показывать пальцем, визжали про > 50 лет, ссылаясь на (!!!) википедию и «статью с чудесной формулой», не понимая полупроводников, их производства и их эксплуатации «ПО СУТИ».

Возвращаясь на землю грешную, напомните, пожалуйста, физическую конструкцию (как это выглядит в жизни на кремние) этой ячейки? Это важно для дальнейшего понимания «надежности».

Где можно купить такое интересное устройство? =)

Буэ.

Где можно купить такое интересное устройство? =)

В России уже нигде, только в Китае.

>А теперь посчитайте сколько у вас всего получится в итоге операций чтения-записи, к какому падению скорости это приведет и к какому фактическому увеличению износа накопителя...

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

к какому падению скорости это приведет

именно по этой причине скорость записи SSD меньше раза в полтора-два, чем скорость чтения.

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

И каким образом в этом случае «блоки „изнашиваются“ более-менее равномерно, так что даже если винт на 3/4 забит файлами которые лежат и никогда не меняются, а 1/4 переписывается по десять раз на дню, все равно равномерно изнашивается весь винт»?

Данный алгоритм в лучшем случае лишь обеспечивает «дожитие» всех блоков до определенного «возраста» - за счёт более ускоренного износа. Не самая разумная идея, на мой взгляд...

именно по этой причине скорость записи SSD меньше раза в полтора-два, чем скорость чтения.

Скорость записи меньше, потому что после записи еще дополнительно осуществляется чтение записанных данных и вычисление контрольных сумм...

>Для простоты рассмотрения приравняем 1 ячейку (у которой надёжность 1-5 млн. циклов) = 1 колесу (покрышке). Автор «формулы» рассматривает ситуацию (при SSD 64GB), когда «машина» ездеет на 1-м колесе (!), а в запасе лежат еще 63 (миллиарды убрал для наглядности). Но, на практике, «машина» ездеет как минимум на 1/4 или 16 «колёсах» и, за счет остальных 48, возможно продление срока службы всего комплекта (64) колёс. Как минимум 16 (т.е. 1/4 SSD), а то и больше.

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

>Меняя время от времени местами изношенные покрышки с новыми, можно добиться равномерного изнашивания.

Да, но колёса-то все в работе, вот я о чём.

>И каким образом в этом случае «блоки „изнашиваются“ более-менее равномерно, так что даже если винт на 3/4 забит файлами которые лежат и никогда не меняются, а 1/4 переписывается по десять раз на дню, все равно равномерно изнашивается весь винт»?

100 дней эти 12 гигабайт записываются по 10 раз на дню (итого 1000 перезаписей), потом меняются местами с данными которые лежат не переписываясь годами, и начинают «запарывать» уже другой участок диска, потом третий и т.д.

Данный алгоритм в лучшем случае лишь обеспечивает «дожитие» всех блоков до определенного «возраста» - за счёт более ускоренного износа.

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

100 дней эти 12 гигабайт записываются по 10 раз на дню (итого 1000 перезаписей), потом меняются местами с данными которые лежат не переписываясь годами, и начинают «запарывать» уже другой участок диска, потом третий и т.д.

Это не равномерное изнашивание, при равномерном все блоки имеют примерно одинаковый «возраст». Наиболее оптимальный алгоритм в этом случае - это запись изменяемых данных в свободное место с меньшим числом циклов перезаписи. Предполагаю, что подобный алгоритм в той или иной форме и реализован на практике...

>Это не равномерное изнашивание, при равномерном все блоки имеют примерно одинаковый «возраст»

Ну естественно не идеально равномерное, но при данном алгоритме «возраст» отдельных блоков будет отличаться не более чем на 1000 (тонкости алгоритма мне не известны, может там не 1000, может 100 - но это уже мелочи). Если все блоки будут иметь «возраст» в пределах от 3000 до 4000 перезаписей - это можно назвать относительно равномерным. Во всяком случае это намного лучше чем 30% блоков будут иметь «возраст» 10000 (т.е. полностью изношены), а остальные от 0 до 1000.

Ну естественно не идеально равномерное, но при данном алгоритме «возраст» отдельных блоков будет отличаться не более чем на 1000 (тонкости алгоритма мне не известны, может там не 1000, может 100 - но это уже мелочи).

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

Во всяком случае это намного лучше чем 30% блоков будут иметь «возраст» 10000 (т.е. полностью изношены), а остальные от 0 до 1000.

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

>Чем больше будет таких «ступенек» до критических цифр перезаписи, тем сильнее будет изнашиваться накопитель в целом.

Это понятно, поэтому ступенек должно быть не слишком много.

Если довести эту идею до своего логического завершения,

Скорее, до абсурда.

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

Сомневаюсь. Если идею не доводить до абсурда (т.е. выравнивать при каждой перезаписи) то перемещений будет не очень много.

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

ТУт ситуация аналогичная: компромисс между «идеальностью» равномерности изнашивания, и накладными расходами.

но ведь разработчик дели утверждает что работает на 62 метрах нормально (сам проверял - работает), а альт на 64 не хочет

Сомневаюсь. Если идею не доводить до абсурда (т.е. выравнивать при каждой перезаписи) то перемещений будет не очень много.

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

Неправильно новость назвали

Надо было так: «[b]Линус положил на 2.4[/b]». Или так: «[b]Линус положил на 2.34 большой и толстый. Если длины хватит, то обещает положить ещё и на лысину Балмера[/b]».

Неправильно новость назвали

Надо было так: «Линус положил на 2.4». Или так: «Линус положил на 2.34 большой и толстый. Если длины хватит, то обещает положить ещё и на лысину Балмера».

>2.4 пробовал - подтормаживало ... в кедах (%

Интересно. По моим ощущениям 2.4 было быстрее 2.2. Но на однопроцессорных машинках самый быстрый вариант всё равно 2.0.

А 2.6 на нём не собирается, или нестабильно?

Кросс- же.

А 2.6 на нём не собирается, или нестабильно?

Собирать на нём ничего не надо, есть же кросс-компиляция. Тем более готовые ядра можно скачать в интернетах. Другое дело, что linux-2.6 на этой машинке работает нестабильно. Хны-хны.

>Собирать на нём ничего не надо, есть же кросс-компиляция.

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

Тем более готовые ядра можно скачать в интернетах. Другое дело, что linux-2.6 на этой машинке работает нестабильно. Хны-хны.

Багрепорты майнтейнеру слали? Или он забил уже?

Все забили.

Багрепорты майнтейнеру слали? Или он забил уже?

Все уже забили.