ZFS на десктопе

священные коровы

Unlinking the old block and linking in the new is accomplished in a single operation, so it can’t be interrupted—if you dump the power after it happens, you have the new version of the file, and if you dump power before, then you have the old version. You’re always filesystem-consistent, either way.

Вот это не совсем корректное описание. Операций там несколько (и они тут описаны), но коммит изменений происходит только после того, как все эти операции завершились успешно.

Причём всё это также верно для всех Copy-on-Write файловых систем.

Тогда вопрос: почему говорят что CoW файловые системы подвержены фрагментации из-за снепшотов?

Ведь выходит, что дело не в снепшотах… А, в принципе та же zfs, сперва будет выделять блоки по 4 мегабайт, потом всё меньше, и меньше, пока не начнет совсем уж фрагментироваться.

Instead, the copy-on-write filesystem writes out a new version of the block you modified, then updates the file’s metadata to unlink the old block, and link the new block you just wrote.

В ZFS фрагментируется свободное пространство. Также стоит заметить, что дефрагментация CoW это очень хитрый и крайне ненадёжный процесс, потому Btrfs имеет свойство превращаться в тыкву при попытке её дефрагментировать, а в ZFS дефрагментация вообще не предусмотрена.

Вот мой домашний парк (со всех машин):

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

В ZFS фрагментируется свободное пространство.

Это да. После того как удаляются данные, по идее количество длинных свобоных блоков должно увеличиться (т.е. процент фрагментации уменьшиться)?

Вот по zfs такие значения:

How the percentages relate to the average segment size of free space goes roughly like this. Based on the current Illumos kernel code, if all free space was in segments of the given size, the reported fragmentation would be:

512 B and 1 KB segments are 100% fragmented
2 KB segments are 98% fragmented; 4 KB segments are 95% fragmented.
8 KB to 1 MB segments start out at 90% fragmented and drop 10% for every power of two (eg 16 KB is 80% fragmented and 1 MB is 20%). 128 KB segments are 50% fragmented.
2 MB, 4 MB, and 8MB segments are 15%, 10%, and 5% fragmented respectively
16 MB and larger segments are 0% fragmented.

ZFS на десктопе

Чтобы что?

т.е. процент фрагментации уменьшиться

Не всегда и зависит от многих факторов.

Например у меня в среднем фрагментация выше когда пул заполнен плюс-минус наполовину. Но я видел на почти пустом пуле очень высокую фрагментацию (и даже знаю как воспроизвести ☺).

segment size

Ну вообще размер логического блока подгоняется под юзкейс. А так как его можно установить только на этапе создания пула, надо быть очень дальновидным. Иначе пул, созданный под виртуалки с 8-16M блоком, используемый под кучу мелочи (дерево портов FreeBSD, дерево ебилдов Gentoo, исходники) будет крайне неэффективен как по скорости (потому что на каждый мелкий файл нужно перезаписать полный блок), так и по объёму (потому что на каждый мелкий файл будет аллоцирован полный блок). И наоборот, пул с 512B-4K блоком, созданный под кучу мелочи, если на нём будут размещены "диски" виртуалок, будет очень сильно тормозить (потому что запись больших объёмов мелкими чанками даже с кэшем это больно).

потому Btrfs имеет свойство превращаться в тыкву при попытке её дефрагментировать

Ложь! В btrfs - это единственный способ изменить способ и тп… Работает как часы

единственный способ изменить способ

Моя твоя понимай нету!

Способ сжатия, но не важно. Оно работает.

но не важно

