LINUX.ORG.RU

Битые секторы

 ,


0

1

Я сейчас делаю проверку на битые секторы на старом жд. Битые секторы записываются в файл «badblock». После форматирования жд, этот файл всё ещё можно будет использовать для пометки битых секторов, чтобы система их игнорировала? Просто проверка идёт уже 20 часов (и походу будет идти ещё несолько дней) и ой как не хотелось бы её повторять снова.
И немного подробее. В файле badblock просто записываются битые сектора, по одному на строку:
51234564
51234565
51234566
И т.д.
После форматирования нумерация секторов остаётся такой же? То есть если я выполню

e2fsck -l /home/user/badblock /dev/sda2
после форматирования, заблокируются именно те сектора, которые надо?

badblock запущен на /dev/sda2 или /dev/sda?

И, лучше этот винт не использовать, если у него полезли кучи битых секторов, значит на нём уже куча realloc — медленый доступ, да и протянет он недолго.

mky ★★★★★
()
Ответ на: комментарий от mky

Сначала на /dev/sda1 в файл badblock. Затем на /dev/sda2 в файл badblock2. Я не знал, что можно для всего диска запустить. На /dev/sda1 битых секторов не найдено. Я куплю новый жд, но пока хотелось бы продлить жизнь этого.

seprik_lo
() автор топика
Ответ на: комментарий от seprik_lo

То, что для /dev/sda2 это хорошо, это подходит для e2fsck. Размер блока 4096 указывали? Точнее нужно брать размер блока из вывода ″tune2fs -l″, но он редко отличается от 4 кбайт.

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

И я не уверен, что это хорошая идея кормить список плохих секторов команде e2fsck, если на ФС есть файлы...

mky ★★★★★
()
Ответ на: комментарий от mky

Разве ext2 будет орентироваться на логические номера 4К-блоков? Это должно быть важно, dd и очевидно badblock обычно оперирует совместимыми со старым стандартом 512Б-блоками.

kirill_rrr ★★★★★
()

Во первых - контроллер попытается отремапить битые векторы на живые из резервной области. Обычно ошибки чтения недостаточно для этого, надо попробовать запись. Лучше проверить ещё на задержки.
Если биты большие области, то лучше оперировать LVM, только метаданые там не хранить.
Карту читаемости можно построить GNU ddrescue, приблизительно он может быстрее диапазоны выстроить, но там другой формат.
Если диск уже стучит и скрипит, то лучше его даже не выключать лишний раз - может запарковаться и переклинить.

boowai ★★★★
()
Ответ на: комментарий от kirill_rrr

Разве ext2 будет орентироваться на логические номера 4К-блоков?

Посмотрите список процессов при запуске ″mke2fs -c″, найдите там badblocks и посмотрите с какими ключами вызывает его mke2fs. Только устройство должно быть достаточно большим, чтобы были 4к блоки файловой системы.

очевидно badblock обычно оперирует совместимыми со старым стандартом 512Б-блоками

Совсем не очевидно. man badblocks

-b block-size
Specify the size of blocks in bytes. The default is 1024.

Important note: If the output of badblocks is going to be fed to the e2fsck or mke2fs programs, it is important that the block size is properly specified, since the block numbers which are generated are very dependent on the block size in use by the filesystem.

mky ★★★★★
()
Ответ на: комментарий от mky

Ещё ни разу не встречал диска, где бэдблок использовал «The default is 1024»

Посмотрите список процессов при запуске ″mke2fs -c″, найдите там badblocks и посмотрите с какими ключами вызывает его mke2fs. Только устройство должно быть достаточно большим, чтобы были 4к блоки файловой системы.

Никто там никого не вызывает. Есть стандарт, пришедший ещё с дискет - логический блок блочных устройств 512 байт. И не важно, какими физическими блоками оперирует контроллер 256Гб SSD, для совместимости со всеми остальными с точки зрения драйвера диска в ОС это будет 512 байт. Но скажем ntfs при этом объеденяет блоки в 4К кластеры. ext2 обычно делает так же.

kirill_rrr ★★★★★
()
Последнее исправление: kirill_rrr (всего исправлений: 1)

