rssLink RSS for all categories
 
icon_red
icon_green
icon_green
icon_red
icon_red
icon_green
icon_green
icon_red
icon_red
icon_red
icon_red
icon_green
icon_green
icon_red
icon_green
icon_red
icon_green
icon_green
icon_red
icon_red
icon_green
icon_red
icon_green
icon_red
icon_orange
icon_blue
icon_green
icon_green
icon_green
icon_green
icon_green
icon_blue
icon_green
 

FS#3385 — filerz304.mail

Attached to Project— Emails
Incident
tous les emails
CLOSED
100%
Le filer ne démarre plus, peut être un CPU HS.
Dans le doute nous passons sur un spare.

Date:  Tuesday, 15 September 2009, 09:35AM
Reason for closing:  Done
Additional comments about closing:  Un patch a solutionné le problème.
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.