Если не важно — значит не нужно! (%

Стоп, назад машина!

Ну вообще размер логического блока подгоняется под юзкейс. А так как его можно установить только на этапе создания пула

Если я правильно всё понимаю, то мы сейчас совсем о разном. - Я говорю, о сегменте (ошибочно написав что это блоки), Вы же говорите о размере блока. Для фрагментации важен размер сегмента - zfs начинает их выделять под блоки начиная с 16ти мегабайт и постепенно понижая этот размер, по мере заполнения этих самых сегментов - что она нам и показывает в проценте фрагментации. - Я не прав где-то?

Чем Btrfs хуже ZFS

Всем хуже.

Все правильно сделал или тупанул и стоит пересоздать все в LVM + ext4?

Зависит от твоих хотелок и железа.

Предпочитаю не использовать zfs на десктопе и оставить его для всяких насов/проксмокса и отдельных файлопомоек. Она развивается от отдельно от ядра и создает неудобства, но при типичном использовании убунты на них можно не наткнуться. Так же недавно появилась поддержка рефлинков, отпал еще один серьезный минус относительно других фс. Если на компе много памяти, диск ссд, нужны фишки zfs помимо дедупликации, то вполне можно использовать. Но с ссд-шниками предпочитаю просто использовать btrfs на пользовательской машине.

lvm + ext4 редко когда есть смысл использовать, особенно на десктопе. xfs практически всегда лучше ext4, а lvm полезен, когда по какой-то причине нужны его фишки, но есть серьезные недостатки от использования zfs/btrfs. Использую lvm + ext4 на всяких виртуальных машинах с 10-50 гб дисками, где идет запись в какую-нибудь маленькую бд с логами. Порой там и без lvm обойтись проще.

На hdd zfs/btrfs, обычно, приводят к ощутимым потерям в скорости. Но кэширование в памяти может сгладить проблемы при записи, а сжатие улучшить ситуацию при чтении. Если не использовать сжатие и нет необходимости в фишках этих систем, то я бы избегал их на hdd.

Онлайн дедупликация zfs на десктопе в типичной ситуации ничего не дает помимо доп. нагрузки. А вот дедупликация в виде побочного эффекта от рефлинков в btrfs/xfs и свежей zfs (сам еще не пробовал) экономит место и время, пользователю даже не обязательно знать об этой особенности.

lvm + ext4 редко когда есть смысл использовать, особенно на десктопе.

lvm2 + ext4 всегда есть смысл использовать, особенно на десктопе.

Cоздаёшь таргет и сервис создания снэпшота lvm2 для /. Cоздаёшь дополнительный вход в custom.cfg меню Grub2. Всё. Имеешь возможность создавать консиситентные бэкапы основной OS из под неё же. А не перезагружаясь в любую другую OS. Примеров в инете полно. Бэкапы через снепшоты zfs и btrfs технически консиситентны, а логически нет. Т.е. снепшот не будет битым, а файлы в нём вполне м.б. полу-изменённые.

А вот XFS в качестве / на десктопе - подлянка. (Лог xfs при shutdown часто не докатывается почему-то, а при смене версии ядра обязателен xfs_repare, который отказывается работать при недокаченом логе, но успевает поставить отметку попытки открытия новым ядром. Т.о. заапгрейдил ядро, попытался загрузиться с него - получай висяк на загрузку уже с любым ядром.) Пока так вот с xfs. Под данные xfs пойдёт, но не под /.

Что касается ZFS. Сравнивал пользовательское usability (mdadm raid1 + ext4) с (zfs mirror). Чисто по субъективным ощущуениям 1 вариант существенно отзывчивее, а так же полно инструментов для восстановления случайно удалённых файлов. Зато 2 вариант существенно надёжнее, есть снепшоты, но восстановить что-либо при случайном удалении очень сложно. Так же scrubing во 2 варианте проходит быстрее, т.к. не проверяется свободное место.

Да, меня что-то не в ту степь понесло. Но это не отменяет моих утверждений про отношение размера блока к степени фрагментации.

// Только что у меня сдохло три диска разом, унеся RAID-10 с виртуалками-контейнерами в /dev/null. ☹

Имеешь возможность создавать консиситентные бэкапы основной OS из под неё же.

Предпочитаю не использовать lvm для этого. Производительность сильно падает при наличии снапшотов, надо создавать отдельный / и оставлять под снапшот место. Проще сразу btrfs использовать.

Пока так вот с xfs.

Что-то подобное видел больше 10 лет назад.

Здрасьте! Я новенький на форуме и плохо разбираюсь в компьютерах, поэтому хочу задать глупый вопрос по поводу:

// Только что у меня сдохло три диска разом, унеся RAID-10 с виртуалками-контейнерами в /dev/null. ☹

А это нормально, что ZFS насилует диски таким образом, что они умирают одновременно, а не поочерёдно, как с ext4 ???

Одни минусы, работает медленнее, программ для восстановления меньше.

lvm2 + ext4 всегда есть смысл использовать, особенно на десктопе.

ext4 не умеет уменьшаться онлайн. Btrfs в этом плане пободрее выглядит.

А это нормально, что ZFS насилует диски таким образом, что они умирают одновременно, а не поочерёдно

Умерли диски. Физически. И ZFS тут совершенно не причём.

Умерли диски. Физически. И ZFS тут совершенно не причём.

Это ZFS виновата, что они умерли в одно время. На ext4 бы умирли в разное время, наверное.

Я не десятках серверах использую zfs,

Только что у меня сдохло три диска разом, унеся RAID-10 с виртуалками-контейнерами в /dev/null

На двух есть проблемы: На первом, постоянно ошибки контрольных сумм. - Поменяли, бэкпейн плату, МП, CPU, проверили память. - Теперь хочу поменять HBA и провода до дисков. Хочется уже добить этот вопрос…

И на одном из серверов, я потерял том raid-10 из-за выхода из строя ECC памяти. - У меня ECC память начала сыпать ошибками, и, посколько я делал всякие снепшоты, и т.п. - пытаясь понять что не так, похоже в момент когда zfs обновляла свои метаданные - память выдала ошибочные данные, как результат, том монтировался только на чтение. На запись монтироваться не мог, io 100% и всё. Каюк.

В обоих случаях, полагаю, проблем в zfs нет, это всё же аппаратные дела, но, которые явно дают понять, что резервная копия всегда нужна.

Да, размер блока нужно грамотно выбирать - я постил тред, где после того, как я его выбрал правильно, на диски нагрузку по вводу-выводу я сократил в десять раз, собственно…

Не приведет. Но для CoW всё равно нужен будет некий объем данных для удаления файла. Даже на ЛОРе есть пара-тройка тредов, где люди забивали BTRFS на 100% и при попытке удалить файл ловили «No space left on device».

Я такое на тестовом пуле получал, так что проблема реальная

Это ZFS виновата, что они умерли в одно время.

Докажи это. А потом я докажу обратное.

На ext4 бы умирли в разное время, наверное.

Посыпались диски, а не файловая система.

наверное

То есть ты просто в лужу пукнул? Ну ладно, не стану тебя переубеждать.

В моём случае проблема тоже аппаратная. Но пока неясно в чём конкретно: память, бэкплейн и/или питание. Но ясно что данные (в бытовых условиях) достать не получится.

Докажи это. А потом я докажу обратное.

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

Посыпались диски, а не файловая система.

ZFS, по-твоему, надежная фс, но она не исключает возможности отказа оборудования.

То есть ты просто в лужу пукнул?

Я предположил. ZFS создает дополнительные нагрузки на диски из-за своих особенностей, что могло привести к их одновременному выходу из строя. На ext4 нагрузка распределяется иначе, поэтому вероятность одновременного отказа дисков меньше.

Ну ладно, не стану тебя переубеждать.

Будешь! Конечно, если тебе есть чем. На самом деле ты просто боишься, что это окажется правдой и твоя любимая фс тебе подложила =)

