Отправляет email-рассылки с помощью сервиса Sendsay

Обсуждения и споры о свободных системах и всём сопутствующем

Подписаться Бесплатный дискуссионный лист Подписчиков 539
←   Июнь 2004   →
 1
 2
 3
 4
 5
05.06.2004
16:23:58
18:06:45
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
23.06.2004
00:16:38
00:17:06
24
24.06.2004
20:55:38
23:32:14
25
26
27
28
29
30


За последние 60 дней ни разу не выходила


Сайт листа: http://www.linuxrsp.ru
Открыт: 22-10-2003
Пре-модерация: Нет
Адрес для писем в лист: comp.soft.linux.debate-list@subscribe.ru
Адрес модератора: comp.soft.linux.debate-owner@subscribe.ru

Модератор
Фёдор Сорекс

Статистика

539 подписчиков
0 за неделю

Re: Фрагментация

Привет всем!
Хочу поделиться тезисами, которые должны снять вопрос с повестки дня...
Заранее пардон за тривиальные суждения и тавтологии.

1. АКСИОМА - фрагментация файлов, как явление, существует в любых
файловых системах, поддерживающих хранение файла в нескольких несмежных
непрерывных участках. Другими словами, если для размещения файла длиной N
логических блоков НЕ ТРЕБУЕТСЯ наличия N идущих подряд свободных логических
блоков.

2. Фрагментация в широком смысле есть не вредное_явление, как думают
многие, а качественное_свойство файловой системы.

3. ОСНОВНЫЕ ЗАДЕРЖКИ на уровне файловой системы происходят не при
чтении-записи данных, а при открытии-закрытии файлов! Потому, куда выгодней
дефрагментировать не область хранения данных, а системную область, где
хранятся сами внутренние структуры ФС. Под FAT16/32 это давало очень
заметный прирост в скорости поиска-открытия файлов. Под NTFS5 тоже дает,
хотя почему-то этот эффект меньше. На Униксовых файловых системах несколько
иная структура хранения системной информации, позволяющая выполнять поиск
"заголовка" файла гораздо быстрее, чем в ФАТ и НТФС.

4. Я совсем не уверен, что замеры производительности на реальных
задачах дадут "экономически" заметное различие для фрагментированных и
нефрагментированных экземпляров файловых систем. По моим наблюдениям, в
реальной работе файл-сервера пользователи больше ждут не 'Gatheringa'
раскиданных по диску кластеров (кэширование-то работает!), а снятия
блокировок другого пользователя. Особенно в отстое типа одинЦ или
фокспро-совместимых домочадах.
По крайней мере, при типичной офисной загрузке моих серверов (под Win2000AS
и ASP Linux Vostok + SAMBA 2.2.8) визуальные задержки и средняя длина
очередей запросов к диску после дефрагментации никак не меняется...

5. При работе с большим количеством примерно одинаковых небольших
файлов, занимающих небольшое количество кластеров (а имеено это происходит в
реальной офисной работе!), вероятность фрагментации вообще невелика. -
просто новый файл займет место какого-нибудь недавно стертого. Многие
менеджеры ФС (NTFS5, например, EXT3 по-моему тоже) при создании небольшого
файла выделяют сразу непрерывную область, размер которой вычисляется по
некоей формуле, вроде MAX(Lsysmin; Lreqested*K)
Конечно, в идеальном случае в таблице размещения файлов у каждого кластера
должен быть особый атрибут - "зарезервирован под рост файла". Смутно
помнится, где-то я даже видел что-то подобное...

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

7. При работе на сервере какой нибудь СУБД (типа Oracle или MS SQL
Server) файлы создаются специальной утилитой, которая при запросе к ОС на
создание файла сразу просит много, и ОС ищет непрерывный кусок. А лучше для
этого использовать неразмеченный раздел... Многие так и делают.

8. Стратегий размещеняи файлов в свободных местах много. Эта тема
потянет на диссертацию...

