вывода

0

2

Столкнулся с такой проблемой, при попытке запустить gparted я получаю ошибку

Ошибка синхронизации или закрытия файлов /dev/sdc: Ошибка ввода/вывода<<<

ссд живое, ибо реагирует на команду hdparm /dev/sdc

/dev/sdc: multcount = 16 (on) IO_support = 1 (32-bit) readonly = 0 (off) readahead = 256 (on) geometry = 15566/255/63, sectors = 250069680, start = 0<<<

реакция на fdisk -l /dev/sdc

Диск /dev/sdc: 119,2 GiB, 128035676160 байт, 250069680 секторов Единицы: секторов по 1 * 512 = 512 байт Размер сектора (логический/физический): 512 байт / 512 байт Размер I/O (минимальный/оптимальный): 512 байт / 512 байт<<<

реакция на dd if=/dev/zero of=/dev/sdс bs=512 count=1

1+0 записей получено 1+0 записей отправлено 512 bytes copied, 0,000143093 s, 3,6 MB/s<<<

Как решить проблему ? Хотя бы банально создать таблицу разделов, ибо из-за ошибки даже это не могу сделать

Ссылка

←	Некорректно работают кнопки трекпоинта

Bluetooth-наушники

→

Через fdisk попробуй разделы создать.

Kron4ek ★★★★★
(31.01.22 21:20:07 MSK)

fdisk или cfdisk или parted

Clockwork ★★★★★
(31.01.22 21:23:46 MSK)

Ответ на: комментарий от Kron4ek 31.01.22 21:20:07 MSK

то же самое

Таблица разделов была изменена. Вызывается ioctl() для перечитывания таблицы разделов. /dev/sdc: не удалось закрыть устройство: Ошибка ввода/вывода<<<

ran1dom
(31.01.22 21:28:15 MSK) автор топика

Ответ на: комментарий от ran1dom 31.01.22 21:28:15 MSK

А в dmesg есть какие-нибудь ошибки касательно /dev/sdc?

$ dmesg | grep sdc

Kron4ek ★★★★★
(31.01.22 21:32:36 MSK)
Последнее исправление: Kron4ek 31.01.22 21:32:58 MSK (всего исправлений: 1)

Ответ на: комментарий от Kron4ek 31.01.22 21:32:36 MSK

[ 3041.489728] sd 3:0:0:0: [sdc] tag#0 FAILED Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE [ 3041.489732] sd 3:0:0:0: [sdc] tag#0 Sense Key : Illegal Request [current] [ 3041.489735] sd 3:0:0:0: [sdc] tag#0 Add. Sense: Unaligned write command [ 3041.489739] sd 3:0:0:0: [sdc] tag#0 CDB: Write(10) 2a 00 00 00 5e b8 00 00 48 00 [ 3041.489743] blk_update_request: I/O error, dev sdc, sector 24248 op 0x1:(WRITE) flags 0x800 phys_seg 9 prio class 0 [ 3041.489749] Buffer I/O error on dev sdc, logical block 3031, lost async page write [ 3041.489758] Buffer I/O error on dev sdc, logical block 3032, lost async page write [ 3041.489761] Buffer I/O error on dev sdc, logical block 3033, lost async page write [ 3041.489763] Buffer I/O error on dev sdc, logical block 3034, lost async page write [ 3041.489766] Buffer I/O error on dev sdc, logical block 3035, lost async page write [ 3041.489768] Buffer I/O error on dev sdc, logical block 3036, lost async page write [ 3041.489771] Buffer I/O error on dev sdc, logical block 3037, lost async page write [ 3041.489773] Buffer I/O error on dev sdc, logical block 3038, lost async page write [ 3041.489776] Buffer I/O error on dev sdc, logical block 3039, lost async page write [ 3041.509462] sd 3:0:0:0: [sdc] tag#0 FAILED Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE [ 3041.509467] sd 3:0:0:0: [sdc] tag#0 Sense Key : Illegal Request [current] [ 3041.509471] sd 3:0:0:0: [sdc] tag#0 Add. Sense: Unaligned write command [ 3041.509476] sd 3:0:0:0: [sdc] tag#0 CDB: Write(10) 2a 00 00 00 5f 00 00 01 98 00 [ 3041.509482] blk_update_request: I/O error, dev sdc, sector 24320 op 0x1:(WRITE) flags 0x800 phys_seg 51 prio class 0 [ 3041.509487] Buffer I/O error on dev sdc, logical block 3040, lost async page write

ran1dom
(31.01.22 21:37:51 MSK) автор топика

Ответ на: комментарий от ran1dom 31.01.22 21:37:51 MSK

