» Дефрагментация диска

tomset

Цитата:

Только вновь создаваемому файлу выделяется максимально большой  свободный кусок.

Про все не буду говорить но есть один комп с ХР, так там вновь копируемый с фотика файл сразу фрагментирован - хотя места свободного валом.


Цитата:

тем что все двигает, даже то что не фрагментировано

Да ладно? Это смотря чем и что заказывается и даже при оптимизации в том же ауслоджике не всё двигается.


Цитата:

Совершенно не может влиять и не показывает положение индексных записей.

Что не может?
Опять же, ауслоджик показал сто папка фрагментирована (по сути индексы) - после дефрагментации всё в одном кластере.


Цитата:

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

Серьёзно? Что то изменилось в идеологии NTFS и она перестала проверять записанное на корректность и, только в случае успешности, актуализировать новое местоположение и закрывать транзакцию в журнале ФС?
Или всё ещё про FAT не можете забыть?


Цитата:

у меня сейчас десятка. Захожу в оптимизацию диска. Запускаю анализ - ответ 0% фрагментации.

Ну всё - теперь истукан новый и он один - 10ка.
Впрочем дело не только в 10-ке, такой процент может показать и в 7-ке. И дело не в отсуствии фрагментации а в том что считается фрагментацией. Я не помню где кто то писал и точные цифры ( а также насколько это достоверно), но было что то про то, что фрагменты более 64 мегов не считаются.
Так что, если есть сомнения, дисковый редактор в руки и смотреть ранлисты.


Цитата:

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

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

Опять же, в ауслоджике (старенькая портэйбл (официальная) версия) запустил полную оптимизацию.
В плане дефрагментации всё нормально, но обычно, при оптимизации он всё подтягивает к началу (*) и как бы в конце должно остаться свободное место одним куском. Ан нет - есть бреши. Решил разобраться и увидел что там имеются записи идентификатора зоны (этипа пишется что скачано с интернета). Нашёл к чему относится, убрал эти сведения, запустил оптимизацию по новой - всё стало отлично.
(*) В том же VoptX есть (ИМХО) хорошая фишка - можно задать чтобы файлы контрольных точек помещались в конце раздела.

Цитата:

Серьёзно? Что то изменилось в идеологии NTFS и она перестала проверять записанное на корректность и, только в случае успешности,

Успешности чего?
Что команда записи выполнена и не более.
Но имелся ввиду сам хард. Он ни про ни какие NTFS, FAT в принципе на знает.
Работает исключительно с LBA.

Опять вы не понимаете о чем вам пишут.
Все эти прелести просто бессмысленны для современного харда.
Только для успокоения упертого пользователя.
Почему? Я уже написал.
Разработчики подобных утилит, не знают, как работает сам хард.
Что толку выстроить кластеры файла по порядку, если физически сектора имеют совершенно другое положение.
Причем разное на каждом экземпляре.
И толку для производительности от такой дефрагментации ни какого.
Все выводы опять строятся на древних хардах с шаговыми двигателями работающих в PIO cо скоростью ниже чем мегабайт в секунду.
Там действительно все было по порядку и логически и физически.
А дефектные сектора заносились в специальные поля при низко уровнем форматировании.
И понятий мониторинг - SMART для них вообще не было.
Как раз Винда, учитывает особенности харда, и больше чем нужно не дефрагментирует.



Цитата:

Ну всё - теперь истукан новый и он один - 10ка.

И опять мимо, читаете между строк.
Я сейчас на десятке, а другие компы убраны на время ремонта.
Поэтому показать на других системах не могу.
Ну и внимательно посмотрите картинку о разной плотности.
Что я выкладывал. Причем это логическая адресация.
Физическая вообще неизвестно какая.
Может тогда дойдет.

tomset

Цитата:

Успешности чего? Что команда записи выполнена и не более.

Что данные скопированы на новое место, что они считываются и целы, и что можно прописать их новой расположение, а старое забыть. Как то так.
И как бы то же самое происходит и при копировании данных и вообще при работе с теми же метафайлами.
Так что, если считать опасным дефрагментацию в виду гипотетического "хард сказал что записал, а сам похерил", то с таким же успехом можно считать опасной работу вообще.