Обрати внимание, что бэды идут подряд. Это, на самом деле, один «физический» блок, которым минимально оперирует сам диск. Нужно было запускать badblock параметром -b соответствующим твоему диску. Тогда и проверка прошла бы в разы быстрее. Если сейчас посмотреть в SMART, то, вангую, там сейчас 1 Pending сектор. Нужно в него (номер узнаётся через badblock) произвести запись (через dd или тот же badblock с сотв. офсетом). Тогда диск его или заремапит (Reallocated Sectors увеличится на 1) или, вообще, уберёт из списка подозрительных, если запись пройдёт успешно. Паниковать по этому поводу не стоит. Бэды - нормальная рабочая практика. Истерички, которые сходу советуют менять диск - нубасы.

anonymous
()
Ответ на: комментарий от kirill_rrr

Ещё ни разу не встречал

Классическое УМВР во все поля. Если вызывать badblocks с дефолтными параметрами, то бэды всегда идут группами по 4/8 штук подряд.

anonymous
()
Ответ на: комментарий от mky

Совсем не очевидно

Относительно недавно (годы) дефолт сменили с 512 на 1024. Не понятно, почему не 4096, т.к. это и есть сейчас дефолт для большинства дисков.

anonymous
()
Ответ на: комментарий от anonymous

Херня, ща бы смарту верить. Это всё конечно ерунда, но если у тебя есть что-то ценное там, то уже нет, и бэкапы тебя не спасут.

anonymous
()
Ответ на: комментарий от anonymous

Херня, ща бы смарту верить

Балбес, на диске есть бэды. И в SMART это отражено со 100% вероятностью. И сейчас это Pending сектор(ы), а нужно, чтобы они или исчезли или перешли в Reallocated, чтобы можно было продолжать пользоваться диском. Для такой ситуации достаточно просто отрубить диск по питанию «на горячую», по сути - софтовая ошибка.

anonymous
()
Ответ на: комментарий от anonymous

Беды которые есть на диске в смарте не указаны, это так задумано производителем. И ОП нигде не говорил, что у него там только pending или 1 дорожка осыпалась, пыль от неё и дрочева бэдблоком вполне вероятно разнесла всё что там оставалось (и этого не будет в смарте).

anonymous
()
Ответ на: комментарий от anonymous

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

anonymous
()
Ответ на: комментарий от anonymous

1 дорожка осыпалась, пыль от неё и дрочева бэдблоком вполне вероятно разнесла всё что там оставалось (и этого не будет в смарте)

Всё ясно, кукаретик.

anonymous
()
Ответ на: комментарий от anonymous

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

anonymous
()

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

Лучше прекрати проверку и сначала покажи SMART диска. Потом badblocks -w на всё устройство, а не на отдельные ФС, если резервная область ещё есть - это ускорит процесс. А занесение бэдов в файл - это уже последняя инстанция перед окончательной смертью винта, когда резервная область у него закончилась.

Deleted
()
Ответ на: комментарий от kirill_rrr

Логический сектор диска 2-4К. но физически это 4-8 сектора

anonymous
()
Ответ на: комментарий от kirill_rrr

Ещё ни разу не встречал диска, где бэдблок использовал «The default is 1024»

Запуск ″badblocks -v /dev/hdc", диск размером 20 Гбайт ( модель IC35L020AVVA07):

Checking for bad blocks in read-only mode
From block 0 to 20094480
Запуск ″badblocks -v /dev/sdb", диск размером 1 Тбайт (модель WDC WD10EARS):
Checking blocks 0 to 976762584
Checking for bad blocks (read-only test):          104384/      976762584

Тут очевидно, что badblocks тестирует блоками размером 1 кбайт.

Давайте ваш вывод badblocks и модели жёстких дисков.

Никто там никого не вызывает.

Вы придираетесь к словам, типа «запускает, а не вызывает» или вобще не поняли, что я попросил? Вот фрагмент листинга ″ps axfuwww″ на команду ″mke2fs -c /dev/sda2″:

root     14682  0.0  0.1   5960  2364 pts/4    S    Sep14   0:01                
      |           \_ -bash
root     30770  0.0  0.0   4780  1252 pts/4    S+   21:06   0:00                      |               \_ mke2fs -c /dev/sda2
root     30772  3.7  0.0   4648  1036 pts/4    D+   21:06   0:00                      |                   \_ badblocks -b 4096 -X -s /dev/sda2 1313312

