Дефрагментация и проверка HDD

Ответить
 

belikoviv

Старожил

Стаж: 16 лет 4 месяца

Сообщений: 679

belikoviv · 07-Июл-25 17:29 (2 месяца 16 дней назад)

GCRaistlin
есть люди, которые убеждены, что Земля - плоская.
Доказать им обратное - невозможно.
Не тратьте силы
[Профиль]  [ЛС] 

Vivianus

Победитель музыкального конкурса

Стаж: 15 лет 8 месяцев

Сообщений: 6447

Vivianus · 07-Июл-25 17:41 (спустя 12 мин., ред. 07-Июл-25 17:41)

GCRaistlin писал(а):
87968997Просто потому, что копировались в том же порядке, в котором отображаются в Проводнике. Сделайте другую сортировку - и идиллия нарушится
скрытый текст
1) Создаем копии 2 файлов и кладем в папку test:
NTFS File Sector Information Utility.
Copyright (C) Microsoft Corporation 1999. All rights reserved.
\test\01-signum-push_through__original_mix-l4l.flac
$STANDARD_INFORMATION (resident)
$FILE_NAME (resident)
$OBJECT_ID (resident)
$DATA (nonresident)
logical sectors 936170868-936186200 (0x37ccd574-0x37cd1158)
NTFS File Sector Information Utility.
Copyright (C) Microsoft Corporation 1999. All rights reserved.
\test\02-signum-sunny_changes__original_mix-l4l.flac
$STANDARD_INFORMATION (resident)
$FILE_NAME (resident)
$OBJECT_ID (resident)
$DATA (nonresident)
logical sectors 883322314-883334363 (0x34a66dca-0x34a69cdb)
2) В Distrix UltimateDefrag 6 сделаем папку архивной, в конец диска, с сортировкой по имени:
Нумерация кластеров в обратном порядке, потому что отсчет начинается с конца диска:
NTFS File Sector Information Utility.
Copyright (C) Microsoft Corporation 1999. All rights reserved.
\test\01-signum-push_through__original_mix-l4l.flac
$STANDARD_INFORMATION (resident)
$FILE_NAME (resident)
$OBJECT_ID (resident)
$DATA (nonresident)
logical sectors 1278257591-1278272923 (0x4c30a9b7-0x4c30e59b)
NTFS File Sector Information Utility.
Copyright (C) Microsoft Corporation 1999. All rights reserved.
\test\02-signum-sunny_changes__original_mix-l4l.flac
$STANDARD_INFORMATION (resident)
$FILE_NAME (resident)
$OBJECT_ID (resident)
$DATA (nonresident)
logical sectors 1278245541-1278257590 (0x4c307aa5-0x4c30a9b6)
Еще доказательства?
Практическое применение: та же проверка кубитом папок и файлов при запуске. Очевидно, что он проверяет их по порядку, и если файлы идут физически по порядку, диску будет легче, чем если папка 300ГБ будет разбросана по всему диску
[Профиль]  [ЛС] 

GCRaistlin

Стаж: 17 лет 8 месяцев

Сообщений: 6430

GCRaistlin · 07-Июл-25 18:50 (спустя 1 час 8 мин., ред. 07-Июл-25 18:50)

Vivianus писал(а):
87969057В Distrix UltimateDefrag 6 сделаем папку архивной, в конец диска, с сортировкой по имени
Иными словами, заставим ее оба файла физически переместить туда в этом порядке. Неудивительно, что они в результате именно в нем там и расположатся. Окей, беру своё "невозможно" обратно.
Только осмысленность этого действия, в отличие от дефрагментации как таковой, под большим вопросом. Фича ради фичи, пользование которой увеличивает вероятность потери данных. У меня есть несколько битых раздач, которые стали таковыми, судя по всему, из-за того, что на дисках, на которые они качались, было включено NTFS-сжатие, в результате те оказались настолько фрагментированны, что ремуксы при воспроизведении заикались. Я, обнаружив это безобразие, баловаться с NTFS-сжатием перестал, а сжатые диски дефрагментировал. И спустя много времени, при recheck'е, обнаружил, что файлы некоторых раздач на этих дисках - битые. А раздачи к этому моменту уже умерли. С тех пор я на дисках для торрентов отключил фоновую дефрагментацию: лучше целый файл из десяти кусков, чем битый из одного.
Уточню, что виновата была не дефрагментация как таковая, а то, что она производилась на разогнанной машине, при нестандартной частоте PCI/PCIe/памяти. При исправном и работающем штатно оборудовании такого случаться не должно. Но - зачем рисковать?
Возможно, на медленных дисках 90-х это "архивирование в конец диска" в определенных сценариях и давало заметный эффект, но сейчас это точно баловство. И вообще, надо было им запилить сортировку по Last Access Time: это логичнее сортировки по имени. Или уже запилили?
Vivianus писал(а):
87969057проверка кубитом папок и файлов при запуске. Очевидно, что он проверяет их по порядку
Да, по порядку - по порядку кусков. А файлы раздачи в кусках могут быть распределены по-разному.
Не мудрите. Фрагментация - зло, но чрезмерно умная дефрагментация - эло еще большее.
[Профиль]  [ЛС] 

