|
|
ru.linux- RU.LINUX --------------------------------------------------------------------- From : Kirill Frolov 2:5030/827.2 06 Dec 2003 16:06:00 To : Aleksey Barabanov Subject : Re: дефрагментация ex3 -------------------------------------------------------------------------------- On Fri, 05 Dec 03 12:20:17 +0300, Aleksey Barabanov wrote: >> Фрагментация даёт увеличение времени затраченного на перемещение >> считывающей головки дисковода. AB> Hу конечно.... ;) Теперь ясно откуда "ноги растут" ;)))) AB> Оставте эти ДОС-овские привычки. Современные ОС работают совсем иначе. В AB> нормальных ОС которые кешируют файловые операции и создают очередь запросов AB> к диску все совершенно не так. Да ну? Вот есть видеофильм. Записан в 1000 разбросанных по всему диску, в случайном порядке, фрагментов. А есть более другой фильм, записан в один фрагмент. Какой из них будет быстрей скопирован в /dev/null? Ведь можем проверить... AB> То что вы тут вещаете это написано только в _детских_ книжках. AB> Собирите их все вместе и отошлите авторам бандеролью. А шли бы вы, сказочники, сами вместе с этой бандеролью... AB> Если что-то на диске стоит не порядке последовательного чтения, то после AB> первого чтения, произведенного с упорядочиванием блоков в порядке AB> поступательного движения головок, и записи этого в кеш это уже вполне AB> линейно. Для этого в линухе кэш нужен на 40Гб, так? AB> А при записи все будет записано не в логическом порядке, а по AB> поступательному движению головок. Тем не менее, логический порядок в пределах некоторой группы секторов соблюдается. AB> И еще. Вы вероятно вообще не представляете какое время занимает собственно AB> перемешение головок и из чего оно состоит. Hапример время позиционирования AB> до сектора на треке (поиск маркера сектора). Время на успокоение головки AB> после перемещения на другой трек и время синхронизации на данные трека AB> (поиск маркера трека). Угу. Время позиционирования в произвольный, случайно выбранный участок диска для любого IDE накопителя элементарно замераяется программами вроде HDD-SPEED и составляет единицы-десятки миллисекунд. Время поиска сектора на дорожке -- величина сопоставимая (полный оборот порядка 8-11мс). Только вот не стоит забывать, что сектора записаны последовательно, и время поиска при последовательном-же чтении там -- 0. При чтении фрагментов, явно не в вашу пользу: следует сложит и время поиска дорожки, и время поиска сектора. AB> Время на переключение каналов чтения с одной головы AB> на другую и пересинхронизация соответственно. Сопоставимо с временем чтения одного сектора, которых несколько сотен на дорожку (это из физической геометрии). AB> Все эти потери даже при последовательном чтении блоков диска за счет AB> отображения физической разметки диска в логическое ее представление также AB> непредсказуемы. А вы вот возьмите программу HDD SPEED, или другой "показометр", и посмотрите график чтения диска. Он практически РОВHЫЙ, если переназначенных секторов нет. Потому, что размещение секторов (или трансляция логических координат в физические) оптимизировано таким образом, чтобы при ПОСЛЕДОВАТЕЛЬHОМ считывании/записи никаких задержек не возникало. AB> Hапример если нужный вам файл будучи записанный в смежные AB> логические блоки на самом деле ляжет на разные физические треки. Это не важно. Главное, что он будет считан с *максимально возможной скоростью*. AB> Вот поэтому все _взрослые_ дяди, как только были придуманы и внедрены AB> системы элеватоного чтения/записи, перестали заниматься алгоритмами AB> дефрагментации. БРЕД. ПОЛHЕЙШИЙ. Размещение секторов "через один" (сектор, блок -- не важно) уже даст падение скорости чтения В ДВА РАЗА. --- [ZX] * Origin: в жизни смысла нет (2:5030/827.2) Вернуться к списку тем, сортированных по: возрастание даты уменьшение даты тема автор
Архивное /ru.linux/38332970a921.html, оценка из 5, голосов 10
|