Как и написано в man, mke2fs для проверки устройства скастовал badblocks и не забыл тому указать, что нужно выдавать номера блоков для размера 4 кбайт.

mky ★★★★★
()
Ответ на: комментарий от anonymous

Не уверен насчёт именно 512 байт, ИМХО, раньше badblocks по умолчению брал размер блока через ioctl BLKBSZGET. В моём древнем man'e 2001 года вобще не написано про размер блока по умолчанию.

mky ★★★★★
()
Ответ на: комментарий от kirill_rrr

Advanced format физически 4к, а не 512 — сегодня диски есть и такие и такие, у ext по-моему нет понятия кластера, но логически оно может быть любого размера (по-моему даже независимо от того что там думает диск), будут ограничения на максимальный размер фс. Чаще всего с этим сталкиваешься во всяких squashfs и подобном.

У ssd по-моему значительно больше блоки и файл в 1 байт будет занимать весь блок, да?

anonymous
()

Какая разница какой сектор ? Форматнуть в фс и задать 4 килобайта. Потом натравить пометку бэдблоков

ism ★★★
()
Ответ на: комментарий от mky

Сейчас на двух 1Тб дисках и одном 160Гб бэдблок показал 1К блоки. В последние 2 года тестировал несколько сдохших флешек и один умерший ssd. Не проверял размер блока на ssd, но проверял у флешек - думал сделать блэклист ext2, и там точно были блоки 512.

И другой инструмент, parted, на одном из моих теребейтников:

(parted) print                                                            
Model: TOSHIBA MQ01ABD100 (scsi)
Disk /dev/sdc: 1000GB
Sector size (logical/physical): 512B/512B
Partition Table: msdos
Disk Flags: 

Number  Start   End     Size    Type     File system     Flags
 1      1049kB  12,9GB  12,9GB  primary  linux-swap(v1)
 2      12,9GB  1000GB  987GB   primary  ext4
Бэдблок считает, что блоки диска 1К, партед что 512Б, независимо от того, что считает контроллер диска, партед может разметить раздел со смещением 512Б если указать номера блоков, и файловой системе придётся расположиться на таком разделе.

kirill_rrr ★★★★★
()
Последнее исправление: kirill_rrr (всего исправлений: 1)
Ответ на: комментарий от anonymous

По флешкам и ssd вообще сложно. На хабре была хорошая статься про слой ftl на них, суть вроде в том, что только разработчики чипа знают, какими на самом деле блоками будет оперировать флэш-память. Но со стороны ОС это должно быть блочное устройство со стандартным размером блока. Вроде как чип оптимизируют под быструю работу с ntfs, т.е. под 4К блоки, но это не обязательно так.

kirill_rrr ★★★★★
()
Ответ на: комментарий от ism

Форматнуть в фс и задать 4 килобайта.

Я забыл, вот результат:

> zpool status store
  pool: store
 state: ONLINE
status: One or more devices are configured to use a non-native block size.
	Expect reduced performance.
action: Replace affected devices with devices that support the
	configured block size, or migrate data to a properly configured
	pool.
  scan: resilvered 560G in 0 days 16:19:13 with 0 errors on Sat Oct  6 16:11:22 2018
config:

	NAME                              STATE     READ WRITE CKSUM
	store                             ONLINE       0     0     0
	  raidz1-0                        ONLINE       0     0     0
	    gpt/store_zfs_S23TJDSZ305854  ONLINE       0     0     0
	    gpt/store_zfs_S23TJDSZ305881  ONLINE       0     0     0
	    ada1                          ONLINE       0     0     0  block size: 512B configured, 4096B native

errors: No known data errors

iZEN ★★★★★
()
Ответ на: комментарий от iZEN

Размер блока всегда надо ставить принудительно, так как некоторые фс пытаются детектить и ошибаются

Достаточно всегда ставить 4 килобайт

ism ★★★
()
Последнее исправление: ism (всего исправлений: 1)
Ответ на: комментарий от iZEN

Благодаря этому добру твой комп тыквится до уровня хуже 4/4 хасвела, лол.

anonymous
()
Ответ на: комментарий от iZEN

Ты же понимаешь, что нормальная зфс только в солярке, там что-то фундаментальное на уровне ядра?

anonymous
()
Ответ на: комментарий от anonymous

Конечно, понимаю. Солярка божественна, а мы её слуги.

iZEN ★★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.