Перейти из форума на сайт.

НовостиФайловые архивы
ПоискАктивные темыТоп лист
ПравилаКто в on-line?
Вход Забыли пароль? Первый раз на этом сайте? Регистрация
Компьютерный форум Ru.Board » Hardware » Магнитные носители информации » Обнуление/Восстановление списка плохих секторов в NTFS

Модерирует : Akam1, Dr_StandBy, vertex4

 Версия для печати • ПодписатьсяДобавить в закладки
Страницы: 1 2

Открыть новую тему     Написать ответ в эту тему

FoxBlack09

Full Member
Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
Antech
ну если претенциозно, то да - фрагментация всё равно имеет место
зато количество фрагментов намного более ограничено чем при 4-х а то и 0,5 --килобайтовом кластере
другими словами, что лучше: 64КБ непрерывных данных или 64КБ фрагментированных? а если фрагменты далеки друг от друга? разницу уловили?
поверьте - разница в средней скорости доступа колоссальная - проверено на опыте
я имею в виду тот факт, что на считывание порции данных при макс. разм. кластера голове нужно меньше прыжков(на которые уходит порядочно времени) с трека на трек, следовательно среднее время доступа меньше, скорость выдачи данных выше, износ БМГ ниже, плюсы со всех сторон... ну кроме разве что омрачает радость мелкое файло, на котором большие потери из за кластерной незаполненности..., но это дело решается по возможности архивацией или NTFS компрессией
а поподробнее нельзя ли об
Цитата:
а самые мелкие вообще в FILE Records живут
?

Всего записей: 512 | Зарегистр. 01-04-2009 | Отправлено: 22:16 01-04-2010 | Исправлено: FoxBlack09, 23:54 01-04-2010
Antech

Silver Member
Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
FoxBlack09

Цитата:
64КБ непрерывных данных или 64КБ фрагментированных?

А почему они будут фрагментированы? ИМХО просто размер экстента (в кластерах) будет разный, а размер фрагмента (в секторах, байтах) будет один и тот же (сколько поместится в данную дырку, т.е. область пустого пространства).
(Я никаких опытов не проводил, чисто теоретически. У меня везде кластер 4 КиБ на NTFS. Я не раз читал на iXBT мнения MS MVP, что на NTFS делать нестандартный размер кластера смысла не имеет, и что это неоднократно обсуждалось.)
 

Цитата:
поподробнее

Почитайте про резидентные атрибуты, вроде тут есть: http://www.insidepro.com/kk/044/044r.shtml

Всего записей: 3120 | Зарегистр. 26-12-2006 | Отправлено: 09:15 02-04-2010
FoxBlack09

Full Member
Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
Antech
вот вам пример:
представьте себе файл в 128 КБ лежащий в 2х экземплярах на разных партициях, у 1й размер кластера 64 КБ у второй 4 КБ, данные максимально фрагментированы, помним что кластер для ФС это неделимая единица, т.е. информация в нём расположена строго последовательно (нефрагментирована), для того чтобы считать это файл целиком голове физически нужно будет всего лишь раз перескочить на следующий фрагмент (на разделе с разм. кл.64КБ), тогда как на второй партиции эта же задача потребует 32! операции позиционирования головы. Логично?

Всего записей: 512 | Зарегистр. 01-04-2009 | Отправлено: 13:55 02-04-2010
Antech

Silver Member
Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
FoxBlack09
А, ну с такой точки зрения - да. Но фрагментация при это должна быть просто космическая...

Всего записей: 3120 | Зарегистр. 26-12-2006 | Отправлено: 14:04 02-04-2010
FoxBlack09

Full Member
Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
Antech
а вы попробуйте не дефрагментировать эдак годик раздел, а файло туда-сюда несколько раз частями, фрагментация иногда ужасающая, не поддающаяся никаким законам логики, не знаю - то ли невозможно иначе из-за каких-то мне непонятных далеко идущих соображений, либо ребята из микрософт не особо старались...
 