9. Насчет дефрагментации данных - лично я, вместо консолидации файлов в
начале диска делал бы с точностью до наоборот - рассредотачивал данные по
различным областям диска (например: длинные - в конец, средние - в начало,
короткие -в середину) , перемежая между собой занятые и свободные фрагменты
примерно одинаковой длины. Подумайте, и поймете "зачем". Насколько я понял
идеологию ReiserFS, её авторы отталкивались от сходных постулатов, хотя
пошли по другому пути.

10. Единственная серьёзная проблема, которая может "вылезти" на сильно
фрагментированном томе - это крайне сложное восстановление данных после сбоя
диска (при потере системных областей). Но - во-первых, это и так форс-мажор,
во-вторых, бэкапы надо делать, а в третьих, в журналируемых системах
хранения типа той же НТФС "глубокие" отказы ФС маловероятны. У меня за много
лет эксплуатации была только одна совсем печальная история - когда сделали
суперсверхдешевый сервер под Вынь2000, и ИДЕ Квантум 20ГБ от натуги просто
запилил середину диска (а там у НТФС как раз находится логическое начало
тома - мастер-запись, таблица размещения файлов и пр... ) Кстати, он в
"полуотказе" проработал месяца два, как потом выяснилось по остаткам
системных логов... Часть данных вытащил с помощью ZARtool, но большую часть
похоронил - большая часть MFT и файлов-директориев не читалась физически (на
спец. стенде). Вот так вот. Не экономьте на ХаДэДэ!

На моей памяти, систем, НЕ ПОДДЕРЖИВАЮЩИХ фрагментацию, было мало:
- CP/M, CP/M-86;
- RT-11,FODOS,RAFOS и им подобные для PDP-11 (про ОС РВ для СМ-4/1420 не
скажу - не помню...); RSX-11 - уже с фрагментацией
- большинство т.н. Rommable-FS и Flashable-FS, применяющихся во встроенных
контроллерах, где совсем нет места для сложного программного кода;
- совсем старые операционки, про которые все забыли...
Вот на них как раз и приходилось периодически-обязательно запускать всякие
там Squeeze и т.п. утилитки, иначе был велик риск того, что следующий файл
размером больше 1 блока просто не запишется.

Вкратце, все.
Извините, если не в тему.

Бест регардс, Игорь Гаврилюк





-*Название листа "Обсуждения и споры о свободных системах и всём сопутствующем"
Написать в лист: comp.soft.linux.debate-list@subscribe.ru
Архив Листа - http://subscribe.ru/archive/comp.soft.linux.debate Поиск: http://www.google.com
Адрес правил листа http://subscribe.ru/catalog/comp.soft.linux.debate/rules
Номер письма: 1307; Возраст листа: 240; Участников: 583
Адрес сайта рассылки: http://www.linuxrsp.ru
Адрес этого письма в архиве: http://subscribe.ru/archive/comp.soft.linux.debate/msg/173513


-*Информационный канал Subscribe.Ru
Написать в лист: mailto:comp.soft.linux.debate-list@subscribe.ru
Отписать : mailto:comp.soft.linux.debate--unsub@subscribe.ru

http://subscribe.ru/ mailto:ask@subscribe.ru