Если все три диска были одного цвета, они могли выйти из строя одновременно из-за увеличенной нагрузки.

Тогда почему четвёртый точно такой же не сдох вместе с остальными?

ZFS может создавать больше тепла

Эээ… ШТООО?! Это когда в ZFS встроили функцию обогревателя? (%

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

И тут мы пришли к тому, что ZFS тут совершенно не причём. (%

ZFS, по-твоему, надежная фс, но она не исключает возможности отказа оборудования.

Диски посыпались и поэтому ZFS на них умерла, а не наоборот!

ZFS создает дополнительные нагрузки на диски из-за своих особенностей, что могло привести к их одновременному выходу из строя. На ext4 нагрузка распределяется иначе, поэтому вероятность одновременного отказа дисков меньше.

Вообще никак не связано с физической смертью дисков. Если бы речь шла именно о побивке данных на разделе, я бы с тобой тоже не мог согласиться, так как ZFS проверяет данные при доступе и пытается их восстановить, когда это возможно. С Ext4 ты просто получаешь частично битые данные.

Тогда почему четвёртый точно такой же не сдох вместе с остальными?

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

Это когда в ZFS встроили функцию обогревателя? (%

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

И тут мы пришли к тому, что ZFS тут совершенно не причём. (%

ZFS активно использует диски для проверки целостности данных и восстановления, это может создавать дополнительную нагрузку. Эта повышенная нагрузка может привести к более быстрому износу дисков. На ext4 такой интенсивной нагрузки нет, поэтому диски могли бы выйти из строя в разное время.

Диски посыпались и поэтому ZFS на них умерла, а не наоборот!

Наконец-то тебя начинает бомбить)) Если ZFS проверяет данные и пытается их восстановить, то ZFS могла бы предупредить о проблемах, но интенсивная специфическая работа могла ускорить выход из строя дисков, не оставив шансов на уведомление.

Да, я, конечно, верю что проблема имеет место быть! Так что, в этом сомнений нет. Спасибо!

А в чем выразилась именно посыпанность диска? Вот смотри какое у меня дерьмо творится на файло-помойке с дедупликацией. Я предполагаю, что виноват HBA или шлейфы:

NAME                                                  STATE     READ WRITE CKSUM
tank                                                  DEGRADED     0     0     0
  mirror-0                                            DEGRADED     0     0     0
    ata-WDC_WD4000FYYZ-01UL1B3_WD-WMC130F3ADL6        ONLINE       0     0     0
    ata-WDC_WD4003FRYZ-01F0DB0_VBHAHM3F               DEGRADED     0     0 1.35K  too many errors
    ata-HGST_HUS726T4TALE6L4_VBHSH5XF                 DEGRADED     0     0   452  too many errors
  mirror-1                                            DEGRADED     0     0     0
    ata-WDC_WD4000FYYZ-01UL1B2_WD-WCC136ZRL1K1        ONLINE       0     0     0
    ata-HGST_HUS726T4TALE6L4_VBHS678F                 DEGRADED     0     0 2.80K  too many errors
  mirror-4                                            ONLINE       0     0     0
    ata-WDC_WD4003FRYZ-01F0DB0_V1JWM8LG               ONLINE       0     0     0
    ata-WDC_WD4003FRYZ-01F0DB0_V1JW4AGG               ONLINE       0     0     0
  mirror-5                                            DEGRADED     0     0     0
    ata-WDC_WD30EFRX-68AX9N0_WD-WMC1T1003960          ONLINE       0     0     0
    ata-WDC_WD30EFRX-68AX9N0_WD-WMC1T1070377          DEGRADED     0     0 1.20K  too many errors
dedup
  mirror-3                                            ONLINE       0     0     0
    ata-KINGSTON_SEDC500M480G_50026B72828B7BEA-part6  ONLINE       0     0     0
    ata-KINGSTON_SEDC500M480G_50026B72828B7831-part6  ONLINE       0     0     0
logs
  ata-KINGSTON_SEDC500M480G_50026B72828B7BEA-part4    ONLINE       0     0     0
  ata-KINGSTON_SEDC500M480G_50026B72828B7831-part4    ONLINE       0     0     0
cache
  ata-KINGSTON_SEDC500M480G_50026B72828B7BEA-part5    ONLINE       0     0     0

Так ты не в zpool status сюда смотри, ты в smartctl -a /path/to/your/disk/device смотри. Если там UDMA CRC errors растет - то это шлейф. Если Reallocated/Current Pending/Offline Uncorrectable - то это девайсу самому кабзда. А вот если все счетчики на девайсах в порядке, тогда это либо бэкплейн, либо оперативка.

это исключение

Из той же партии.

закономерность

Это статистическое понятие. Здесь оно не применимо.

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

ZFS активно использует диски для проверки целостности данных и восстановления, это может создавать дополнительную нагрузку. Эта повышенная нагрузка может привести к более быстрому износу дисков. На ext4 такой интенсивной нагрузки нет, поэтому диски могли бы выйти из строя в разное время.

На фоне общей нагрузки на сервере, нагрузка от проверок в пределах погрешности. С тем же успехом могли сдохнуть даже FAT16.

Наконец-то тебя начинает бомбить

Не дождёшься. Ты же не разбираешься в коплюхтерах, я тебе как тупенькому объясняю.

А в чем выразилась именно посыпанность диска?

Отвалился даже S.M.A.R.T. Я смог извернуться его прочитать, надо было вообще не пинать диск после подключения, вначале считать смарт, ибо при попытке импорта пула или другого интенсивного чтения оно сразу "соображает" что оно сдохло и тыквится.

Дальнейшие эксперименты приостановлены. Надо попробовать данные вытащить, а для этого надо извернуться импортировать пул хотя бы с readonly=on.

Вот смотри какое у меня дерьмо творится на файло-помойке с дедупликацией.

У меня также на mirrored stripe, но оно не может импортироваться, потому что одна из половинок страйпа всё, один из mirror ушёл полностью. zpool status показать не могу по выше описанным причинам.

Я предполагаю, что виноват HBA или шлейфы

Как выше советует Pinkbyte, нужно смотреть смарт, но я бы советовал вместо -a (all) смотреть -x (extra+all). Но я ненастоящий сварщик в выхлопе не особо шарю, потому кастовать на выхлоп практически бесполезно. ☺

Спасибо!

Вот что на одном из проблемных дисков, я так понимаю, всё супер… А проблема есть:

SMART Attributes Data Structure revision number: 16
Vendor Specific SMART Attributes with Thresholds:
ID# ATTRIBUTE_NAME          FLAG     VALUE WORST THRESH TYPE      UPDATED  WHEN_FAILED RAW_VALUE
  1 Raw_Read_Error_Rate     0x000b   100   100   016    Pre-fail  Always       -       0
  2 Throughput_Performance  0x0005   132   132   054    Pre-fail  Offline      -       96
  3 Spin_Up_Time            0x0007   148   148   024    Pre-fail  Always       -       404 (Average 412)
  4 Start_Stop_Count        0x0012   100   100   000    Old_age   Always       -       18
  5 Reallocated_Sector_Ct   0x0033   100   100   005    Pre-fail  Always       -       0
  7 Seek_Error_Rate         0x000b   100   100   067    Pre-fail  Always       -       0
  8 Seek_Time_Performance   0x0005   128   128   020    Pre-fail  Offline      -       18
  9 Power_On_Hours          0x0012   099   099   000    Old_age   Always       -       9794
 10 Spin_Retry_Count        0x0013   100   100   060    Pre-fail  Always       -       0
 12 Power_Cycle_Count       0x0032   100   100   000    Old_age   Always       -       18
192 Power-Off_Retract_Count 0x0032   100   100   000    Old_age   Always       -       427
193 Load_Cycle_Count        0x0012   100   100   000    Old_age   Always       -       427
194 Temperature_Celsius     0x0002   117   117   000    Old_age   Always       -       51 (Min/Max 19/57)
196 Reallocated_Event_Count 0x0032   100   100   000    Old_age   Always       -       0
197 Current_Pending_Sector  0x0022   100   100   000    Old_age   Always       -       0
198 Offline_Uncorrectable   0x0008   100   100   000    Old_age   Offline      -       0
199 UDMA_CRC_Error_Count    0x000a   200   200   000    Old_age   Always       -       0

SMART Error Log Version: 1
No Errors Logged

а для этого надо извернуться импортировать пул хотя бы с readonly=on

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

P.S. smart выложил выше - ничего криминального на проблемном диске не вижу… За ключ x - спасибо. Любопытно.

Температура диска высоковата(57 - предельная, а у тебя 51), а так в целом никакого криминала нет.

Может быть такое что блок питания испортился, кстати - например, диски висят на одном плече, и это плечо перестало выдавать нужный ток.

У меня на десктопе такое было. Данные немного побило, но после замены нормализовалось (спасибо зеркалированию).

smart выложил выше - ничего криминального на проблемном диске не вижу

Температура разве что. Диск свеженький.

Температура разве что. Диск свеженький.

Вот вот… И, аналогичная чехарда с тремя дисками происходит… В рот мне ноги.

Спасибо. Но, вот три диска в массиве выдают ошибки контрольных сумм… Хоть стой, хоть падай, хоть прыгай.

Я предполагаю, что виноват HBA или шлейфы

Есть ещё предположение что питания не хватает.

У тебя там один Hitachi. Старые (выпущенные до того, как они были куплены Western Digital) довольно чувствительны к питанию. На просадках они имеют свойство троить. Про WD по этому поводу мне (пока) сказать нечего, но по косвенным тоже вполне возможно.

У меня, кстати, тоже WD RE, только объёмом поменьше.

Но, вот три диска в массиве выдают ошибки контрольных сумм… Хоть стой, хоть падай, хоть прыгай.

Я свои битые диски решил прогнать на чтение-запись по совету знакомого, который в восстановлении данных имеет опыт. Либо диск превратится в тыкву (если физические повреждения), либо отдуплится (если софтбэды) и какое-то время прослужит ещё.

У тебя там один Hitachi. Старые (выпущенные до того, как они были куплены Western Digital) довольно чувствительны к питанию. На просадках они имеют свойство троить. Про WD по этому поводу мне (пока) сказать нечего, но по косвенным тоже вполне возможно.

Меняли БП. Меняли диски! В этих дырках всегда сбои… Сейчас заказываю шлейфы и HBA

Я свои битые диски решил прогнать на чтение-запись по совету знакомого, который в восстановлении данных имеет опыт. Либо диск превратится в тыкву (если физические повреждения), либо отдуплится (если софтбэды) и какое-то время прослужит ещё.

Ну, стало быть они как-то видятся? Чем прогонять на чтение? mhdd, всё ещё норм инструмент или уже нет?

В этих дырках всегда сбои…

Ну раз так, то HBA или шлейфы, да.

Ну, стало быть они как-то видятся?

Как я уже писал, если их не трогать, то они определяются. При попытке интенсивного доступа (как чтение, так и запись), сразу превращаются в тыкву и отваливаются. Потому из single-user.

Чем прогонять на чтение?

Я не настоящий сварщик:

dd if=/dev/ada0 of=/dev/ada0 bs=512 conv=noerror

mhdd

Я не линуксоид. (=
Но говорят что оно умерло. Как и Victoria.

Ну раз так, то HBA или шлейфы, да.

Ну, вот тогда не сходится, раз SMART чистый (как мне писали выше, что в случае шлейфов должны быть ошибки, ну, и в случае HBA, вероятно они). Но, блин, другого уже ничего не остается… Так что - да. Заказал уже.

dd if=/dev/ada0 of=/dev/ada0 bs=512 conv=noerror

Ряд вопросов к команде: Во первых, оно ж на запись? Вычитали, записали туда же… Второе: bs=512, у Вас диски 512 сектора, не 4096? Третье: а зачем так делать? Если будут нечитаемые блоки, ну, плюс-минус в SMART они и так появятся. В чем логика? Почему не так:

dd if=/dev/ada0 of=/dev/null bs=1M

На первой ошибке оно и встанет, тем самым Вы убедитесь что диск сдох. Какой cмысл работы на неделю чтения блоков по 512? Но, я тоже не сварщик. Так что могу чего-то не допонимать.

Я не линуксоид. (= Но говорят что оно умерло. Как и Victoria.

Так оно вообще всё на ms-dos работает, если мы говорим о mhdd - запускается livecd, получает монопольный доступ к диску и поехали. Сразу карта видна поблочная и т.п. :)

Во первых, оно ж на запись?

Чтобы потом отдельно не проводить тесты на запись.

Второе: bs=512, у Вас диски 512 сектора, не 4096?

512 байт.

Третье: а зачем так делать?

Если ошибки чисто логические (CKSUM), оно отдуплится (собственно, один диск уже оживлён таким образом).

dd if=/dev/ada0 of=/dev/null bs=1M

На первой ошибке оно и встанет, тем самым Вы убедитесь что диск сдох.

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

Какой cмысл работы на неделю чтения блоков по 512? Но, я тоже не сварщик. Так что могу чего-то не допонимать.

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

Так оно вообще всё на ms-dos работает

А у меня есть только PC-DOS, причём без COMMAND.COM (точнее он подменён какой-то вендорской утилитой). Ну и есть одна проблема: по SoL я его не увижу, а монитора с VGA у меня нет. )=

А зачем на ноуте ZFS?

Чтобы головка от ноутбука не свистела

Чтобы потом отдельно не проводить тесты на запись.

А, ну тут я не понял вначале, Вы сказали, что только мол чтение проверяете, и тут я вижу команду на запись. По этому удивился…

(собственно, один диск уже оживлён таким образом). Отпишитесь, пож-та, о рез-тах.

Это тыканье контроллера носом в проблемные блоки, если проблема логическая, оно просрётся и поедет дальше.

Сомнительно, если честно… :) Я не понимаю как это технически происходит. Сомнительно, но, ОКей, как скажет один банкир.

А у меня есть только PC-DOS, причём без COMMAND.COM (точнее он подменён какой-то вендорской утилитой). Ну и есть одна проблема: по SoL я его не увижу, а монитора с VGA у меня нет. )=

Любопытно чем закончится история. Я в свою очередь могу отписать, чем закончится моя история с HBA и шлейфами. :)

Вы сказали, что только мол чтение проверяете, и тут я вижу команду на запись.

Если оно не читает — значит блок битый. Но если в него записать, то он может ожить (как в моём случае).

Сомнительно, если честно… :) Я не понимаю как это технически происходит.

Same shit. Но… это работает! На данный момент я прогнал два диска и… оба ожили. Да, скорее всего часть блоков реаллоцировалась, но они даже в скорости не потеряли.

Но у меня ситуация не самая стандартная: диски отыквились от постепенного снижения питания.

Любопытно чем закончится история.

Ну как минимум два диска однозначно живы! Третий уже в процессе.

Я в свою очередь могу отписать, чем закончится моя история с HBA и шлейфами. :)

С удовольствием разделю радость победы. Или посочувствую в случае поражения.