>>>>> "Andreas" == Andreas Dilger <adilger@clusterfs.com> writes:Andreas> On Aug 08, 2005 21:27 +0200, Roland Fehrenbacher wrote:> I obtain the following, when unmounting the lustre client filesystem > (Lustre 1.4.1, kernel 2.6.12.4 with patches from > https://bugzilla.lustre.org/show_bug.cgi?id=6864) > > [ 339.855698] idr_remove called for id=243680 which is not allocated. > [ 339.863164] > [ 339.863165] Call Trace:<ffffffff80241d95>{sub_remove+261} <ffffffff8024487a>{__up_write+26} > [ 339.874588] <ffffffff80241dbe>{idr_remove+30} <ffffffff801808e9>{kill_anon_super+41} > [ 339.884509] <ffffffff8017fdb6>{deactivate_super+70} <ffffffff801974a8>{sys_umount+152} > [ 339.894601] <ffffffff8024487a>{__up_write+26} <ffffffff8010d9c2>{system_call+126} > [ 339.904149] >>> What could go wrong here? Is this something to worry about? Andreas> This is a bad interaction with ll_common_fill_super() Andreas> overriding the sb-> s_dev value. In newer kernels this Andreas> value is used by the VFS at cleanup time. Formerly, we Andreas> set it to a common value for all clients so that Andreas> clustered NFS export would see the same "device" for all Andreas> clients. Does this mean I can ignore it? Cheers, Roland
>>>>> "Roland" == Roland Fehrenbacher <rf@q-leap.de> writes:>>>>> "Andreas" == Andreas Dilger <adilger@clusterfs.com> writes:Andreas> On Aug 09, 2005 18:45 +0200, Roland Fehrenbacher wrote: Andreas> On Aug 08, 2005 21:27 +0200, Roland Fehrenbacher wrote: >> > I obtain the following, when unmounting the lustre client >> filesystem > (Lustre 1.4.1, kernel 2.6.12.4 with patches from > >> https://bugzilla.lustre.org/show_bug.cgi?id=6864) >> > >> > [ 339.855698] idr_remove called for id=243680 which is not >> allocated. > [ 339.863164] > [ 339.863165] Call >> Trace:<ffffffff80241d95>{sub_remove+261} >> <ffffffff8024487a>{__up_write+26} > [ 339.874588] >> <ffffffff80241dbe>{idr_remove+30} >> <ffffffff801808e9>{kill_anon_super+41} > [ 339.884509] >> <ffffffff8017fdb6>{deactivate_super+70} >> <ffffffff801974a8>{sys_umount+152} > [ 339.894601] >> <ffffffff8024487a>{__up_write+26} >> <ffffffff8010d9c2>{system_call+126} > [ 339.904149] Andreas> This is a bad interaction with ll_common_fill_super() Andreas> overriding the sb-> s_dev value. In newer kernels this Andreas> value is used by the VFS at cleanup time. Formerly, we Andreas> set it to a common value for all clients so that Andreas> clustered NFS export would see the same "device" for all Andreas> clients. >>> Does this mean I can ignore it? Andreas> You can comment out setting of sb->s_dev in Andreas> lustre_common_fill_super() for your kernel. We don''t Andreas> officially support 2.6.12 kernels yet, so it hasn''t been Andreas> fixed in our CVS yet. Roland> I have commented out as follows in Roland> lustre/llite/llite_lib.c Roland> /* sb->s_dev = devno; */ Roland> but the error still appears: Roland> ...... Sorry, false alarm. The problem is fixed. I had the old version of the module loaded by mistake. Thanks for your help Andreas. Cheers, Roland
Hi, Roland Fehrenbacher writes: > (Lustre 1.4.1, kernel 2.6.12.4 with patches from > https://bugzilla.lustre.org/show_bug.cgi?id=6864) [...] > What could go wrong here? Cannot tell, but I just wanted to mention that this bug have been updated recently (see comment #11) and if you are using these patches you should check if you have the update. You use 1.4.1. The fix appeared between 1.4.1 and 1.4.2.1. You may want to update the lustre version, too. Probably to 1.4.4. Regards, -- Solofo.Ramangalahy@bull.net, Bull S.A. | Tel: +33 (0)4 76 29 72 48 Linux R&D, HPC/CI/Lustre | Fax: +33 (0)4 76 61 52 52 1, Rue de Provence. BP208 | Office B1/386 38432 Echirolles Cedex, France | Mail Stop B1/167
On Aug 08, 2005 21:27 +0200, Roland Fehrenbacher wrote:> I obtain the following, when unmounting the lustre client filesystem > (Lustre 1.4.1, kernel 2.6.12.4 with patches from > https://bugzilla.lustre.org/show_bug.cgi?id=6864) > > [ 339.855698] idr_remove called for id=243680 which is not allocated. > [ 339.863164] > [ 339.863165] Call Trace:<ffffffff80241d95>{sub_remove+261} <ffffffff8024487a>{__up_write+26} > [ 339.874588] <ffffffff80241dbe>{idr_remove+30} <ffffffff801808e9>{kill_anon_super+41} > [ 339.884509] <ffffffff8017fdb6>{deactivate_super+70} <ffffffff801974a8>{sys_umount+152} > [ 339.894601] <ffffffff8024487a>{__up_write+26} <ffffffff8010d9c2>{system_call+126} > [ 339.904149] > > What could go wrong here? Is this something to worry about?This is a bad interaction with ll_common_fill_super() overriding the sb->s_dev value. In newer kernels this value is used by the VFS at cleanup time. Formerly, we set it to a common value for all clients so that clustered NFS export would see the same "device" for all clients. Cheers, Andreas -- Andreas Dilger Principal Software Engineer Cluster File Systems, Inc.
On Aug 09, 2005 18:45 +0200, Roland Fehrenbacher wrote:> Andreas> On Aug 08, 2005 21:27 +0200, Roland Fehrenbacher wrote: > > I obtain the following, when unmounting the lustre client filesystem > > (Lustre 1.4.1, kernel 2.6.12.4 with patches from > > https://bugzilla.lustre.org/show_bug.cgi?id=6864) > > > > [ 339.855698] idr_remove called for id=243680 which is not allocated. > > [ 339.863164] > > [ 339.863165] Call Trace:<ffffffff80241d95>{sub_remove+261} <ffffffff8024487a>{__up_write+26} > > [ 339.874588] <ffffffff80241dbe>{idr_remove+30} <ffffffff801808e9>{kill_anon_super+41} > > [ 339.884509] <ffffffff8017fdb6>{deactivate_super+70} <ffffffff801974a8>{sys_umount+152} > > [ 339.894601] <ffffffff8024487a>{__up_write+26} <ffffffff8010d9c2>{system_call+126} > > [ 339.904149] > > > > >> What could go wrong here? Is this something to worry about? > > Andreas> This is a bad interaction with ll_common_fill_super() > Andreas> overriding the sb-> s_dev value. In newer kernels this > Andreas> value is used by the VFS at cleanup time. Formerly, we > Andreas> set it to a common value for all clients so that > Andreas> clustered NFS export would see the same "device" for all > Andreas> clients. > > Does this mean I can ignore it?You can comment out setting of sb->s_dev in lustre_common_fill_super() for your kernel. We don''t officially support 2.6.12 kernels yet, so it hasn''t been fixed in our CVS yet. Cheers, Andreas -- Andreas Dilger Principal Software Engineer Cluster File Systems, Inc.
>>>>> "Andreas" == Andreas Dilger <adilger@clusterfs.com> writes:Andreas> On Aug 09, 2005 18:45 +0200, Roland Fehrenbacher wrote: Andreas> On Aug 08, 2005 21:27 +0200, Roland Fehrenbacher wrote:> > I obtain the following, when unmounting the lustre client filesystem > > (Lustre 1.4.1, kernel 2.6.12.4 with patches from > > https://bugzilla.lustre.org/show_bug.cgi?id=6864) > > > > [ 339.855698] idr_remove called for id=243680 which is not allocated. > > [ 339.863164] > > [ 339.863165] Call Trace:<ffffffff80241d95>{sub_remove+261} <ffffffff8024487a>{__up_write+26} > > [ 339.874588] <ffffffff80241dbe>{idr_remove+30} <ffffffff801808e9>{kill_anon_super+41} > > [ 339.884509] <ffffffff8017fdb6>{deactivate_super+70} <ffffffff801974a8>{sys_umount+152} > > [ 339.894601] <ffffffff8024487a>{__up_write+26} <ffffffff8010d9c2>{system_call+126} > > [ 339.904149]Andreas> This is a bad interaction with ll_common_fill_super() Andreas> overriding the sb-> s_dev value. In newer kernels this Andreas> value is used by the VFS at cleanup time. Formerly, we Andreas> set it to a common value for all clients so that Andreas> clustered NFS export would see the same "device" for all Andreas> clients. >> Does this mean I can ignore it? Andreas> You can comment out setting of sb->s_dev in Andreas> lustre_common_fill_super() for your kernel. We don''t Andreas> officially support 2.6.12 kernels yet, so it hasn''t been Andreas> fixed in our CVS yet. I have commented out as follows in lustre/llite/llite_lib.c /* sb->s_dev = devno; */ but the error still appears: [ 428.336284] idr_remove called for id=243680 which is not allocated. [ 428.343751] [ 428.343751] Call Trace:<ffffffff80241da5>{sub_remove+261} <ffffffff8024488a>{__up_write+26} [ 428.355162] <ffffffff80241dce>{idr_remove+30} <ffffffff801808e9>{kill_anon_super+41} [ 428.365039] <ffffffff8017fdb6>{deactivate_super+70} <ffffffff801974b8>{sys_umount+152} [ 428.375115] <ffffffff8024488a>{__up_write+26} <ffffffff8010d9c2>{system_call+126} [ 428.384695] Cheers, Roland
Hi,
I obtain the following, when unmounting the lustre client filesystem
(Lustre 1.4.1, kernel 2.6.12.4 with patches from
https://bugzilla.lustre.org/show_bug.cgi?id=6864)
[ 339.855698] idr_remove called for id=243680 which is not allocated.
[ 339.863164]
[ 339.863165] Call Trace:<ffffffff80241d95>{sub_remove+261}
<ffffffff8024487a>{__up_write+26}
[ 339.874588] <ffffffff80241dbe>{idr_remove+30}
<ffffffff801808e9>{kill_anon_super+41}
[ 339.884509] <ffffffff8017fdb6>{deactivate_super+70}
<ffffffff801974a8>{sys_umount+152}
[ 339.894601] <ffffffff8024487a>{__up_write+26}
<ffffffff8010d9c2>{system_call+126}
[ 339.904149]
What could go wrong here? Is this something to worry about?
Thanks,
Roland