Ответить  
"Igor Gavriluk"
Sat, 19 Jun 2004 01:53:11 +0300 (#173513)

 

Ответы:

Igor Gavriluk пишет:

Именно при чтении-записи данных и происходит основная задержка,
связанная с фрагментацией. Причина в том, что скорость перемещения
головки диска на несколько порядков ниже скорости чтения-записи
информации. Допустим, время перемещения головки с начального до
конечного цилиндра 30мс (что приблизительно соответствует реальности).
Если соседние данные будут разбросаны на крайние цилиндры, то при
размере кластера 4Кб за одну секунду будет прочитано всего 133Кб, в то
время, как диск способен передавать 100Мб в секунду (разница почти на
три порядка). Обычно такой дикой фрагментации не бывает, но все равно
замедление на один порядок очень даже возможно.

ОС РВ - это советский клон RSX-11. Кстати, фрагментация там
поддерживалась для файлов данных, программы должны были занимать
непрерывную область. И хотя это определялось исключительно спецификой
ядра (программа загружалась в память без участия файловой системы, в
ядре запоминался адрес начального сектора программы на диске и ее
размер), это приводило к быстрой загрузке программ, что я считаю правильным.



-*Название листа "Обсуждения и споры о свободных системах и всём сопутствующем"
Написать в лист: comp.soft.linux.debate-list@subscribe.ru
Архив Листа - http://subscribe.ru/archive/comp.soft.linux.debate Поиск: http://www.google.com
Адрес правил листа http://subscribe.ru/catalog/comp.soft.linux.debate/rules
Номер письма: 1309; Возраст листа: 240; Участников: 583
Адрес сайта рассылки: http://www.linuxrsp.ru
Адрес этого письма в архиве: http://subscribe.ru/archive/comp.soft.linux.debate/msg/173549


-*Информационный канал Subscribe.Ru
Написать в лист: mailto:comp.soft.linux.debate-list@subscribe.ru
Отписать : mailto:comp.soft.linux.debate--unsub@subscribe.ru

http://subscribe.ru/ mailto:ask@subscribe.ru

Ответить   "Yuri N. Glibovetz" Sat, 19 Jun 2004 18:21:52 +0300 (#173549)

 

Yuri N. Glibovetz [mailto:gyn***@m*****.ru] пишет:

Не совсем так. Более-менее "правильный" планировщик создаст в очереди команд
к диску две группы - на чтение в начале диска, и на чтение в конце диска. И
выполнит их последовательно, т.е. глобальных перемещений будет всего 3-5
(учитывая другие запросы к диску). К тому же время позиционирования
начало-конец на самом деле ненамного больше времени трэк-трэк (гораздо
меньше порядка)). Основное время занимает точная доводка и стабилизация
головок. Да и передать 100мб за секунду на сегодняшний день не способен
никто 8-)) - самый гнилой винт дает 2-3 ГБ/с уже "для приложений", т.е.
после всех "надстроек" файловой системы. А если имелось в виду
100_Гига_б/с... У меня NTFS5 на "Cheetah X15 36LP" (это при 15Krpm и
uwSCSI-320!) усредненно давала порядка 65ГБ/с в лучшие годы... Процы стояли
неслабые - Ксеоны однако.

Задержка первых данных ("сырых" секторов) при выполнении команды
позиционивания-чтения при сброшенных дисковых кэшах находится в порядках
"срденее время позиционирования"+"2-4 оборота диска"+"50~500мкс на системные
нужды" т.е. для ИДЕ дисков 7200об/мин это порядка 9-12мс, для uwSCSI дисков
на 10000об/мин это уже 3-5мс.

Как таковая, фрагментация файлов данных начинает играть заметную роль в
_быстродействии_приложения_ только в несколькох случаях:

1) приложение "медленное", и сервер успевает вытеснить данные из системного
кэша (имеются в виду _служебные_данные о файле - таблицы размещения и т.п.)
При перепрочтении ещё и служебной информации уж точно будет больше
позиционирования. Насколько я помню, и в NTFS, и в большинстве Униксовых ФС
служебная информация разбросана по диску, а в самых "умных" её размещение
начинается не с начала раздела диска, как многие думают, а с середины -
среднее расстояние позиционирования до данных от центра раздела в два раза
меньше, чем от края (можно и вперёд лететь, и назад)...

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

3) Близкий к 2) вариант - маленький размер самого кэша. По моим прикидкам,
дисковый кэш в RAM должен позволять вмещать всю служебную информацию со всех
смонтированных томов плюс 25-50% (хотя бы) от объёма часто запрашиваемых
данных. Это минимизирует "неудобные" запросы позиционирования-чтения. Запись
в служебные области все равно останется, но если разрешена отложенная
запись, это почти незаметно. Такие требования при современном "гигантизме"
дисков иногда непросто выполнить - служебная область на заполненном 120ГБ
томе может составлять 3-4гб, а если на нем очень много мелких файлов (при
хостинге веб сайтов, например) то ещё больше. Тут NTFS резко проигрывает
EXTам и UFSам, поскольку в НТ с каждым файлом хранится (и каждый раз
обрабатывается ситемой) не очень маленький Access Control List, который в
Униксах занимает всего пару DWORD. Сама идея ACL и NTFS Security очень
сильная, но в большинстве практических применений избыточная.