Впрочем, про позицию суслика я уже писал. И в ней нет ничего нового.


Цитата:

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

И очередные шоры. Во первых я сужу по множеству систем, в том числе и по SATA-шным винтам. Уже упомянутый выше комп - под ХР стоит программа, которая запиывает множественные параметры тех процесса. В ней можно посмотреть графики любого из за весь процесс работы. Как будет доступ, сделаю скриншот с конкретными цифрами, но там файл 2 мега может состоять из 200 фрагментов. И когда оно так, то текущие графики открываются со скрипом, хотя если задать дату более раннего времени, то открытие моментальное. А всё потому что старые файлы дефрагментированы. Дефрагментируем новые файлы и вот уже и новые графики открываются шустро.

ЗЫ: А так, конечно же, я мастодонт и не вижу умею смотреть на уровне электронного микроскопа как там электроны бегают.

Опять рассматриваете частный случай.
О чем я сразу написал, что программа не оптимизирована. И только для нее нужна постоянная дефрагментация.
Да еще и не виндовая, а супер-пупер, иначе не поможет.

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

tomset
Чуть выше я писал и о фрагментации записываемых на этот раздел фоток (файлов)
Так что про программу не частный случай а один из примеров. Если бы даже под файлы место резервировалось заранее, они бы наверняка тоже были фрагментированы.
И вероятнее всего из за описанной К.Касперски болячки драйвера NTFS (как минимум в ХР и ранее).

tomset

Цитата:

Что толку выстроить кластеры файла по порядку, если физически сектора имеют совершенно другое положение.

Вы излишне драматизируете. Толк он виден ну вот прямо как на ладони.

temp9285


Цитата:

И вероятнее всего из за описанной К.Касперски болячки драйвера NTFS (как минимум в ХР и ранее).

Я, наверное помню ту статью. Ну он там всё про дыры на NTFS, если эта та статья. Типо что винда не может перемещать блоками не то меньше 16 кБ, не то меньше 64 кБ. Видел этот эффект на Windows 2000, не момню только, SP3 или SP4. На ХР с ним не столкнулся.

Добавлено:
temp9285


Цитата:

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

Я помню такой эффект на одной из версий Total Commander. Записываешь фильм на совершенно чистый раздел, файл фрагментированный. Потом не то Total Commander исправились, не то я какие настройки изменил, этот косяк пропал. Вот уже несколько лет винда и Total Commander записывают файлы не фрагментируя, находя подходящее свободное место, ХР.

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

Презабавнейше наблюдать взаимонепонимание "физиков" (tomset) и лириков "логистов"
(temp9285,ZSZ).смотрящих на винт,с разных сторон транслятора винта.Каждый стучит в свою колокольню,не слыша чужую

alexyc1
Презабавнейше не то слово.
Мне вот почему то это напоминает что то типа.
tomset - Это железная хреновина весом несколько тон - её невозможно поднять от земли. К тому же в неё залили керосин, который потом будет гореть - она сгорит, даже если сможет и приподяться над землёй.
temp9285,ZSZ Но ведь оно летает, причём очень даже неплохо.


Лично мне не надо знать анатомию человека на уровне атомарного строения, все нейро-ауральные взаимодействия при работе организма или его отдельного иного органа.
Но мне достаточно знать состав продуктов чтобы понять вреден он для организма или нет.

Но если говорить о более низком уровне в пределах известного мне.
1. Диск с несколькими блинами и в два раза больше головок. Если головки будут читать одновременно, то наибольшая скорость (без кэширования) будет в случае если логические сектора будут физически находится на разных сторонах блинов в одной и той же точке нахождения головок.
Разве не так? Но ведь они не идут последовательно.
2. Я не знаю каковы возможности нынешних головок, поэтому вспомню очень старые винты. При их работе нельзя было за один проход прочесть два последовательных физических сектора, расположенных на одном трек. Поэтому тогда использовалось чередование и даже была утиль в БИОСе, которая показывала какое чередование оптимально.
Нынешние прошивки конечно же намного круче и т.п., но вряд ли они могут изменить ситуацию. И это уже удел прошивки строить логическю карту так, чтобы скорости были получше.