проверено на опыте 7 лет работы - результаты ошеломляющие
правда сравнивал больше минимальный и максимальный размер кластера в работе, но есть серьёзные результаты и по 4 кб-вым кластерам, жаль только что от 8 и далее КБ нельзя применять НТФС Компрессию, на 64 КБ она была бы для мелкого файлА в самый раз

Всего записей: 512 | Зарегистр. 01-04-2009 | Отправлено: 15:10 02-04-2010 | Исправлено: FoxBlack09, 15:48 02-04-2010
Antech

Silver Member
Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
FoxBlack09
При такой сильной фрагментации, наверное, есть смысл периодически дефрагментить.
У меня еще не возникало вопросов с фрагментацией. Некоторые файлы могут иметь десятки тысяч фрагментов, это да, но большинство - как обычно: один, два, несколько фрагментов...
 
P.S.
Ну и оффтоп мы тут развели !

Всего записей: 3120 | Зарегистр. 26-12-2006 | Отправлено: 23:02 03-04-2010
FoxBlack09

Full Member
Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
Antech
 

Цитата:
Ну и оффтоп мы тут развели !

что правда, то правда
 

Цитата:
При такой сильной фрагментации, наверное, есть смысл периодически дефрагментить

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

Всего записей: 512 | Зарегистр. 01-04-2009 | Отправлено: 18:11 07-04-2010 | Исправлено: FoxBlack09, 15:07 12-04-2010
FoxBlack09

Full Member
Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору

Всего записей: 512 | Зарегистр. 01-04-2009 | Отправлено: 02:20 08-04-2010 | Исправлено: FoxBlack09, 15:08 12-04-2010
FoxBlack09

Full Member
Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
Antech
был занят какое-то время, и вот вернулся к вопросу о $BadClus:

Цитата:
03 AF 96 07 - 31 02 AF 96 07 - 01 02 - 12 B5 00 04 - 00

почему красные цифры расположены именно в таком порядке?
разве не так должно быть:
03 AF 96 07 - 31 02 AF 96 07 - 01 02 - 21 B5 00 04 - 00
?
ведь схема такая (насколько я понял):
величина размера под смещение (полубайт), величина размера под фрагмент (полубайт), размер фрагмента(байты, биг ендиан), размер смещения (байты, биг ендиан)...
или я что-то недопонял?
 
и ещё вопрос: Зачем под последнее смещение выделено аж 2 байта? (зачем нужны зелёные нули?)
 

Всего записей: 512 | Зарегистр. 01-04-2009 | Отправлено: 13:46 12-04-2010 | Исправлено: FoxBlack09, 16:16 12-04-2010
Antech

Silver Member
Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
FoxBlack09

Цитата:
разве не так должно быть

Я взял ранлист из Вашего "дампа" (ну т.е. из ASCII Hex). Сейчас проверил - там именно так (12 B5 00 04). Поэтому вопрос как должно быть в данном случае не стоит: мы имеем некий ранлист в ASCII Hex и это исходные данные.
 

Цитата:
величина размера под смещение (полубайт), величина размера под фрагмент (полубайт), размер фрагмента(байты, биг ендиан), размер смещения (байты, биг ендиан)

Да.
 

Цитата:
Зачем под последнее смещение выделено аж 2 байта? (зачем нужны зелёные нули?)

Под смещение выделен один байт (04), таков данный ранлист, а под размер B5 00 и зачем здесь 2 байта ХЗ (но такое бывает, это у M$ надо спросить). Но если рассматривать экстент 21 B5 00 04, то нули уже не лишние (смещение 0400h).

Всего записей: 3120 | Зарегистр. 26-12-2006 | Отправлено: 10:45 13-04-2010
FoxBlack09

Full Member
Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
Antech
вот что мне выдал Runtime's Disk Explorer for NTFS v3.66:
 
03:AF9607*31:02AF9607*01:02*12:B50004
1st run: x796AF (497327) sparse (=empty) clusters
2nd run: x0002 (2) clusters starting at x000796AF (497327)
3rd run: x0002 (2) sparse (=empty) clusters
4th run: x00B5 (181) clusters starting at x000796B3 (497331)
 