4) на сервере только один диск - и на систему, и на данные, и у него
отключена отложенная запись. Типично для "маленьких" серверов под
Вынь2000АС-контроллером домена. Эта "роль"(PDC) принудительно отключает
отложенную запись. Система создаёт _заметный_ поток на запись (логи и пр.),
да и сама запись осуществляется несколько медленнее, и позиционирование для
записи "вклинивается" в поток команд к диску самым бесцеремонным образом...

-= лёгкий оффтопик =-
Со скоростью работы дисков связано несколько разных факторов -
-- средняя задержка позинионирования - вычисляется именно "усреднением",
т.е. зависит от задач, выполняющихся его контроллером. У SCSI дисков,
поддерживающих очередь команд (а они все её поддерживают) контроллер может
лучше планировать перемещения головок. Вкупе с другими фишками средняя
скорость поиска на хороших uwSCSI дисках достигает 3.5-4мс(!).
-- задержка "track-to-track". При чтении очень больших объёмов данных
"подряд" создает паузы в потоке данных, вызванные "шаганием" тонарма с
головками. У хороших SCSI-дисков составляет 0.2-0.3мс(!). Ближе к центру
диска она чуть меньше, поскольку стабилизация головок проходит легче при
меньшей скорости обдува пограничным слоем воздуха.
-- средняя задержка поиска сектора, вызванная конечной скоростью вращения
дисков. Идеально было бы сразу после стабилизации головок на цилиндре
считать за один оборот все содержимое цилиндра, и потом разбираться с ним.
High-End диски, похоже, примерно так и делают - кэш 8мб примерно
соответствует объёму нескольких дорожек (например, Seagate Cheetah X15 36LP
имеет 18497 цилиндров - в среднем по 2мб на дорожку). Читают ли они только
одну поверхность, или весь цилиндр - не знаю, не изучал. По-моему, памяти
все-таки маловато для всего цилиндра, да и предыдущие данные надо отдавать в
шину постепенно.
-- Задержки передачи данных. Целиком и полностью зависят от возможностей
интерфейсов, загрузки контроллера и самой системы и пр.
-- "скрытые" технологические моменты:
- рекалибровка термическая - механические свойства системы меняются
при нагреве;
- рекалибровка вибрационная (есть такая на быстрых дорогих дисках)
для устранения резонансной вибрации в многодисковых шасси;
кстати, из этих же соображений реальная скорость вращения у
каждого диска чуть-чуть "своя"
- снижение активности с целью охлаждения микросхем (тоже видел такое
в одном Design Note на микроконтроллер от Fujitsu)
- искусственное "выравнивание" потока данных на т.н AV (Audio-Video)
дисках, предназначенных для потоковой записи-чтения (видеомонтаж etc.), при
котором даже в "удачных" последовательностях команд все равно имитируется
некоторая задержка позиционирования.

__ПОЛЕЗНОЕ:
Поскольку внешние треки позволяют записывать в 2-2.5 раза больше данных при
той же линейной (физической) плотности записи, современные диски используют
технологию зонной записи (кажется, так она называется), размечая внешние
треки на бОльшее количество секторов.
Это дает интересный эффект (проверен на практике): для интенсивной
файлогонятельной загрузки есть смысл создать отдельный раздел на внешнем
крае диска. Я генерил RAID 0+1 (stripped-marrored volume) на двух парах
небольших винтов (старенкие читы 9ГБ 10000об/мин) специально для хранения
данных 1С, для самодельного фокспрошного приложения, даже для кеширующих
прокси (SQUID, MS ISA Server) - результат очень заметный даже визуально!
И последствия фрагментации в таком случае минимизируются при прочих равных
условиях - количество перемещений головок в 2 раза меньше.
...Кстати, на IDE дисках почему-то иногда наблюдалось обратное (например, на
Fujitsu 20GB 7200rpm).