проверить шлейф, обновить прошивку, отправить на помойку/в гарантию

Bloody ★★
(31.01.22 21:39:52 MSK)

Ответ на: комментарий от Clockwork 31.01.22 21:23:46 MSK

та же проблема

Предупреждение: Ошибка синхронизации или закрытия файлов /dev/sdc: Ошибка ввода/вывода Повторить/Retry/Игнорировать/Ignore?

ran1dom
(31.01.22 21:44:24 MSK) автор топика

Ссылка

Ответ на: комментарий от Bloody 31.01.22 21:39:52 MSK

брось, какая помойка, ссд вчера ещё работало

ran1dom
(31.01.22 21:45:04 MSK) автор топика

Ответ на: комментарий от ran1dom 31.01.22 21:45:04 MSK

у меня OCZ так и откидывались, не одна и не две, и даже не три

Bloody ★★
(31.01.22 21:53:48 MSK)

Ссылка

Ответ на: комментарий от ran1dom 31.01.22 21:37:51 MSK

Кабель проверь. У меня бывало отходил, были похожие ошибки.

Kron4ek ★★★★★
(31.01.22 22:05:10 MSK)

Ссылка

Ответ на: комментарий от Kron4ek 31.01.22 21:32:36 MSK

так же стоковый менеджер дисков такую ошибку выдаёт ошибку

ran1dom
(31.01.22 22:06:58 MSK) автор топика

Ответ на: комментарий от ran1dom 31.01.22 22:06:58 MSK

dd if=/dev/zero of=/dev/sdc bs=512 count=2048
dd if=/dev/sdc of=/dev/null bs=512 count=2048

firkax ★★★★★
(31.01.22 22:38:20 MSK)

Ссылка

реакция на dd

Реакция на dd без oflag=direct говорит только о том что вы писали в page cache а не на диск.

Вообще ваш диск уже тыква. Попробуйте сделать ему blkdiscard /dev/sdc

Nastishka ★★★★★
(01.02.22 02:22:58 MSK)

Как правильно копировать вывод терминала

Vsevolod-linuxoid ★★★★★
(01.02.22 03:33:20 MSK)

Ссылка

Ответ на: комментарий от ran1dom 31.01.22 21:45:04 MSK

Инджой ёр модный ССД — они именно так и дохнут, без предупреждения, иногда посреди работы.

И, главное, на ЛОРе полно баритонов, звездящих о том, как «устарели» HDD…

anonymous
(01.02.22 08:50:07 MSK)

Ссылка

Ответ на: комментарий от Nastishka 01.02.22 02:22:58 MSK

раз уж вы заговорили о флаге direct

можете пояснить, как =правильно= пользоваться этой опцией для ddrescue? (в мане или официальном GNU Manual информация очень сухая)
особенно интересует вопрос использования

--direct (       use direct disc access for input file)

зачем обращаться напрямую к битому диску? (типичный кейс ddrescue - копирование битого диска на здоровый/новый)

anonymous
(01.02.22 19:22:17 MSK)

Ответ на: комментарий от anonymous 01.02.22 19:22:17 MSK

Чтобы ядро не умничило и не объединяло запросы в один. Чтобы диск получал команды читать по одному сектору. Не факт что поможет, но бывает, что НЖМД зависает при обращении к битому сектору и,отслеживать создание файлов в директории auditd если читать по 16 секторов разом, то и соседние сектора от битого не прочитаются.

Ну и не зачем заполнять дисковый кеш данными, которые больше никакому приложению не нужны. Может система не только ddrescue выполняет.

mky ★★★★★
(01.02.22 19:55:44 MSK)

Ответ на: комментарий от mky 01.02.22 19:55:44 MSK

спасибо
со вторым доводом согласен сразу на 200%
по первому доводу - вы немного противоречите вот этому вот пункту (ну или я неправильно понял что-то)

       -c, --cluster-size=<sectors>
              sectors to copy at a time [128]

anonymous
(01.02.22 20:04:15 MSK)

hakavlad ★★★
(01.02.22 20:18:16 MSK)

Ссылка

Ответ на: комментарий от anonymous 01.02.22 20:04:15 MSK

Исходники ddrescue не смотрел. Как я понимаю, размер кластера определят кол-во секторов, которые dd попросит от ядра. А само ядро, без флага O_DIRECT, может попросить от НЖМД больше секторов — read ahead, может выравнивание, может ещё что.

mky ★★★★★
(01.02.22 20:38:03 MSK)

Ответ на: комментарий от mky 01.02.22 20:38:03 MSK