Цитата:
и зачем здесь 2 байта ХЗ
помоему это несущественные нюансы работаы драйвера фс
практически (вероятнее всего) можно было бы выделить всего 1 байт
сегодня-завтра закончит работу chkdsk  на более большом объёме с большим количеством бэдов и тогда будет "в чём порыться"
если интересно сообщу любопытные результаты (если будут)
 
есть ещё один вопрос: как уместить вручную выстроенную цепочку в $BadClus если она выходит за пределы файла?
ситуация такова: 23 равномерно распределённых плохих диапазона по 4-6 ГБ на разделе объёмом 698Гб (голова сдохла, а отключить невозможно - проверяли)
 
 

Цитата:
09:24 02-09-2009
Соответственно, ранлист такой: 01 05 11 01 05 14 XX XX XX XX 06 (здесь XX XX XX XX - размер раздела минус 7 кластеров).  

Помоему у вас ошибка в примере - для спарс-фрагмента не нужно указывать смещение, кроме того не минус 7, а минус 6
P.S.: случайно заметил... если в чём не прав - буду рад если поправите

Всего записей: 512 | Зарегистр. 01-04-2009 | Отправлено: 17:13 14-04-2010 | Исправлено: FoxBlack09, 22:31 14-04-2010
VinniJones

Newbie
Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
Апну тему. Сбросить отметку о  испорченном секторе можно еще проще - в программе CHKDSK есть опция  /B при котором CHKDSK сбрасывает ранее отмеченные поврежденные (bad) секторы и перепроверяет их.

Всего записей: 3 | Зарегистр. 10-04-2007 | Отправлено: 00:57 06-09-2012
VasyK



Junior Member
Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
VinniJones
 
Стоит отметить что ключь /B работает только с CHKDSK от WINDOWS 7

Всего записей: 40 | Зарегистр. 07-02-2006 | Отправлено: 21:37 06-09-2013
rivbroder

Newbie
Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
Может есть софт, умеющий редактировать $badclus ? Т.е. который умеет всю эту логику, я бы хотел добавлять/удалять области на свое усмотрение.

Всего записей: 5 | Зарегистр. 07-10-2011 | Отправлено: 11:15 27-05-2017 | Исправлено: rivbroder, 11:34 27-05-2017
RomanKotel



Junior Member
Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
DFSee 14.6 FDISK, display & analysis.
DOS32, OS2, Win-NT and Linux version.
Shows partition-tables and bootsectors.
Collects UNFDISK type recovery info.
Supports MBR and GPT style partitions.
Displays HPFS/NTFS/FAT/JFS/EXT2/3/4 and
some ReiserFS, XFS and HFS structures.
Check allocation integrity and display.
Allocation maps for disks and partitions
Fast CLONING and IMAGING of disks and
partitions. CHKDSK, File-recovery for
HPFS, JFS, NTFS, FAT, EXFAT and EXT2/3/4.
RESIZE/Expand on FAT, HPFS and NTFS.
MOVE or COPY any filesystem/partition.
Now with a user-friendly menusystem!
Includes HEX sector editor/disassembler
and an interactive directory browser
with file edit/view and copy functions.
Allows access to compressed (IMZ) images
and VirtualBox dynamic disk (VDI) images
(c) 2017 Jan van Wijk - Fsys Software
www.dfsee.com
 
Полнофункциональная триальная версия позволяет обнулить файл $BadClus одной командой:
File -> Open Single Partition ->
Mode=NTFS -> Reset bad sectors

Всего записей: 35 | Зарегистр. 19-06-2008 | Отправлено: 07:30 05-07-2017 | Исправлено: RomanKotel, 07:40 05-07-2017
Открыть новую тему     Написать ответ в эту тему

Страницы: 1 2

Компьютерный форум Ru.Board » Hardware » Магнитные носители информации » Обнуление/Восстановление списка плохих секторов в NTFS


Реклама на форуме Ru.Board.

Powered by Ikonboard "v2.1.7b" © 2000 Ikonboard.com
Modified by Ru.B0ard
© Ru.B0ard 2000-2024

BitCoin: 1NGG1chHtUvrtEqjeerQCKDMUi6S6CG4iC

Рейтинг.ru