Спасибо за долготерпение при прочтении данного опуса.

Всех благ, Игорь Гаврилюк


-*Название листа "Обсуждения и споры о свободных системах и всём сопутствующем"
Написать в лист: comp.soft.linux.debate-list@subscribe.ru
Архив Листа - http://subscribe.ru/archive/comp.soft.linux.debate Поиск: http://www.google.com
Адрес правил листа http://subscribe.ru/catalog/comp.soft.linux.debate/rules
Номер письма: 1310; Возраст листа: 241; Участников: 583
Адрес сайта рассылки: http://www.linuxrsp.ru
Адрес этого письма в архиве: http://subscribe.ru/archive/comp.soft.linux.debate/msg/173863


-*Информационный канал Subscribe.Ru
Написать в лист: mailto:comp.soft.linux.debate-list@subscribe.ru
Отписать : mailto:comp.soft.linux.debate--unsub@subscribe.ru

http://subscribe.ru/ mailto:ask@subscribe.ru

Ответить  
"Igor Gavriluk"
Sun, 20 Jun 2004 00:41:00 +0300 (#173863)

 

i686-pc-linux-gnu)

Доброго времени суток.

On Sun, 20 Jun 2004 00:41:00 +0300
"Igor Gavriluk" <gavrik2***@m*****.ru> wrote:

???

Да будет вам известно, что число 320 в названии интерфейса означает ни что иное,
как максимальная скорость передачи данных в мегабайтах в секунду. Т.е. с такой
предельной скоростью передаются данные из кэша винта в память. Чтение происходит
ЗНАЧИТЕЛЬНО медленнее.

Дальше письмо читать не стал.