ок, ещё раз спасибо
про /sys/block/sd?/queue/read_ahead_kb знал уже раньше
я тоже сырцы не смотрел, просто думал, что упускаю что-то очевидное. Диск буду восстанавливать впервые, поэтому хотелось заранее подготовиться, получить опытную инфу, а не только google/archwiki

anonymous
(01.02.22 20:54:23 MSK)

Ссылка

Ответ на: комментарий от anonymous 01.02.22 19:22:17 MSK

Обычно при чтении делается так называемый readahead который как правило порядка 64/128KB. Если у вас побит один-два сектора, которые нынче, как известно, 4KB (а у меня были такие диски - если не делать перезапись, через некоторое время не читаются некоторые единичные сектора), то вы получаете ошибку чтения для 16 секторов. С флагом direct читается 4K что означает что вы не прочтете только то что не читается

Nastishka ★★★★★
(02.02.22 00:55:21 MSK)
Последнее исправление: Nastishka 02.02.22 00:55:59 MSK (всего исправлений: 1)

Ответ на: комментарий от Nastishka 02.02.22 00:55:21 MSK

не прошло и полгода, зайка моя!

ну а вообще спасибо - твои слова подтверждают слова mky

anonymous
(02.02.22 01:18:56 MSK)

Ссылка

Ответ на: комментарий от mky 01.02.22 19:55:44 MSK

Чтобы ядро не умничило и не объединяло запросы в один. Чтобы диск получал команды читать по одному сектору.

Мне кажется - Вы сильно упрощаете, и задумку, и реализацию, и ограничения…

bugfixer ★★★★★
(02.02.22 08:50:56 MSK)

Ответ на: комментарий от bugfixer 02.02.22 08:50:56 MSK

Возможно. Дайте свой ответ правильного уровня детализации.

mky ★★★★★
(02.02.22 10:04:30 MSK)

Ответ на: комментарий от bugfixer 02.02.22 08:50:56 MSK

proof(s) или gtfo
выбирай

anonymous
(02.02.22 19:10:11 MSK)

Ссылка

Ответ на: комментарий от mky 02.02.22 10:04:30 MSK

Возможно. Дайте свой ответ правильного уровня детализации.

Вопрос не в детализации. DIO это не про прямой доступ к диску как к устройству, это об bypassing page cache. И unit’ом там является не HW sector size, а fs block size. Все абстракции файловых систем сохраняются. Из ограничений - всё должно быть block size aligned, и offsets, и sizes.

И мне кажется это немножко ортогонально задаче ТС, если у него HW ошибки сыплются. Я даже не до конца понимаю как DIO в этом контексте всплыл.

bugfixer ★★★★★
(03.02.22 05:04:04 MSK)

Ответ на: комментарий от bugfixer 03.02.22 05:04:04 MSK

Все абстракции файловых систем сохраняются

Я отвечал на вопрос анонима про dd_rescue, который, врятли кто додумается запускать на обычный (регулярный) файл. Для файла-устройства O_DIRECT, во всяком случае раньше, требовал размер 512 байт, и гарантировалось, что read-ahead нет.

Я согласен, что для обычного файла ядро работает через драйвер ФС, и тот вобще может полностью игнорить флаг O_DIRECT.

Вы можете написать, в каком случае чтение 512 байт с /dev/sda с флагом O_DIRECT не превратится в одну команду READ на интерфейсе диска?

Я даже не до конца понимаю как DIO в этом контексте всплыл.

DIO всплыл в ответе Nastishka, когда ТС показывал, что dd работает на его SSD-диске.

mky ★★★★★
(03.02.22 21:22:57 MSK)

Ответ на: комментарий от mky 03.02.22 21:22:57 MSK

DIO всплыл в ответе Nastishka, когда ТС показывал, что dd работает на его SSD-диске.

Что-то мне подсказывает конкретно этот SSD читит, как насчёт записать не из /dev/zero, а /dev/random (например)?

bugfixer ★★★★★
(04.02.22 05:30:42 MSK)

Ответ на: комментарий от bugfixer 04.02.22 05:30:42 MSK

ТС чего-то молчит, видимо расстроился. Конечно, лучше бы он тут отписался, чем всё закончилось, для статистики. Возможно, что после ресета/отключения питания, ssd вобще окирпичился.

mky ★★★★★
(04.02.22 13:45:52 MSK)

покажи реакцию на удар молотком.

~~Minona~~ ★★☆
(04.02.22 15:48:12 MSK)

Ссылка

7 июля 2023 г.

Ответ на: комментарий от mky 04.02.22 13:45:52 MSK

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

Khronos
(07.07.23 19:22:47 MSK)