Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
Failed rpool
8 views
Skip to first unread message
Dmitry Komissarov
Oct 6, 2017, 4:35:00 PM10/6/17
to
Привет, All!
После серийного отключения электричества root pool на
OmniOS-r151022 перешел в состояние FAILED c corrupted data.
rpool состял из одного диска, без рейда.
Вытащил из машины винт и попытался импортировать его в
виртуалку с ключом -F.
zpool начал ругаться на отсутствующие диски.
Если импортировать с -f то zpool ничего не говорит про диски,
но жалуеться на ошибки IO.
Тогда попробовал загрузиться с флешки на пострадавшей машине,
zpool по прежнему ругается на диски.
Правда, диск в системе при загрузки с флешки
начал отображаться как c5d0s0, а был как c1d0s0.
phys-path диска остался прежним.
А вот zdb говорит что path все таки c1d0s0.
Но если, сделать симлинк с c5.. на c1.., то zpool все равно не видит
диск, хотя import без ключей начал показывать имя диска как c1...
В общем, можно с этим что-то сделать или сразу форматировать?
Сам диск в порядке, смарт ошибок не показывает, dd of=/dev/null
проходит без ошибок.
WBR, Dmitry
После серийного отключения электричества root pool на
OmniOS-r151022 перешел в состояние FAILED c corrupted data.
rpool состял из одного диска, без рейда.
Вытащил из машины винт и попытался импортировать его в
виртуалку с ключом -F.
zpool начал ругаться на отсутствующие диски.
Если импортировать с -f то zpool ничего не говорит про диски,
но жалуеться на ошибки IO.
Тогда попробовал загрузиться с флешки на пострадавшей машине,
zpool по прежнему ругается на диски.
Правда, диск в системе при загрузки с флешки
начал отображаться как c5d0s0, а был как c1d0s0.
phys-path диска остался прежним.
А вот zdb говорит что path все таки c1d0s0.
Но если, сделать симлинк с c5.. на c1.., то zpool все равно не видит
диск, хотя import без ключей начал показывать имя диска как c1...
В общем, можно с этим что-то сделать или сразу форматировать?
Сам диск в порядке, смарт ошибок не показывает, dd of=/dev/null
проходит без ошибок.
WBR, Dmitry
Victor Sudakov
Oct 7, 2017, 3:14:59 AM10/7/17
to
Dear Dmitry,
06 Oct 17 22:52, you wrote to All:
DK> После серийного отключения электричества root pool на
DK> OmniOS-r151022 перешел в состояние FAILED c corrupted data.
DK> rpool состял из одного диска, без рейда.
DK> Вытащил из машины винт и попытался импортировать его в
DK> виртуалку с ключом -F.
DK> zpool начал ругаться на отсутствующие диски.
DK> Если импортировать с -f то zpool ничего не говорит про диски,
DK> но жалуеться на ошибки IO.
DK> Тогда попробовал загрузиться с флешки на пострадавшей машине,
DK> zpool по прежнему ругается на диски.
DK> Правда, диск в системе при загрузки с флешки
DK> начал отображаться как c5d0s0, а был как c1d0s0.
DK> phys-path диска остался прежним.
DK> А вот zdb говорит что path все таки c1d0s0.
DK> Но если, сделать симлинк с c5.. на c1.., то zpool все равно не видит
DK> диск, хотя import без ключей начал показывать имя диска как c1...
DK> В общем, можно с этим что-то сделать или сразу форматировать?
Я правильно понял, что этот пул не удалось нигде, ни на какой системе, ни с
какими ключами импортировать? Доступа к данным нет никаким способом?
Victor Sudakov, VAS4-RIPE, VAS47-RIPN
06 Oct 17 22:52, you wrote to All:
DK> После серийного отключения электричества root pool на
DK> OmniOS-r151022 перешел в состояние FAILED c corrupted data.
DK> rpool состял из одного диска, без рейда.
DK> Вытащил из машины винт и попытался импортировать его в
DK> виртуалку с ключом -F.
DK> zpool начал ругаться на отсутствующие диски.
DK> Если импортировать с -f то zpool ничего не говорит про диски,
DK> но жалуеться на ошибки IO.
DK> Тогда попробовал загрузиться с флешки на пострадавшей машине,
DK> zpool по прежнему ругается на диски.
DK> Правда, диск в системе при загрузки с флешки
DK> начал отображаться как c5d0s0, а был как c1d0s0.
DK> phys-path диска остался прежним.
DK> А вот zdb говорит что path все таки c1d0s0.
DK> Но если, сделать симлинк с c5.. на c1.., то zpool все равно не видит
DK> диск, хотя import без ключей начал показывать имя диска как c1...
DK> В общем, можно с этим что-то сделать или сразу форматировать?
Я правильно понял, что этот пул не удалось нигде, ни на какой системе, ни с
какими ключами импортировать? Доступа к данным нет никаким способом?
Victor Sudakov, VAS4-RIPE, VAS47-RIPN
Dmitry Komissarov
Oct 7, 2017, 3:54:59 AM10/7/17
to
Привет, Victor!
07 Oct 17 13:45, you wrote to me:
DK>> В общем, можно с этим что-то сделать или сразу форматировать?
VS> Я правильно понял, что этот пул не удалось нигде, ни на какой системе,
VS> ни с какими ключами импортировать? Доступа к данным нет никаким
VS> способом?
Да, из всех опробованных способов ни один не сработал.
Пробовал подключать сначала к виртуалке с OmniOS, потом
на родной машине загрузившись с флешки.
Так что да, ни с какими ключами импорт не удается и
соответственно доступа к данным нет.
Вот думаю попробовать под FreeBSD в виртуалке импортировать...
WBR, Dmitry
07 Oct 17 13:45, you wrote to me:
DK>> В общем, можно с этим что-то сделать или сразу форматировать?
VS> ни с какими ключами импортировать? Доступа к данным нет никаким
VS> способом?
Да, из всех опробованных способов ни один не сработал.
Пробовал подключать сначала к виртуалке с OmniOS, потом
на родной машине загрузившись с флешки.
Так что да, ни с какими ключами импорт не удается и
соответственно доступа к данным нет.
Вот думаю попробовать под FreeBSD в виртуалке импортировать...
WBR, Dmitry
Victor Sudakov
Oct 7, 2017, 11:24:59 AM10/7/17
to
Dear Dmitry,
07 Oct 17 10:31, you wrote to me:
DK>>> В общем, можно с этим что-то сделать или сразу форматировать?
VS>> Я правильно понял, что этот пул не удалось нигде, ни на какой
VS>> системе, ни с какими ключами импортировать? Доступа к данным нет
VS>> никаким способом?
DK> Да, из всех опробованных способов ни один не сработал.
DK> Пробовал подключать сначала к виртуалке с OmniOS, потом
DK> на родной машине загрузившись с флешки.
DK> Так что да, ни с какими ключами импорт не удается и
DK> соответственно доступа к данным нет.
А "zpool import [-D]" хотя бы показывает его как пул, который потенциально
можно импортировать?
Я вообще всегда боялся такой ситуации, которая видимо и возникла у тебя. Всякий
встроенный scrub и прочий ремонт рассчитаны на ситуацию, когда пул всё-таки
импортирован, а что если он не импортируется?
На http://docs.oracle.com/cd/E19253-01/819-5461/gbctt/index.html рекомендуют
еще "zpool clear -F", я не помню, ты пробовал это или нет?
DK> Вот думаю попробовать под FreeBSD в виртуалке импортировать...
Victor Sudakov, VAS4-RIPE, VAS47-RIPN
07 Oct 17 10:31, you wrote to me:
DK>>> В общем, можно с этим что-то сделать или сразу форматировать?
VS>> Я правильно понял, что этот пул не удалось нигде, ни на какой
VS>> никаким способом?
DK> Да, из всех опробованных способов ни один не сработал.
DK> Пробовал подключать сначала к виртуалке с OmniOS, потом
DK> на родной машине загрузившись с флешки.
DK> Так что да, ни с какими ключами импорт не удается и
DK> соответственно доступа к данным нет.
А "zpool import [-D]" хотя бы показывает его как пул, который потенциально
можно импортировать?
Я вообще всегда боялся такой ситуации, которая видимо и возникла у тебя. Всякий
встроенный scrub и прочий ремонт рассчитаны на ситуацию, когда пул всё-таки
импортирован, а что если он не импортируется?
На http://docs.oracle.com/cd/E19253-01/819-5461/gbctt/index.html рекомендуют
еще "zpool clear -F", я не помню, ты пробовал это или нет?
DK> Вот думаю попробовать под FreeBSD в виртуалке импортировать...
Victor Sudakov, VAS4-RIPE, VAS47-RIPN
Dmitry Komissarov
Oct 7, 2017, 12:14:59 PM10/7/17
to
Привет, Victor!
07 Oct 17 21:58, you wrote to me:
VS> А "zpool import [-D]" хотя бы показывает его как пул, который
VS> потенциально можно импортировать?
Вывод команды:
#zpool import
pool: rpool
id: 9411....
state: FAULTED
status: The pool was last accessed by another system.
action: The pool cannot be imported due to damaged devices or data.
The pool may be active on another system, but can be imported
using
the '-f' flag.
config:
rpool FAULTED corrupted data
c4t0d0s0 ONLINE
#zpool import -f -a
cannot import 'rpool': I/O error
Destroy and re-create the pool from
a backup source.
#zpool import -Ff -a
cannot import 'rpool': one or more devices is currently unavailable
ну и все остальные комбинации дают схожие ответы, за исключением -n - тогда
вообще пустой вывод
Причина сообщения о недоступности диска это похоже косяк в реализации zfs в
иллюмосе. Потому что если верить инету, под фрей это лечиться указанием
через -d /dev/by-id
Здесь же можно обуказываться на что угодно, хотя zdb показывает phys-path
совпадающий с системным.
VS> Я вообще всегда боялся такой ситуации, которая видимо и возникла у
VS> тебя. Всякий встроенный scrub и прочий ремонт рассчитаны на ситуацию,
VS> когда пул всё-таки импортирован, а что если он не импортируется?
Я так понимаю, при проектировании даже не задумывались, что будет, если
развалится пул состоящий из одного диска. Видимо по задумке надо сразу
разворачиваться из бекапа.
VS> На http://docs.oracle.com/cd/E19253-01/819-5461/gbctt/index.html
VS> рекомендуют еще "zpool clear -F", я не помню, ты пробовал это или нет?
clear и scrub требуют импортированный пул.
DK>> Вот думаю попробовать под FreeBSD в виртуалке импортировать...
Утилиты (zbd и zpool) из FreeBSD пул даже не видят.
А еще из смешного.
Под фрей у zpool есть ключ -X. В же хелпе zpool'а от Illumos такого ключа нет,
но
утилита на него не ругается. Если сделать zpool import -fFX rpool идет
интенсивное
обращение к диску, но результат тот же: one or more devices ... unavailable.
WBR, Dmitry
07 Oct 17 21:58, you wrote to me:
VS> А "zpool import [-D]" хотя бы показывает его как пул, который
VS> потенциально можно импортировать?
Вывод команды:
#zpool import
pool: rpool
id: 9411....
state: FAULTED
status: The pool was last accessed by another system.
action: The pool cannot be imported due to damaged devices or data.
The pool may be active on another system, but can be imported
using
the '-f' flag.
config:
rpool FAULTED corrupted data
c4t0d0s0 ONLINE
#zpool import -f -a
cannot import 'rpool': I/O error
Destroy and re-create the pool from
a backup source.
#zpool import -Ff -a
cannot import 'rpool': one or more devices is currently unavailable
ну и все остальные комбинации дают схожие ответы, за исключением -n - тогда
вообще пустой вывод
Причина сообщения о недоступности диска это похоже косяк в реализации zfs в
иллюмосе. Потому что если верить инету, под фрей это лечиться указанием
через -d /dev/by-id
Здесь же можно обуказываться на что угодно, хотя zdb показывает phys-path
совпадающий с системным.
VS> Я вообще всегда боялся такой ситуации, которая видимо и возникла у
VS> тебя. Всякий встроенный scrub и прочий ремонт рассчитаны на ситуацию,
VS> когда пул всё-таки импортирован, а что если он не импортируется?
Я так понимаю, при проектировании даже не задумывались, что будет, если
развалится пул состоящий из одного диска. Видимо по задумке надо сразу
разворачиваться из бекапа.
VS> На http://docs.oracle.com/cd/E19253-01/819-5461/gbctt/index.html
VS> рекомендуют еще "zpool clear -F", я не помню, ты пробовал это или нет?
clear и scrub требуют импортированный пул.
DK>> Вот думаю попробовать под FreeBSD в виртуалке импортировать...
А еще из смешного.
Под фрей у zpool есть ключ -X. В же хелпе zpool'а от Illumos такого ключа нет,
но
утилита на него не ругается. Если сделать zpool import -fFX rpool идет
интенсивное
обращение к диску, но результат тот же: one or more devices ... unavailable.
WBR, Dmitry
Victor Sudakov
Oct 8, 2017, 12:15:00 AM10/8/17
to
Dear Dmitry,
07 Oct 17 18:26, you wrote to me:
VS>> А "zpool import [-D]" хотя бы показывает его как пул, который
VS>> потенциально можно импортировать?
DK> Вывод команды:
DK> #zpool import
DK> pool: rpool
DK> id: 9411....
DK> state: FAULTED
DK> status: The pool was last accessed by another system.
DK> action: The pool cannot be imported due to damaged devices or
DK> data.
DK> The pool may be active on another system, but can be
DK> imported using
DK> the '-f' flag.
DK> config:
DK> rpool FAULTED corrupted data
DK> c4t0d0s0 ONLINE
DK> #zpool import -f -a
DK> cannot import 'rpool': I/O error
DK> Destroy and re-create the pool from
DK> a backup source.
Это в результате сбоя по питанию оно так фатально поломалось?
С UFS я что только ни делал за свой 20-летний опыт общения с фрей, до полной
ремонтонепригодности UFS не ломалась ни разу.
DK> #zpool import -Ff -a
DK> cannot import 'rpool': one or more devices is currently unavailable
DK> ну и все остальные комбинации дают схожие ответы, за исключением -n -
DK> тогда вообще пустой вывод
DK> Причина сообщения о недоступности диска это похоже косяк в реализации
DK> zfs в иллюмосе. Потому что если верить инету, под фрей это лечиться
DK> указанием через -d /dev/by-id Здесь же можно обуказываться на что
DK> угодно, хотя zdb показывает phys-path совпадающий с системным.
VS>> Я вообще всегда боялся такой ситуации, которая видимо и возникла
VS>> у тебя. Всякий встроенный scrub и прочий ремонт рассчитаны на
VS>> ситуацию, когда пул всё-таки импортирован, а что если он не
VS>> импортируется?
DK> Я так понимаю, при проектировании даже не задумывались, что будет,
DK> если развалится пул состоящий из одного диска. Видимо по задумке надо
DK> сразу разворачиваться из бекапа.
VS>> На http://docs.oracle.com/cd/E19253-01/819-5461/gbctt/index.html
VS>> рекомендуют еще "zpool clear -F", я не помню, ты пробовал это или
VS>> нет?
DK> clear и scrub требуют импортированный пул.
А. Я так понял из документа, что для clear импортированный не нужен. Буду
знать.
DK>>> Вот думаю попробовать под FreeBSD в виртуалке импортировать...
DK> Утилиты (zbd и zpool) из FreeBSD пул даже не видят.
DK> А еще из смешного.
DK> Под фрей у zpool есть ключ -X. В же хелпе zpool'а от Illumos такого
DK> ключа нет, но утилита на него не ругается. Если сделать zpool import
DK> -fFX rpool идет интенсивное обращение к диску, но результат тот же:
DK> one or more devices ... unavailable.
На 10.3 нет такого ключа, а что он должен делать?
Victor Sudakov, VAS4-RIPE, VAS47-RIPN
07 Oct 17 18:26, you wrote to me:
VS>> А "zpool import [-D]" хотя бы показывает его как пул, который
VS>> потенциально можно импортировать?
DK> #zpool import
DK> pool: rpool
DK> id: 9411....
DK> state: FAULTED
DK> status: The pool was last accessed by another system.
DK> action: The pool cannot be imported due to damaged devices or
DK> data.
DK> The pool may be active on another system, but can be
DK> imported using
DK> the '-f' flag.
DK> config:
DK> rpool FAULTED corrupted data
DK> c4t0d0s0 ONLINE
DK> #zpool import -f -a
DK> cannot import 'rpool': I/O error
DK> Destroy and re-create the pool from
DK> a backup source.
Это в результате сбоя по питанию оно так фатально поломалось?
С UFS я что только ни делал за свой 20-летний опыт общения с фрей, до полной
ремонтонепригодности UFS не ломалась ни разу.
DK> #zpool import -Ff -a
DK> cannot import 'rpool': one or more devices is currently unavailable
DK> ну и все остальные комбинации дают схожие ответы, за исключением -n -
DK> тогда вообще пустой вывод
DK> Причина сообщения о недоступности диска это похоже косяк в реализации
DK> zfs в иллюмосе. Потому что если верить инету, под фрей это лечиться
DK> указанием через -d /dev/by-id Здесь же можно обуказываться на что
DK> угодно, хотя zdb показывает phys-path совпадающий с системным.
VS>> Я вообще всегда боялся такой ситуации, которая видимо и возникла
VS>> ситуацию, когда пул всё-таки импортирован, а что если он не
VS>> импортируется?
DK> Я так понимаю, при проектировании даже не задумывались, что будет,
DK> если развалится пул состоящий из одного диска. Видимо по задумке надо
DK> сразу разворачиваться из бекапа.
VS>> На http://docs.oracle.com/cd/E19253-01/819-5461/gbctt/index.html
VS>> рекомендуют еще "zpool clear -F", я не помню, ты пробовал это или
DK> clear и scrub требуют импортированный пул.
А. Я так понял из документа, что для clear импортированный не нужен. Буду
знать.
DK>>> Вот думаю попробовать под FreeBSD в виртуалке импортировать...
DK> А еще из смешного.
DK> Под фрей у zpool есть ключ -X. В же хелпе zpool'а от Illumos такого
DK> ключа нет, но утилита на него не ругается. Если сделать zpool import
DK> -fFX rpool идет интенсивное обращение к диску, но результат тот же:
DK> one or more devices ... unavailable.
На 10.3 нет такого ключа, а что он должен делать?
Victor Sudakov, VAS4-RIPE, VAS47-RIPN
Victor Sudakov
Oct 8, 2017, 3:44:59 AM10/8/17
to
Dear Dmitry,
07 Oct 17 18:26, you wrote to me:
07 Oct 17 18:26, you wrote to me:
DK>>> Вот думаю попробовать под FreeBSD в виртуалке импортировать...
DK> Утилиты (zbd и zpool) из FreeBSD пул даже не видят.
Забыл спросить, а исправный пул из-под OmniOS-а FreeBSD видит?
Victor Sudakov, VAS4-RIPE, VAS47-RIPN
Dmitry Komissarov
Oct 8, 2017, 5:54:59 AM10/8/17
to
Привет, Victor!
08 Oct 17 14:27, you wrote to me:
Исправный - видит, даже импортирует с -f.
WBR, Dmitry
08 Oct 17 14:27, you wrote to me:
DK>>>> Вот думаю попробовать под FreeBSD в виртуалке импортировать...
DK>> Утилиты (zbd и zpool) из FreeBSD пул даже не видят.
VS> Забыл спросить, а исправный пул из-под OmniOS-а FreeBSD видит?
DK>> Утилиты (zbd и zpool) из FreeBSD пул даже не видят.
Исправный - видит, даже импортирует с -f.
WBR, Dmitry
Dmitry Komissarov
Oct 8, 2017, 5:54:59 AM10/8/17
to
Привет, Victor!
08 Oct 17 10:32, you wrote to me:
VS> Это в результате сбоя по питанию оно так фатально поломалось?
Сначала вырубился свет и видимо из-за этого, что-то в БП поломалось.
Выяснилось это не сразу, т.к. машина завелась, система загрузилась,
проработала полтора дня, потом перестала пинговаться. После перезагрузки
завелась, но через минут пять опять повисла. А потом перестала загружаться
совсем. Когда монитор к ней подцепил было уже поздно, grub перестал
видеть раздел.
VS> С UFS я что только ни делал за свой 20-летний опыт общения с фрей, до
VS> полной ремонтонепригодности UFS не ломалась ни разу.
Я вообще такого еще не видел, что бы хоть как-то, но что бы нельзя было
починить
фс. Да, даже UFS под DragonFly, когда она постоянно падала из-за моих косяков
в коде,
такого себе не позволяла.
И под Linux что raiser, что xfs вполне восстанавливались после сбоев.
По крайней мере такого, что бы нельзя было починить фс на другой машине
никогда не было.
VS> На 10.3 нет такого ключа, а что он должен делать?
Я так понимаю что zpool ключи -F и -X передает zdb.
А ключ -X от zdb это eXtreme transaction rewind
В общем возится с этим больше не буду, диск отформатирую и поставлю систему
заново,
только уже разнеся данные и систему по разным винтам.
WBR, Dmitry
08 Oct 17 10:32, you wrote to me:
VS> Это в результате сбоя по питанию оно так фатально поломалось?
Сначала вырубился свет и видимо из-за этого, что-то в БП поломалось.
Выяснилось это не сразу, т.к. машина завелась, система загрузилась,
проработала полтора дня, потом перестала пинговаться. После перезагрузки
завелась, но через минут пять опять повисла. А потом перестала загружаться
совсем. Когда монитор к ней подцепил было уже поздно, grub перестал
видеть раздел.
VS> С UFS я что только ни делал за свой 20-летний опыт общения с фрей, до
VS> полной ремонтонепригодности UFS не ломалась ни разу.
Я вообще такого еще не видел, что бы хоть как-то, но что бы нельзя было
починить
фс. Да, даже UFS под DragonFly, когда она постоянно падала из-за моих косяков
в коде,
такого себе не позволяла.
И под Linux что raiser, что xfs вполне восстанавливались после сбоев.
По крайней мере такого, что бы нельзя было починить фс на другой машине
никогда не было.
VS> На 10.3 нет такого ключа, а что он должен делать?
Я так понимаю что zpool ключи -F и -X передает zdb.
А ключ -X от zdb это eXtreme transaction rewind
В общем возится с этим больше не буду, диск отформатирую и поставлю систему
заново,
только уже разнеся данные и систему по разным винтам.
WBR, Dmitry
Vova Uralsky
Oct 8, 2017, 6:45:00 AM10/8/17
to
Hello Victor!
08 Oct 17 10:32, Victor Sudakov wrote to Dmitry Komissarov:
VS>>> потенциально можно импортировать?
DK>> Вывод команды:
DK>> #zpool import
DK>> pool: rpool
DK>> id: 9411....
DK>> state: FAULTED
DK>> status: The pool was last accessed by another system.
DK>> action: The pool cannot be imported due to damaged devices or
DK>> data.
DK>> The pool may be active on another system, but can be
VS> С UFS я что только ни делал за свой 20-летний опыт общения с фрей, до
VS> полной ремонтонепригодности UFS не ломалась ни разу.
Судя по описанию, данные действительно поломались, но не от того что система
что-то недописала, а от того что диску поплохело. Был у меня один такой сигейт,
на котором периодически данные портились. Читать можно было в любое время без
"ошибок", SMART считал что всё ОК. Я довольно долго с этим диском возился,
пытался понять механизм. Когда обнаружил что MD5 файла может быть произвольной
не только после записи, но может поменяться после power cycle, разобрал его с
сыном, чтобы показать как там всё устроено. Hа большее такой диск явно не
годился.
Тестировал чем-то типа
while :
do
dd if=/dev/zero of=$(date "+%m%d%H%M%Y.%S") bs=$((1024*1024)) count=1024 &&
continue
break
done
find . | xargs md5 | grep -v cd573cfaace07e7949bc0c46028904ff
Regards,
Vova
08 Oct 17 10:32, Victor Sudakov wrote to Dmitry Komissarov:
VS>>> потенциально можно импортировать?
DK>> Вывод команды:
DK>> #zpool import
DK>> pool: rpool
DK>> id: 9411....
DK>> state: FAULTED
DK>> status: The pool was last accessed by another system.
DK>> action: The pool cannot be imported due to damaged devices or
DK>> data.
DK>> The pool may be active on another system, but can be
DK>> c4t0d0s0 ONLINE
DK>> #zpool import -f -a
DK>> cannot import 'rpool': I/O error
DK>> Destroy and re-create the pool from
DK>> a backup source.
VS> Это в результате сбоя по питанию оно так фатально поломалось?
DK>> #zpool import -f -a
DK>> cannot import 'rpool': I/O error
DK>> Destroy and re-create the pool from
DK>> a backup source.
VS> С UFS я что только ни делал за свой 20-летний опыт общения с фрей, до
VS> полной ремонтонепригодности UFS не ломалась ни разу.
Судя по описанию, данные действительно поломались, но не от того что система
что-то недописала, а от того что диску поплохело. Был у меня один такой сигейт,
на котором периодически данные портились. Читать можно было в любое время без
"ошибок", SMART считал что всё ОК. Я довольно долго с этим диском возился,
пытался понять механизм. Когда обнаружил что MD5 файла может быть произвольной
не только после записи, но может поменяться после power cycle, разобрал его с
сыном, чтобы показать как там всё устроено. Hа большее такой диск явно не
годился.
Тестировал чем-то типа
while :
do
dd if=/dev/zero of=$(date "+%m%d%H%M%Y.%S") bs=$((1024*1024)) count=1024 &&
continue
break
done
find . | xargs md5 | grep -v cd573cfaace07e7949bc0c46028904ff
Regards,
Vova
Andrey Ostanovsky
Oct 8, 2017, 7:04:58 AM10/8/17
to
Hello Dmitry!
07 Oct 17 18:26, you wrote to Victor Sudakov:
DK>>> Вот думаю попробовать под FreeBSD в виртуалке импортировать...
Когда под фрей разваливается zfs пул - оно тоже не сильно помогает... Хотя
дисками тоже молотит дольше обычного.
Andrey
07 Oct 17 18:26, you wrote to Victor Sudakov:
DK>>> Вот думаю попробовать под FreeBSD в виртуалке импортировать...
DK> Утилиты (zbd и zpool) из FreeBSD пул даже не видят.
DK> А еще из смешного.
DK> Под фрей у zpool есть ключ -X.
DK> А еще из смешного.
Когда под фрей разваливается zfs пул - оно тоже не сильно помогает... Хотя
дисками тоже молотит дольше обычного.
Andrey
Vova Uralsky
Oct 8, 2017, 7:15:01 AM10/8/17
to
Hello Dmitry!
08 Oct 17 12:39, Dmitry Komissarov wrote to Victor Sudakov:
DK> только уже разнеся данные и систему по разным винтам.
Ты знаешь что вероятность сбоя диска в системе от этого удвоится? ;-)
Regards,
Vova
08 Oct 17 12:39, Dmitry Komissarov wrote to Victor Sudakov:
DK> только уже разнеся данные и систему по разным винтам.
Ты знаешь что вероятность сбоя диска в системе от этого удвоится? ;-)
Regards,
Vova
Dmitry Komissarov
Oct 8, 2017, 1:25:00 PM10/8/17
to
Привет, Vova!
08 Oct 17 12:27, you wrote to me:
DK>> только уже разнеся данные и систему по разным винтам.
VU> Ты знаешь что вероятность сбоя диска в системе от этого удвоится? ;-)
Ну и... ладно! :)
Оба винта одновременно из строя не выйдут.
А потеря файлопомойки конечно болезненна, но не фатальна.
WBR, Dmitry
08 Oct 17 12:27, you wrote to me:
DK>> только уже разнеся данные и систему по разным винтам.
Ну и... ладно! :)
Оба винта одновременно из строя не выйдут.
А потеря файлопомойки конечно болезненна, но не фатальна.
WBR, Dmitry
Dmitry Komissarov
Oct 8, 2017, 1:25:00 PM10/8/17
to
Привет, Vova!
08 Oct 17 11:06, you wrote to Victor Sudakov:
VU> Судя по описанию, данные действительно поломались, но не от того что
VU> система что-то недописала, а от того что диску поплохело.
Диск живой. Новую систему поднял на нем же.
Был вариант, что из-за полетевшего БП электроника винта или матери глючит.
Но нет, ни с новым БП, ни из-под SATA->USB картина не поменялась.
WBR, Dmitry
08 Oct 17 11:06, you wrote to Victor Sudakov:
VU> Судя по описанию, данные действительно поломались, но не от того что
VU> система что-то недописала, а от того что диску поплохело.
Диск живой. Новую систему поднял на нем же.
Был вариант, что из-за полетевшего БП электроника винта или матери глючит.
Но нет, ни с новым БП, ни из-под SATA->USB картина не поменялась.
WBR, Dmitry
Alexey Slukin
Oct 8, 2017, 3:24:59 PM10/8/17
to
Здpавствуй, Dmitry!
Пятница 06 Октября 2017 22:52, ты писал(а) All, в сообщении по ссылке
area://ru.unix.solaris?msgid=2:5021/46@fidonet+59d7e53a:
DK> начал отображаться как c5d0s0, а был как c1d0s0.
я так понимаю, поменялось имя устройства? А в виртуалке разве нельзя назначить
точно такое же расположение диска?
Что бы импортировалось точно с c1d0s0.
С уважением - Alexey
Пятница 06 Октября 2017 22:52, ты писал(а) All, в сообщении по ссылке
area://ru.unix.solaris?msgid=2:5021/46@fidonet+59d7e53a:
DK> начал отображаться как c5d0s0, а был как c1d0s0.
я так понимаю, поменялось имя устройства? А в виртуалке разве нельзя назначить
точно такое же расположение диска?
Что бы импортировалось точно с c1d0s0.
С уважением - Alexey
Dmitry Komissarov
Oct 8, 2017, 4:14:58 PM10/8/17
to
Привет, Alexey!
08 Oct 17 19:51, you wrote to me:
AS> назначить точно такое же расположение диска? Что бы импортировалось
AS> точно с c1d0s0.
Симлинк можно сделать. Но не помогает.
У пула еще есть два поля помимо path: devid и phys_path.
На физической машине их значения соответствовали местоположению диска, а вот
на виртаулке уже нет.
Но отрицательный результат был и там и там.
WBR, Dmitry
08 Oct 17 19:51, you wrote to me:
DK>> начал отображаться как c5d0s0, а был как c1d0s0.
AS> я так понимаю, поменялось имя устройства? А в виртуалке разве нельзя
AS> назначить точно такое же расположение диска? Что бы импортировалось
AS> точно с c1d0s0.
Симлинк можно сделать. Но не помогает.
У пула еще есть два поля помимо path: devid и phys_path.
На физической машине их значения соответствовали местоположению диска, а вот
на виртаулке уже нет.
Но отрицательный результат был и там и там.
WBR, Dmitry
Vova Uralsky
Oct 9, 2017, 8:55:00 PM10/9/17
to
Hello Dmitry!
08 Oct 17 20:09, Dmitry Komissarov wrote to Vova Uralsky:
VU>> Судя по описанию, данные действительно поломались, но не от того что
VU>> система что-то недописала, а от того что диску поплохело.
DK> Диск живой. Hовую систему поднял на нем же.
Как ты определил что он живой? Тот мой сигейт тоже был живой, читал, писал, всё
как надо, только после записи периодически безошибочно считывались неправильные
данные. Я бы не стал его гонять, если бы у меня сомнения в процессе
эксплуатации не появились. К счастью, важных данных там не было, почти, CDR'ы и
VoiceBox'ы офисной АТС.
DK> Был вариант, что из-за полетевшего БП электроника винта или матери
DK> глючит.
DK> Hо нет, ни с новым БП, ни из-под SATA->USB картина не поменялась.
В смысле, ты надеялся что после втыкания в SATA->USB у тебя всё починится? Если
вместо данных когда-то был записан мусор, восстановить их уже невозможно.
Единственное что могло спасти, при появлении первых сомнений -- сделать dd
слайса в файл и с ним в виртуалке экспериментировать.
Regards,
Vova
08 Oct 17 20:09, Dmitry Komissarov wrote to Vova Uralsky:
VU>> Судя по описанию, данные действительно поломались, но не от того что
VU>> система что-то недописала, а от того что диску поплохело.
Как ты определил что он живой? Тот мой сигейт тоже был живой, читал, писал, всё
как надо, только после записи периодически безошибочно считывались неправильные
данные. Я бы не стал его гонять, если бы у меня сомнения в процессе
эксплуатации не появились. К счастью, важных данных там не было, почти, CDR'ы и
VoiceBox'ы офисной АТС.
DK> Был вариант, что из-за полетевшего БП электроника винта или матери
DK> глючит.
DK> Hо нет, ни с новым БП, ни из-под SATA->USB картина не поменялась.
В смысле, ты надеялся что после втыкания в SATA->USB у тебя всё починится? Если
вместо данных когда-то был записан мусор, восстановить их уже невозможно.
Единственное что могло спасти, при появлении первых сомнений -- сделать dd
слайса в файл и с ним в виртуалке экспериментировать.
Regards,
Vova
Vova Uralsky
Oct 9, 2017, 8:55:00 PM10/9/17
to
Hello Dmitry!
08 Oct 17 22:54, Dmitry Komissarov wrote to Alexey Slukin:
DK> Hо отрицательный результат был и там и там.
Так import'у староые пути не важны.
Regards,
Vova
08 Oct 17 22:54, Dmitry Komissarov wrote to Alexey Slukin:
DK> Hо отрицательный результат был и там и там.
Так import'у староые пути не важны.
Regards,
Vova
Victor Sudakov
Oct 10, 2017, 2:14:59 AM10/10/17
to
Dear Vova,
09 Oct 17 23:30, you wrote to Dmitry Komissarov:
VU>>> Судя по описанию, данные действительно поломались, но не от того
VU>>> что система что-то недописала, а от того что диску поплохело.
VU> писал, всё как надо, только после записи периодически безошибочно
VU> считывались неправильные данные. Я бы не стал его гонять, если бы у
VU> меня сомнения в процессе эксплуатации не появились. К счастью, важных
VU> данных там не было, почти, CDR'ы и VoiceBox'ы офисной АТС.
Я на работе видел флешку, которая при чтении из некоторых мест отдавала каждый
раз разные данные. Т.е. записывали на неё большой случайный файл, читали
несколько раз, сравнивали cmp-ой и получали каждый раз отличия в нескольких
байтах. При этом ошибки чтения не было.
Хотя это конечно флешка, не винт.
Victor Sudakov, VAS4-RIPE, VAS47-RIPN
09 Oct 17 23:30, you wrote to Dmitry Komissarov:
VU>>> Судя по описанию, данные действительно поломались, но не от того
DK>> Диск живой. Hовую систему поднял на нем же.
VU> Как ты определил что он живой? Тот мой сигейт тоже был живой, читал,
VU> писал, всё как надо, только после записи периодически безошибочно
VU> считывались неправильные данные. Я бы не стал его гонять, если бы у
VU> меня сомнения в процессе эксплуатации не появились. К счастью, важных
VU> данных там не было, почти, CDR'ы и VoiceBox'ы офисной АТС.
Я на работе видел флешку, которая при чтении из некоторых мест отдавала каждый
раз разные данные. Т.е. записывали на неё большой случайный файл, читали
несколько раз, сравнивали cmp-ой и получали каждый раз отличия в нескольких
байтах. При этом ошибки чтения не было.
Хотя это конечно флешка, не винт.
Victor Sudakov, VAS4-RIPE, VAS47-RIPN
Dmitry Komissarov
Oct 10, 2017, 5:15:00 AM10/10/17
to
Привет, Vova!
09 Oct 17 23:28, you wrote to me:
DK>> Hо отрицательный результат был и там и там.
VU> Так import'у староые пути не важны.
Ну как бы, судя по вопросам на stackoverflow,
это не всегда так.
WBR, Dmitry
09 Oct 17 23:28, you wrote to me:
DK>> Hо отрицательный результат был и там и там.
Ну как бы, судя по вопросам на stackoverflow,
это не всегда так.
WBR, Dmitry
Dmitry Komissarov
Oct 10, 2017, 5:15:00 AM10/10/17
to
Привет, Vova!
09 Oct 17 23:30, you wrote to me:
VU> Как ты определил что он живой? Тот мой сигейт тоже был живой, читал,
VU> писал, всё как надо, только после записи периодически безошибочно
VU> считывались неправильные данные.
Ну вот у меня пока сомнений в нем не появлялось. Ошибок по чтению
на нем нет, система на него встала и работает, что еще надо?
VU> В смысле, ты надеялся что после втыкания в SATA->USB у тебя всё
VU> починится?
А почему нет? Если контроллер на матери начинает гнать пургу при заведомо
живом винте, то как это проверить не подкидывая винт на другую машину?
Сбой чтения данных может быть вызван многими причинами, не только
повреждением винта.
VU> Если вместо данных когда-то был записан мусор, восстановить
VU> их уже невозможно.
Опять же, как определить что вместо данных записан мусор? Только попробовать
прочитать эти данные на заведомо исправном устройстве.
И, к тому же, а как же хваленный CoW? Это же сколько должно быть
циклов перезаписи, что бы забить данные мусором?
VU> Единственное что могло спасти, при появлении первых
VU> сомнений -- сделать dd слайса в файл и с ним в виртуалке
VU> экспериментировать.
А смысл в дампе? Ничего особо ценного там не было, а ни времени, ни уж желания
ковыряться с ним нет. Это уж не говоря о том, что 500 гигов где то надо еще и
хранить.
WBR, Dmitry
09 Oct 17 23:30, you wrote to me:
VU> Как ты определил что он живой? Тот мой сигейт тоже был живой, читал,
VU> писал, всё как надо, только после записи периодически безошибочно
VU> считывались неправильные данные.
Ну вот у меня пока сомнений в нем не появлялось. Ошибок по чтению
на нем нет, система на него встала и работает, что еще надо?
VU> В смысле, ты надеялся что после втыкания в SATA->USB у тебя всё
VU> починится?
А почему нет? Если контроллер на матери начинает гнать пургу при заведомо
живом винте, то как это проверить не подкидывая винт на другую машину?
Сбой чтения данных может быть вызван многими причинами, не только
повреждением винта.
VU> Если вместо данных когда-то был записан мусор, восстановить
VU> их уже невозможно.
Опять же, как определить что вместо данных записан мусор? Только попробовать
прочитать эти данные на заведомо исправном устройстве.
И, к тому же, а как же хваленный CoW? Это же сколько должно быть
циклов перезаписи, что бы забить данные мусором?
VU> Единственное что могло спасти, при появлении первых
VU> сомнений -- сделать dd слайса в файл и с ним в виртуалке
VU> экспериментировать.
А смысл в дампе? Ничего особо ценного там не было, а ни времени, ни уж желания
ковыряться с ним нет. Это уж не говоря о том, что 500 гигов где то надо еще и
хранить.
WBR, Dmitry
0 new messages