2

В настоящее время я работаю

sudo mkfs.msdos -c -F 32 /dev/sdg1

Сколько времени это займет, примерно? Это диск USB 2.0 объемом 250 ГБ. Нижний предел, конечно, составляет 2 * 250GB / 480 Mbit/s ~ 8400s (он должен записывать и читать весь диск), но я боюсь, что это может быть медленнее.

У кого-нибудь есть опыт из первых рук?

Просто чтобы сделать это сообщение более привлекательным, позвольте мне печатать быстро и медленно: как быстро оно будет? как медленно?

4 ответа4

3

Похоже, это сработало для вас, но для записи ....

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

Я бы предложил использовать dmesg, чтобы увидеть, есть ли у него проблемы, если он кажется слишком медленным.

Кстати, почему вы думаете, что это должно записать на весь диск? На странице руководства mkfs.vfat(1), где выполняется деструктивный тест, я не вижу, программа badblocks(1) выполняет тест только для чтения по умолчанию.

И FWIW, у меня mkfs -c заняло более 24 часов (IIRC) на диске SCSI, который был ~ 4 ГБ.

1

Я запустил badblocks /dev/sdg1 на жестком диске емкостью 1 ТБ через USB 2.0, что, в соответствии с man-страницей, будет выполнять команда mkfs.* -c . Размер тестового блока по умолчанию составляет 1 КБ, и он выполняет тест только для чтения по умолчанию.

Через 24 часа я прервал его: он проверил только 120 ГБ и обнаружил более 10000 поврежденных блоков. Как отметил @nvram, он может быть очень медленным, когда у вас действительно плохие блоки.

Так что для вашего жесткого диска это может занять более 2 дней.

0

Потребовалось не намного больше, чем нижний предел. К сожалению, я не наблюдал за этим, но более или менее это было.

0

Спасибо за советы! Я хотел бы поделиться своим опытом устранения неполадок с не загружаемым компьютером Ubuntu моего друга. Я загрузил компьютер с Xubuntu на USB-носитель. После использования команды e2fsck раздел жесткого диска можно было смонтировать, а файлы можно было извлечь с жесткого диска (и мой друг был счастлив :).

Сообщения об ошибках сбоя жесткого диска могут быть видны в кольцевом буфере ядра (и могут быть напечатаны с помощью команды dmesg ):

[78748.550250] ata1.00: status: { DRDY ERR }
[78748.550253] ata1.00: error: { UNC }
[78748.572323] ata1.00: configured for UDMA/100
[78748.572341] ata1: EH complete
[78753.326771] ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x0
[78753.326777] ata1.00: BMDMA stat 0x25
[78753.326782] ata1.00: failed command: READ DMA
[78753.326790] ata1.00: cmd c8/00:08:48:0b:44/00:00:00:00:00/e4 tag 0 dma 4096 in
[78753.326792]          res 51/40:08:48:0b:44/40:00:04:00:00/e4 Emask 0x9 (media error)

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

ubuntu@ubuntu:~$ sudo mke2fs -c -t ext4 /dev/sda1
...
...
...
Checking for bad blocks (read-only test):  18.07% done, 2:54:19 elapsed
 18.20% done, 8:14:58 elapsed
 18.20% done, 8:22:01 elapsed
^[[B20% done, 8:35:08 elapsed

Проверка блоков настолько медленная, что я думал, что выполнение застряло. Это почти остановилось около 18%, и казалось, что он никогда не достигнет конца. Но dmesg показал, что блок пошаговый и проверка блока продолжается. Если с блоками все в порядке, проверка блоков выполняется быстрее, и все выполнение заняло около 24 часов. Размер жесткого диска составляет 40 ГБ.

Всё ещё ищете ответ? Посмотрите другие вопросы с метками .