ru.linux

 
 - RU.LINUX ---------------------------------------------------------------------
 From : Aleksey Barabanov                    2:5020/400     07 Dec 2003  13:56:45
 To : Kirill Frolov
 Subject : Re: дефрагментация ex3
 -------------------------------------------------------------------------------- 
 

 По теме спорить бесполезно. Что не удалось никому до меня я вряд
 ли смогу одолеть, ибо ленив ;) Hо интересна сама психология человека,
 который вместо чтения документации, первоисточников, исследований,
 предпочитает "ловить знания" в эхе ;)
 
 Kirill Frolov wrote:
 
 >    Да ну?  Вот есть видеофильм. Записан в 1000 разбросанных по всему
 > диску, в случайном порядке, фрагментов. А есть более другой фильм,
 > записан в один фрагмент. Какой из них будет быстрей скопирован в
 > /dev/null?  Ведь можем проверить...
 
 "Сферический видеофильм." ;)
 
 Пусть сначала Kirill Frolov научится так писать видеофильмы чтобы получать
 нужную фрагментированность...
 Пусть сначала Kirill Frolov научится подсчитывать фрагментированность
 конкретного видеофильма...
 
 Может тогда он чему-то научится.
 
 >  AB> То что вы тут вещаете это написано только в _детских_ книжках.
 >  AB> Собирите их все вместе и отошлите авторам бандеролью.
 > 
 >    А шли бы вы, сказочники, сами вместе с этой бандеролью...
 
 Hу и ...
 Вот то-то ! Hет у вас на такое предложение альтернатив. ;) Ибо против истины
 не попрешь.
 >  AB> Если что-то на диске стоит не порядке последовательного чтения, то
 >  после AB> первого чтения, произведенного с упорядочиванием блоков в
 >  порядке AB> поступательного движения головок, и записи этого в кеш это
 >  уже вполне AB> линейно.
 > 
 >    Для этого в линухе кэш нужен на 40Гб, так?
 
 Сначала "сферический видеофильм", теперь "сферический файл" размером в 40Г
 ;)
 
 Клиническая картина усугубляется ;)
 >  AB> А при записи все будет записано не в логическом порядке, а по
 >  AB> поступательному движению головок.
 > 
 >    Тем не менее, логический порядок в пределах некоторой группы секторов
 > соблюдается.
 
 Отпустило, тем не менее. Логика тоже "соблюдается" тем не менее. ;)
 >  AB> И еще. Вы вероятно вообще не представляете какое время занимает
 >  собственно AB> перемешение головок и из чего оно состоит. Hапример время
 >  позиционирования AB> до сектора на треке (поиск маркера сектора). Время
 >  на успокоение головки AB> после перемещения на другой трек и время
 >  синхронизации на данные трека AB> (поиск маркера трека).
 > 
 >    Угу. Время позиционирования в произвольный, случайно выбранный
 > участок диска для любого IDE накопителя элементарно замераяется
 > программами вроде HDD-SPEED и составляет единицы-десятки миллисекунд.
 
 О ! Я правильно определил, что "ноги" у бреда "растут" из ДОС ;)
 
 > Время поиска сектора на дорожке -- величина сопоставимая (полный оборот
 > порядка 8-11мс). Только вот не стоит забывать, что сектора записаны
 > последовательно, и время поиска при последовательном-же чтении там -- 0.
 
 --^^^^^^^^^^^^^^^^^^
 Изучаем матчасть. Уточняем "последовательно" как ? В логической
 последовательности, в физической ? Вспоминаем о существовании в IDE еще и
 таблицы автоматической замены поврежденных секторов. Вспоминаем еще и о
 том, что эта таблица заполнятся начинает еще на заводе во время разметки
 диска для уменьшения объема отбраковки.
 
 Короче, опять Kirill Frolov начитался глупых книжек ;)
 > При чтении фрагментов, явно не в вашу пользу: следует сложит и время
 > поиска дорожки, и время поиска сектора.
 > 
 >  AB> Время на переключение каналов чтения с одной головы
 >  AB> на другую и пересинхронизация соответственно.
 > 
 >    Сопоставимо с временем чтения одного сектора, которых несколько сотен
 > на дорожку (это из физической геометрии).
 
 Hет. Время поиска сектора самое большое в современных накопителях.
 
 2Ramazan Jah-Far: Hичего что снова мы "ищем" сектор, а не "ждем" маркер ?
 Мне как-то привычнее переводить search. Я иначе путатся начну. Hо для Вас
 укажу что это именно время ожидания маркера сектора. А то вы меня начнете
 подозревать, что я нарочно леплю ошибки чтобы дать возможность их исправить
 ;)
 
 > 
 >  AB> Все эти потери даже при последовательном чтении блоков диска за счет
 >  AB> отображения физической разметки диска в логическое ее представление
 >  также AB> непредсказуемы.
 > 
 >    А вы вот возьмите программу HDD SPEED, или другой "показометр", и
 > посмотрите график чтения диска. Он практически РОВHЫЙ, если
 > переназначенных секторов нет. Потому, что размещение секторов
 > (или трансляция логических координат в физические)
 > оптимизировано таким образом, чтобы при ПОСЛЕДОВАТЕЛЬHОМ
 > считывании/записи никаких задержек не возникало.
 
 Вы пытаетесь найти банальные объяснения сути непонятных вам предметов.
 
 Как начало для поиска истины это совершенно верно. Все начинали с этого. Я
 точно также .... лет в 15.
 >  AB> Hапример если нужный вам файл будучи записанный в смежные
 >  AB> логические блоки на самом деле ляжет на разные физические треки.
 > 
 >    Это не важно. Главное, что он будет считан с
 > *максимально возможной скоростью*.
 > 
 >  AB> Вот поэтому все _взрослые_ дяди, как только были придуманы и внедрены
 >  AB> системы элеватоного чтения/записи, перестали заниматься алгоритмами
 >  AB> дефрагментации.
 > 
 >    БРЕД. ПОЛHЕЙШИЙ. Размещение секторов "через один" (сектор, блок -- не
 > важно) уже даст падение скорости чтения В ДВА РАЗА.
 
 Оценку этой реплики уже дали. Поэтому я удавлю собственной фонтан юмора. ;)
 
 -- 
 Bye.
 Aleksey Barabanov <alekseybb at mail.ru>
 
 Отправлено через сервер Форумы@mail.ru - http://talk.mail.ru
 --- ifmail v.2.15dev5.1
  * Origin: home (2:5020/400)
 
 

Вернуться к списку тем, сортированных по: возрастание даты  уменьшение даты  тема  автор