ЗЫ: А вот, ещё вспомнилось "И всё таки, она вертится!"

temp9285


Цитата:

Но если говорить о более низком уровне в пределах известного мне.

Так наверное сами видели, при последовательном логическом вычитывании диска той же Викторией или MHDD, скорость чтения секторов дергается не хаотично, а лесенкой, примерно через равные промежутки. Если бы всё было вразнобой: физика-логика, как нам внушает tomset, то не было бы такой стройной красивой картинки.

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

Цитата:

Так наверное сами видели, при последовательном логическом вычитывании диска той же Викторией или MHDD, скорость чтения секторов дергается не хаотично, а лесенкой, примерно через равные промежутки. Если бы всё было вразнобой: физика-логика, как нам внушает tomset, то не было бы такой стройной красивой картинки.

Tomset как раз всё правильно и говорит.
Возьмите к примеру Самсунговские харды - так там зонное
распределение вообще хитрое - от скорости зависит или,
например, Сигейты с медиакэшем - там головы туда-сюда
прыгают так, что весь толк от дефрагментации сводится на
нет.
И как можно логикой бороться с физическими факторами ?!

Lucky1001

Цитата:

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

Не ну действительно. Я вижу что эффект есть - а мне пытаются обьяснить что я слепой.

Lucky1001

Цитата:

что весь толк от дефрагментации сводится на
нет.

При наличии фрагментации будут прыгать больше и намного чаще, только и всего.
Сейчас, может быть, гляну на Самсунге.

temp9285
Хотя я "физик" до корней волос,я не буду принимать ничью сторону.Но ваше сравнение подкорректирую-
tomset вам рассказывает КАК и ПОЧЕМУ летает железка,а вы сZSZ сравниваете аэродинамическую конструкцию/изыски,вплоть до гладкости общивки на одной и той же модели железки после разных шлифовальных машинок.Каждому-свое.С т зрения обывателя,даже в моем лице, накой не нужно знание работы,а нужны красивые цифры "скорости" работы.И чем они достигаются-мало интересует


Цитата:

1. Диск с несколькими блинами и в два раза больше головок. Если головки будут читать одновременно, то наибольшая скорость (без кэширования) будет в случае если логические сектора будут физически находится на разных сторонах блинов в одной и той же точке нахождения головок.
Разве не так? Но ведь они не идут последовательно

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

Цитата:

При их работе нельзя было за один проход прочесть два последовательных физических сектора, расположенных на одном трек. Поэтому тогда использовалось чередование и даже была утиль в БИОСе, которая показывала какое чередование оптимально.

Не совсем понимаю,о чем речь.И главное-как вы можете вообще прочесть извне физику,минуя транслятор?

Цитата:

И это уже удел прошивки строить логическю карту так, чтобы скорости были получше.

Да,вот этим и занимается транслятор CHS в LBA,с учетом таких параметров как дефектлисты/зонник,етс
пс
Судить же по тому как "расположены файлы" по звукам перемещения головок винта,это верх глупости.Помимо работы непосредственно с пользовательскими данными,винт успевает делать множество задач в фоне.И тишина из винта-это не показатель,что головки "двигаются линейно",читая линейно.Очень показательно понаблюдать за работой винта с окном в гермоблок.

ппс
Не менее забавно,отсуствие "оптимизаторов" для иных ОСей,на тех же самых дисках.

alexyc1

Цитата:

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

Запустите копирование файлов в один поток - бесшумная работа диска, и в 2 потока - громыхание как на стиральной доске. Ну и?..

Не получилось сделать картинку от Самсунга, но одном компе из-за RAID Виктория не грузится, на втором слишком быстро работает.

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


Цитата:

Не менее забавно,отсуствие "оптимизаторов" для иных ОСей,на тех же самых дисках.

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

ЗЫ: Тут писалась о том, что упоминаемая мною программа плохая. А от что мешает самой винде изучать поведение программ (типа как это делает Prefetch) - видит что программа создаёт файл и потом наполняет его постепенно до размера ХХХ. Бах, и сразу ей зарезервировал такой фрагмент. Сделала программа файл меньше - осталось окошко. Надо больше, дала ещё фрагмент (типа как с MFT делает). Всёж меньше фрагментов.

