Comment by OVH - Monday, 14 September 2009, 17:59PM

Le problème se reproduit sur le spare.
Nous cherchons une solution en parallèle de la descente du backup de la nuit dernière sur un autre serveur.


physmem 3ff73e
::status
debugging crash dump vmcore.3 (64-bit) from filerz304
operating system: 5.10 Generic_137138-09 (i86pc)
panic message: assertion failed: 0 == dmu_bonus_hold(os, fuid_obj, FTAG, &db), file: ../../common/fs/zfs/zfs_fuid.c, line: 95
dump content: kernel pages only
$c
vpanic()
0xfffffffffb9f0c63()
zfs_fuid_table_load+0xac()
zfs_fuid_init+0x53()
zfs_fuid_find_by_idx+0x87()
zfs_fuid_map_id+0x47()
zfs_groupmember+0xa2()
zfs_setattr+0xa51()
zfs_shim_setattr+0x15()
fop_setattr+0x25()
rfs3_setattr+0x49c()
common_dispatch+0x5b8()
rfs_dispatch+0x21()
svc_getreq+0x209()
svc_run+0x157()
svc_do_run+0x88()
nfssys+0x16a()
_sys_sysenter_post_swapgs+0x14b()

Comment by OVH - Monday, 14 September 2009, 22:59PM

Nous avons patché le zfs avec un bug fixe qui semble fonctionner.
Le probleme viennait probablement du fait que nous avons copié
les données en direct entre un netapp et le solaris sans passer
par le linux. Et donc la copie a pris en compte les attributes
etendus sur les fichiers. Visiblement on avait les informations
sur le netapp qui faisaient planter le netapp. La situation est
stable désormais.