Аааа, бля...

[ufm]

...сказали суровые сибирские мужики. :)

zpool create -m /export/test1 test1 raidz /export/sl1 /export/sl2 /export/sl3
zpool add -f test1 /export/sl4

zpool status
  pool: test1
 state: ONLINE
 scrub: resilver completed with 0 errors on Sat Jun  9 21:52:50 2007
config:

        NAME             STATE     READ WRITE CKSUM
        test1            ONLINE       0     0     0
          raidz1         ONLINE       0     0     0
            /export/sl1  ONLINE       0     0     0
            /export/sl2  ONLINE       0     0     0
            /export/sl3  ONLINE       0     0     0
          /sl4           ONLINE       0     0     0

dd if=/dev/zero of=sl4 bs=512 count=512000
zpool scrub test1

И пц котёнку. Система трапнулась и ушла на перезагрузку. :)

Впрочем, когда я добавлял отдельный vdev к рейду система меня честно нафиг послала, со словами что я тупой и не понимаю что делаю. Из-за этого -f использовать и пришлось. :)

Comments

[38th.livejournal.com]

На 15-й строчке я перестал понимать что ты делал. ;))

[ufm.livejournal.com]

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

[http://users.livejournal.com/_slw/]

send-pr?

[ufm.livejournal.com]

You have created an unreplicated pool of the form:

pool
raidz
/export/sl1
/export/sl2
/export/sl3
/export/sl4

I believe 'zpool add' will warn you about this, hence needing the '-f'.

You then overwrite the entire contents of /export/sl4, causing ZFS to
reopen the device, only to not recognize the device and therefore mark
it FAULTED. Because you are in an unreplicated pool, you then tripped
over:

6413847 vdev label write failure should be handled more gracefully

Which is just one manifestation of a series of issues currently being
worked on where a failed writes in an unreplicated config can cause ZFS
to panic.

Using a replicated config will prevent this problem from happining in
the future.

- Eric