ZSZ
Шум зависит лишь от амлитуды движения голов.Естествненно,потоками даже нефрагментированных данных можно так загрузить диск,что ему не только возможностей механики,но и "мозгов даже не хватит",и скорость упадет до смехотворных значений.
Я пишу о том,что нет линейного перемещения,яля грампластинка на жестких дисках в процессе работы с пользовательскими данными.Всегда голова "дергается" с большей или меньшей амплтудой,совершая движения,подавляющее большинство которых из них вы не услышите и более того-не увидите,т к растояние даже между соседними треками-нанометры.

Добавлено:
temp9285

Цитата:

Да ладно? Разве в ext4 нет онлайн дефрагментации? И да, тоже вспомнились споры в фанатами иных осей.

Речь идет о "шлифовальных машинках",т е стороннем ПО.Или я что то упустил.

Цитата:

"Толку от всей этой дефрагментации - всё равно винда не даст разогнаться".

Так и в жизни примерно тоже самое,главный тормоз-винда,самый агрессивный вирус-антивирусное ПО....

alexyc1


Цитата:

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

При отсутствии фрагментации головки дёргаются реже и с меньшей амплитудой. То есть, километраж пробега при оптимизации расположения файлов по имени значительно уменьшается. Что и видно по высоким скоростям. Малейшая дестабилизация - включили фильм, скорость копирования непропорционально падает.

alexyc1

Цитата:

Речь идет о "шлифовальных машинках",т е стороннем ПО.Или я что то упустил.

Я не в курсе, но подозреваю что если родная работает хорошо, то зачем стороннюю.
Тем более что сторонники невинды (надеюсь не обидятся) не очень любят распространяться о проблемах.

temp9285


Цитата:

но подозреваю что если родная работает хорошо, то зачем стороннюю.

Так кому то и коза-невеста.Или,просто убежденные холостяки,которым более чем достаточно предоставляемого "из коробки"

Добавлено:
ZSZ

Цитата:

о есть, километраж пробега при оптимизации расположения файлов по имени значительно уменьшается

Работа состоит не только из последовательного копирования строго по алфавиту.Даже в вашем примере,о играх,данные считываются с винта не по алфавиту.И если грубо гря,в инишнике прописывать копировать в память файл "а" ,а затем "х",то все преимущества "оптимизации" по имени сводятся на ноль.А с учетом хитросплетений зонника+транслятора не факт,что окажется загрузка быстрее,чем собрать в память нужное из разбросанных с логической точки зрения вразнобой секторов

alexyc1
Ну смотря какая коза.
Если взять ту же винду и её дефрагментаторы.
В ХР можно было посмотреть число фрагментированых и имена файлов.
Дальше всё идёт к отуплению пользователей: "зачем тебе это знать - один хрен не поймёшь" "у тебя всё нормально - Биллом Гейтсом клянусь".
Опять же:
- если алгоритмы работы с самой фс лучше и реально уменьшают фрагментацию, то может и не нужно дефрагментировать
- если рассматривать аспект восстановления фрагментированных данных, так и здесь пользователи невинды более продвинуты и знают про бэкап
- если рассматривать вопросы быстродействия, то в той же винде достаточно поставить касперского иль ещё чего тормозящего и сразу возникает желание что то наоптимизировать.
- и т.д. и т.п.

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

Небольшой эксперимент.
Выбрал папку Windows - куча мелких файлов, 2,2 ГБ. Сказал копировать это на другой физический диск. 52 секунды. Винда лежит в первых 5 ГБ диска, первый раздел.

Повторил то же, но параллельно запустил фильм, логически лежащий поближе к этой папке Windows, поток около 0,2 Мб/с. Результат - 54 секунды.

Повторил то же, но фильм взял с самого конца физического диска, поток такой же. Результат - 59 секунд.

Запуском фильма имитировал наличие фрагментации. Сейчас попробую в одном месте наделать фрагментированные и нефрагментированные файлы.

temp9285

Цитата:

Ну смотря какая коза

