ZFS will currently panic on a write failure to a non replicated pool.
In the case below the Intent Log (though it could have been any module)
could not write an intent log block. Here's a previous response from Eric
Schrock explaining how ZFS intends to handle this:
------------------------
Yes, there are three incremental fixes that we plan in this area:
6417772 need nicer message on write failure
This just cleans up the failure mode so that we get a nice
FMA failure message and can distinguish this from a random
failed assert.
6417779 ZFS: I/O failure (write on ...) -- need to reallocate writes
In a multi-vdev pool, this would take a failed write and attempt
to do the write on another toplevel vdev. This would all but
elminate the problem for multi-vdev pools.
6322646 ZFS should gracefully handle all devices failing (when writing)
This is the "real" fix. Unfortunately, it's also really hard.
Even if we manage to abort the current transaction group,
dealing with the semantics of a filesystem which has lost an
arbitrary amount of change and notifying the user in a
meaningful way is difficult at best.
Hope that helps.
- Eric
Frank Leers wrote On 10/03/06 15:10,:
Could someone offer insight into this panic, please?
panic string: ZFS: I/O failure (write on <unknown> off 0: zio
6000c5fbc0
0 [L0 ZIL intent log] 1000L/1000P DVA[0]=<1:249b68000:1000> zilog uncompre
ssed BE contiguous birth=318892 fill=0 cksum=3b8f19730caa4327:9e102
==== panic kernel thread: 0x2a1015d7cc0 PID: 0 on CPU: 530 ====
cmd: sched
t_procp: 0x187c780(proc_sched)
p_as: 0x187e4d0(kas)
zone: global
t_stk: 0x2a1015d7ad0 sp: 0x18aa901 t_stkbase: 0x2a1015d2000
t_pri: 99(SYS) pctcpu: 0.000000
t_lwp: 0x0psrset: 0 last CPU: 530
idle: 0 ticks (0 seconds)
start: Wed Sep 20 18:17:22 2006
age: 1788 seconds (29 minutes 48 seconds)
tstate: TS_ONPROC - thread is being run on a processor
tflg: T_TALLOCSTK - thread structure allocated from stk
T_PANIC - thread initiated a system panic
tpflg: none set
tsched: TS_LOAD - thread is in memory
TS_DONT_SWAP - thread/LWP should not be swapped
TS_SIGNALLED - thread was awakened by cv_signal()
pflag: SSYS - system resident process
pc: 0x105f7f8 unix:panicsys+0x48: call unix:setjmp
startpc: 0x119fa64 genunix:taskq_thread+0x0: save %sp, -0xd0, %sp
unix:panicsys+0x48(0x7b6e53a0, 0x2a1015d77c8, 0x18ab2d0, 0x1, , , 0x4480001601,
, , , , , , , 0x7b6e53a0, 0x2a1015d77c8)
unix:vpanic_common+0x78(0x7b6e53a0, 0x2a1015d77c8, 0x7b6e3bf8, 0x7080bc30, 0x708
0bc70, 0x7080b840)
unix:panic+0x1c(0x7b6e53a0, 0x7080bbf0, 0x7080bbc0, 0x7b6e4428, 0x0, 0x6000c5fbc
00, , 0x5)
zfs:zio_done+0x284(0x6000c5fbc00)
zfs:zio_next_stage(0x6000c5fbc00) - frame recycled
zfs:zio_vdev_io_assess+0x178(0x6000c5fbc00, 0x6000c586da0, 0x7b6c79f0)
genunix:taskq_thread+0x1a4(0x6000bc5ea38, 0x0)
unix:thread_start+0x4()
_______________________________________________
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
_______________________________________________
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