Ответить   iam Sun, 20 Jun 2004 13:00:18 +0300 (#173922)

 

Да опечатка там... Чего вы... 65 Мегабайт, конечно, в секунду...


-*Название листа "Обсуждения и споры о свободных системах и всём сопутствующем"
Написать в лист: comp.soft.linux.debate-list@subscribe.ru
Архив Листа - http://subscribe.ru/archive/comp.soft.linux.debate Поиск: http://www.google.com
Адрес правил листа http://subscribe.ru/catalog/comp.soft.linux.debate/rules
Номер письма: 1314; Возраст листа: 241; Участников: 583
Адрес сайта рассылки: http://www.linuxrsp.ru
Адрес этого письма в архиве: http://subscribe.ru/archive/comp.soft.linux.debate/msg/174146


-*Информационный канал Subscribe.Ru
Написать в лист: mailto:comp.soft.linux.debate-list@subscribe.ru
Отписать : mailto:comp.soft.linux.debate--unsub@subscribe.ru

http://subscribe.ru/ mailto:ask@subscribe.ru

Ответить  
"Igor Gavriluk"
Sun, 20 Jun 2004 22:48:42 +0300 (#174146)

 

А это бестселлер от Сигейта на сегодняшний день.
Стоит около 280 американских рублей в Москве.
15000 оборотов в минуту
36 Гигабайт объёма
8 мегабайт кэша
Интерфейс uwSCSI-320(MB/s)

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



-*Название листа "Обсуждения и споры о свободных системах и всём сопутствующем"
Написать в лист: comp.soft.linux.debate-list@subscribe.ru
Архив Листа - http://subscribe.ru/archive/comp.soft.linux.debate Поиск: http://www.google.com
Адрес правил листа http://subscribe.ru/catalog/comp.soft.linux.debate/rules
Номер письма: 1315; Возраст листа: 241; Участников: 583
Адрес сайта рассылки: http://www.linuxrsp.ru
Адрес этого письма в архиве: http://subscribe.ru/archive/comp.soft.linux.debate/msg/174148


-*Информационный канал Subscribe.Ru
Написать в лист: mailto:comp.soft.linux.debate-list@subscribe.ru
Отписать : mailto:comp.soft.linux.debate--unsub@subscribe.ru

http://subscribe.ru/ mailto:ask@subscribe.ru

Ответить  
"Igor Gavriluk"
Sun, 20 Jun 2004 22:54:06 +0300 (#174148)

 

Да опечатка там... Чего вы... 65 Мегабайт, конечно, в секунду...
А в другом месте должно было быть "самый гнилой винт дает 2-3 Мегабайт/с уже
"для приложений""

Просто я параллельно с написанием опуса смотрел на даташиты к контроллерам
винтов (для справки),
а там то биты в секунду, то байты в секунду, вот и сбился в буквах
множителей. Бывает, особенно поздней ночью.
Внутренняя скорость передачи данных у хай-энд винтов составляет порядка 7-11
гигаБИТ в секунду,
после декодирования около 700-900мегаБайт в секунду по внутренней шине.

Да простит меня Мироздание, постараюсь впредь воздержаться от невычитанных
постингов.

Спасибо за критику.
СНП, И.Г.


-*Название листа "Обсуждения и споры о свободных системах и всём сопутствующем"
Написать в лист: comp.soft.linux.debate-list@subscribe.ru
Архив Листа - http://subscribe.ru/archive/comp.soft.linux.debate Поиск: http://www.google.com
Адрес правил листа http://subscribe.ru/catalog/comp.soft.linux.debate/rules
Номер письма: 1317; Возраст листа: 242; Участников: 583
Адрес сайта рассылки: http://www.linuxrsp.ru
Адрес этого письма в архиве: http://subscribe.ru/archive/comp.soft.linux.debate/msg/174184


-*Информационный канал Subscribe.Ru
Написать в лист: mailto:comp.soft.linux.debate-list@subscribe.ru
Отписать : mailto:comp.soft.linux.debate--unsub@subscribe.ru

http://subscribe.ru/ mailto:ask@subscribe.ru

Ответить  
"Igor Gavriluk"
Sun, 20 Jun 2004 23:38:27 +0300 (#174184)

 

i686-pc-linux-gnu)

сорри, кажется в коробке HDD вакуум и по определению воздуха нет !!!


-*Название листа "Обсуждения и споры о свободных системах и всём сопутствующем"
Написать в лист: comp.soft.linux.debate-list@subscribe.ru
Архив Листа - http://subscribe.ru/archive/comp.soft.linux.debate Поиск: http://www.google.com
Адрес правил листа http://subscribe.ru/catalog/comp.soft.linux.debate/rules
Номер письма: 1313; Возраст листа: 241; Участников: 583
Адрес сайта рассылки: http://www.linuxrsp.ru
Адрес этого письма в архиве: http://subscribe.ru/archive/comp.soft.linux.debate/msg/174136


-*Информационный канал Subscribe.Ru
Написать в лист: mailto:comp.soft.linux.debate-list@subscribe.ru
Отписать : mailto:comp.soft.linux.debate--unsub@subscribe.ru

http://subscribe.ru/ mailto:ask@subscribe.ru

Ответить   Русскин Андрей Sun, 20 Jun 2004 20:00:54 +0400 (#174136)

 

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

(Кстати, лет 8 назад именно такая проблема встречалась на Conner'ах и IBM'ах
- головки в зоне парковки при простое более 2-3 недель
приваривались к поверхности, и винт "замолкал"; лечилось просто - стукнуть
хорошенько по компьютеру, чтобы "отлепить" залипшее... На буржуйских
мид-менеджеров, покупавших Компаки и Деллы во всяких там Компьютерлендах,
такое "лечение" производило очень сильное впечатление...)

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

Я не так давно промышлял восстановлением данных с поврежденных винтов,
пока это было возможно без очень специфических контроллеров (стендов).
Бывало даже такое: переставляешь диски (пластины!) на другую механику,
ловишь "нулевой" сектор, и - вперед!
Работает на новом шпинделе с новой электроникой... Без крышки...
Только "высокие" 4" винты с 8-12 пластинами нельзя было включать без крышки
- ось шпинделя фиксировалась и на крышке тоже, диски шли вразнос без второй
точки подвеса, царапались об головки.

Воздух выполняет очень важную функцию - по сути он является "держателем"
головок. Т.е. имеет место "аэродинамический подвес" системы
"тонарм-головки".
Объясняется это решение очень просто - в пакете более одной головки (обычно
от 2 до 8), и обеспечить прецизионное регулирование зазора во всех парах
головка-поверхность технически не представляется возможным (для массового
производства). Поэтому используется нежесткая система с аэродинамической
стабилизацией зазора. Пограничный слой, смачивающий поверхность и
раскручивающийся вместе с ней, создаёт в зазоре подъёмную силу, которая
компенсируется реакцией упругого подвеса головки. Для того, чтобы избежать
флаттера (колебаний), применяют различные демпфирующие системы, сейчас в
основном тоже аэродинамические - прорези и дефлекторы на тонарме, разыне
фокусы с завихрениями...
Кстати, при остановленном шпинделе головки довольно сильно прижимаются к
диску, и поэтому старт-стопы винтов выполняются только в зоне парковки. На
старых винтах для гарантированной парковки применялись специальные
соленоиды-замки, потом догадались использовать все тот же раскрученный
воздух и простейшие пластиковые защёлки...

Но это уже совсем оффтопик. Да простят мне читатели!
СНП, И.Г.


-*Название листа "Обсуждения и споры о свободных системах и всём сопутствующем"
Написать в лист: comp.soft.linux.debate-list@subscribe.ru
Архив Листа - http://subscribe.ru/archive/comp.soft.linux.debate Поиск: http://www.google.com
Адрес правил листа http://subscribe.ru/catalog/comp.soft.linux.debate/rules
Номер письма: 1318; Возраст листа: 242; Участников: 583
Адрес сайта рассылки: http://www.linuxrsp.ru
Адрес этого письма в архиве: http://subscribe.ru/archive/comp.soft.linux.debate/msg/174201


-*Информационный канал Subscribe.Ru
Написать в лист: mailto:comp.soft.linux.debate-list@subscribe.ru
Отписать : mailto:comp.soft.linux.debate--unsub@subscribe.ru

http://subscribe.ru/ mailto:ask@subscribe.ru

Ответить  
"Igor Gavriluk"
Mon, 21 Jun 2004 00:17:35 +0300 (#174201)

 

i686-pc-linux-gnu)

Да, век живи - век учись :-)

--
А я сейчас слушаю artist - title - Girl, you'll be a woman soon


-*Название листа "Обсуждения и споры о свободных системах и всём сопутствующем"
Написать в лист: comp.soft.linux.debate-list@subscribe.ru
Архив Листа - http://subscribe.ru/archive/comp.soft.linux.debate Поиск: http://www.google.com
Адрес правил листа http://subscribe.ru/catalog/comp.soft.linux.debate/rules
Номер письма: 1319; Возраст листа: 242; Участников: 589
Адрес сайта рассылки: http://www.linuxrsp.ru
Адрес этого письма в архиве: http://subscribe.ru/archive/comp.soft.linux.debate/msg/174356


-*Информационный канал Subscribe.Ru
Написать в лист: mailto:comp.soft.linux.debate-list@subscribe.ru
Отписать : mailto:comp.soft.linux.debate--unsub@subscribe.ru

http://subscribe.ru/ mailto:ask@subscribe.ru

Ответить   Русскин Андрей Mon, 21 Jun 2004 08:47:59 +0400 (#174356)

 

Yuri N. Glibovetz [mailto:gyn***@m*****.ru] пишет:

Так ведь эти системы - RealTime! И ядро у них крохотное было, большинство
функций выполнялось внешними утилитами. Естественно, чем быстрее выполняется
загрузка исполняемых модулей, тем круче. А время загрузки - это поиск файла
(включая Kernel Time Overhead) и его чтение в память. Целиком и полностью
солилдарен - так "правильнее"!. Если я не перепутал, в тех же vxWorks и QNX
даже специальная опция при создании файла есть - типа "DirectMapping" или
что-то в таком роде...

N.B. Кстати, по непроверенным слухам, всё те же PDP-11 до сих пор всякие
"ядрёные" экспериментальные установки обслуживают...
Их кто-то даже в одночиповом варианте с флэш-диском делал - то ли STMicro,
то ли HOLT IC, не помню...


-*Название листа "Обсуждения и споры о свободных системах и всём сопутствующем"
Написать в лист: comp.soft.linux.debate-list@subscribe.ru
Архив Листа - http://subscribe.ru/archive/comp.soft.linux.debate Поиск: http://www.google.com
Адрес правил листа http://subscribe.ru/catalog/comp.soft.linux.debate/rules
Номер письма: 1311; Возраст листа: 241; Участников: 583
Адрес сайта рассылки: http://www.linuxrsp.ru
Адрес этого письма в архиве: http://subscribe.ru/archive/comp.soft.linux.debate/msg/173864


-*Информационный канал Subscribe.Ru
Написать в лист: mailto:comp.soft.linux.debate-list@subscribe.ru
Отписать : mailto:comp.soft.linux.debate--unsub@subscribe.ru

http://subscribe.ru/ mailto:ask@subscribe.ru

Ответить  
"Igor Gavriluk"
Sun, 20 Jun 2004 00:55:18 +0300 (#173864)

 

i686-pc-linux-gnu)

On Sat, 19 Jun 2004 01:53:11 +0300
"Igor Gavriluk" <gavrik2***@m*****.ru> wrote:

Еще на ZX Spectrum была. Кажется DR-DOS называлась. Но это вообще
запущеный случай.--

С наилучшими пожеланиями
Крохин Анатолий (kraw)
icq 20060869


-*Название листа "Обсуждения и споры о свободных системах и всём сопутствующем"
Написать в лист: comp.soft.linux.debate-list@subscribe.ru
Архив Листа - http://subscribe.ru/archive/comp.soft.linux.debate Поиск: http://www.google.com
Адрес правил листа http://subscribe.ru/catalog/comp.soft.linux.debate/rules
Номер письма: 1321; Возраст листа: 242; Участников: 589
Адрес сайта рассылки: http://www.linuxrsp.ru
Адрес этого письма в архиве: http://subscribe.ru/archive/comp.soft.linux.debate/msg/175076


-*Информационный канал Subscribe.Ru
Написать в лист: mailto:comp.soft.linux.debate-list@subscribe.ru
Отписать : mailto:comp.soft.linux.debate--unsub@subscribe.ru

http://subscribe.ru/ mailto:ask@subscribe.ru

Ответить   Крохин Анатолий Александрович Mon, 21 Jun 2004 08:12:14 +0400 (#175076)

 

Крохин Анатолий Александрович wrote:

TR-DOS - TapeRecorder-DOS



-*Название листа "Обсуждения и споры о свободных системах и всём сопутствующем"
Написать в лист: comp.soft.linux.debate-list@subscribe.ru
Архив Листа - http://subscribe.ru/archive/comp.soft.linux.debate Поиск: http://www.google.com
Адрес правил листа http://subscribe.ru/catalog/comp.soft.linux.debate/rules
Номер письма: 1325; Возраст листа: 243; Участников: 587
Адрес сайта рассылки: http://www.linuxrsp.ru
Адрес этого письма в архиве: http://subscribe.ru/archive/comp.soft.linux.debate/msg/175973


-*Информационный канал Subscribe.Ru
Написать в лист: mailto:comp.soft.linux.debate-list@subscribe.ru
Отписать : mailto:comp.soft.linux.debate--unsub@subscribe.ru

http://subscribe.ru/ mailto:ask@subscribe.ru

Ответить  
Kirill Trofimov
Tue, 22 Jun 2004 10:19:01 +0700 (#175973)