Согласен,но не все же Алены Делоны.

Цитата:

Дальше всё идёт к отуплению пользователей: "зачем тебе это знать - один хрен не поймёшь" "у тебя всё нормально - Биллом Гейтсом клянусь".

Так ВСЕ в жизни постепенно сводится к этому.

Цитата:

Ну и зачем мне сдался штатный?

Вы просто "Ален Делон",и коза вас не устроит.

Добавлено:
ZSZ

Цитата:

Повторил то же, но параллельно запустил фильм, логически лежащий поближе к этой папке Windows, поток около 0,2 Мб/с. Результат - 54 секунды.

Повторил то же, но фильм взял
Цитата: с самого конца

физического диска, поток такой же. Результат - 59 секунд.

alexyc1
Кстати, вот только быстро нашёл более-менее обьективную статью про Ext
http://proubuntu.com.ua/2012/06/05/difrag-linux-fs.html
Но всё равно дефрагментация как бы не нужна ..... потому что система переносит файлы сама.
Что это как не фоновая дефрагментация? Или они так боятся этого слова (признать что и у них фрагментируется)?

alexyc1


Цитата:

Вы создали лишь дополнительный поток,а не фрагментацию.

Этим мы заставили головки метаться через всю поляну.

Итого, при дополнительном потоке всего в 0,5 %, Скорость копирования снизилась на 13 %. При тех же условиях, но когда фильм лежал ближе к папке Windows, потери составили всего около 4 %.


Цитата:

Ваша работа за компом(работу самой ОСи оставим за рамками вопроса) заключается лишь в копировании туда-сюда данных?

Моя работа за компом - это запись около 100 кБ в час. Какая там фрагментация, какой диск, какая система - пофиг.

temp9285
И вот что интересно

Цитата:

В файловых системах Ext2, Ext3 и Ext4 новые файлы равномерно “раскидываются” по всему диску.

О каком последовательном движении головок может идти речь? Пусть файлы размещаются целиком,а не кусками-фрагментами,но они именно РАЗБРОСАНЫ по всему диску даже с логической стороны транслятора,не говоря о физическо их расположении на диске.И никто их не стремится расположить по имени последовательно друг за другом логический сектор за сектором.И начав копировать в несколько потоков точно также,как при фрагментации упадет скорость ,вплоть до пределов механики.

Добавлено:
ZSZ

Цитата:

Этим мы заставили головки метаться через всю поляну.

Метанием голов даже с логической стороны транслятора вы не распоряжаетесь.Тк вам не доступно видение физического заполнения данными секторов

alexyc1

Цитата:

О каком последовательном движении головок может идти речь?

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

temp9285


Цитата:

Опять же, особенно красноглазые фанатики. не в жизнь не признаюются что они испытывают тормоза и т.п.

Я не фанатик, но признаюсь, что в Линуксах файловые операции, сама система, работают по ощущениям заметно медленнее, чем Windows. Может быть этому ещё способствует огромная куча мелких файлов, хаотично разбросанных по логическим дискам.

alexyc1

Цитата:

И никто их не стремится расположить по имени последовательно друг за другом логический сектор за сектором.

Я стремлюсь, потому что это даёт большой выигрыш в скорости при последовательном копировании, архивировании, проверке антивирусом, поиске. Ну и, для кого-то может быть главное - нету шума от hdd.

temp9285

Цитата:

Я разве писал об этом? Где?

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

Добавлено:
ZSZ

Цитата:

Я стремлюсь, потому что это даёт большой выигрыш в скорости при последовательном копировании, архивировании, проверке антивирусом, поиске. Ну и, для кого-то может быть главное - нету шума от hdd.

Похвально,но винт не зависим от ваших пожеланий.Максимум,что можно добится-красивых картинок в "разных ЛЮБИМЫХ программах".

И ещё момент. Когда садишься за чужой комп, заходишь на диск С, в Total Commander делаешь Contrl+B, слышишь хруст французской булки и довольно долго ждёшь результат. Ибо ни дефрагментации, ни оптимизации. Сейчас у себя сделал, результат - через полторы секунды, никакого хруста. Дефрагментировал вчера с оптимизацией по имени.

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