Vivianus

Победитель музыкального конкурса

Стаж: 15 лет 8 месяцев

Сообщений: 6447

Vivianus · 07-Июл-25 19:31 (спустя 41 мин., ред. 07-Июл-25 19:31)

GCRaistlin писал(а):
87969230NTFS-сжатие, в результате те оказались настолько фрагментированны
Был такой же эксперимент с образами виртуалки, выигрыш был 12ГБ зато была жуткая фрагментация этих образов (как и предупреждали в интернете), в итоге убрал сжатие. Сжатие может быть актуально в какихто очень редких случаях, может, когда миллион документов (тектовые файлы ведь сжимаются хорошо). 20 лет назад даже пробовал сжимать системный диск, тогда были интересны все эти эксперименты, твики, сейчас же от компьютера болит голова
[Профиль]  [ЛС] 

Shogal

Старожил

Стаж: 18 лет 3 месяца

Сообщений: 731

Shogal · 08-Июл-25 00:44 (спустя 5 часов, ред. 08-Июл-25 00:44)

Vivianus писал(а):
87968800как дефрагментаторы работают с многоблинновыми дисками, сектор x и следующий за ним сектор y могут находиться один в конце первого билна, второй в начале второго, но наверно разработчики учитывают такие тонкости.
скрытый текст
Мне всегда казалось, что в многоблинных дисках секторы размазаны по блинам по тому же принципу, как в RAID-0 - каждый сектор занимает место на всех блинах сразу в одном и том же физическим месте "стопкой", чтобы блок головок считывал все блины одновременно. Не думаю, что производителям HDD есть физический смысл располагать блины как-то иначе. Дефрагментатору совершенно пофигу, он работает с логической адресацией, а не с физической.
[Профиль]  [ЛС] 

GCRaistlin

Стаж: 17 лет 8 месяцев

Сообщений: 6430

GCRaistlin · 08-Июл-25 05:42 (спустя 4 часа)

Shogal
Вам казалось неправильно.
[Профиль]  [ЛС] 

Shogal

Старожил

Стаж: 18 лет 3 месяца

Сообщений: 731

Shogal · 08-Июл-25 14:52 (спустя 9 часов)

GCRaistlin писал(а):
87970516Shogal
Вам казалось неправильно.
Где можно ознакомиться с информацией по поводу физического расположения секторов относительно блинов у разных производителей?
[Профиль]  [ЛС] 

GCRaistlin

Стаж: 17 лет 8 месяцев

Сообщений: 6430

GCRaistlin · 08-Июл-25 17:16 (спустя 2 часа 24 мин.)

Shogal
Микропрограммой определяется, какой LBA какому физическому сектору соответствует.
[Профиль]  [ЛС] 

Shogal

Старожил

Стаж: 18 лет 3 месяца

Сообщений: 731

Shogal · 08-Июл-25 18:08 (спустя 52 мин., ред. 08-Июл-25 18:08)

GCRaistlin писал(а):
87972081Shogal
Микропрограммой определяется, какой LBA какому физическому сектору соответствует.
Это очевидно, я про то, как они относительно друг друга на блинах располагаются, где об этом почитать? Выбираются же производителем не вразнобой, а так, чтобы минимизировать перемещения головок при линейном чтении.
[Профиль]  [ЛС] 

GCRaistlin

Стаж: 17 лет 8 месяцев

Сообщений: 6430

GCRaistlin · 08-Июл-25 18:30 (спустя 21 мин.)

Shogal
Если последовательные LBA соответствуют последовательным физическим секторам, перемещение головок будет как раз минимальным.
Почитать можно в Википедии, например https://en.wikipedia.org/wiki/Cylinder-head-sector .
[Профиль]  [ЛС] 
 
Ответить
Loading...
Error