[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: [Linux-cluster] gfs2 assertion "!mapping->nrpages" failed on rsync



Hi,

On Wed, 2009-12-02 at 18:25 +0200, Dan Candea wrote:
> On Wednesday 02 December 2009 14:48, Whitehouse Steven wrote:
> --
> Hi,
> 
> On Wed, 2009-12-02 at 14:09 +0200, Dan Candea wrote:
> > hello
> > 
> > randomly , during a nightly backup with rsync I receive the error below on a 
> 3 
> > node setup with cluster2.  because of the withdraw I can't unmount without a 
> > reboot.
> > 
> > does someone have a clue?
> > 
> > 
> > GFS2: fsid=data:FSdata.0: fatal: assertion "!mapping->nrpages" failed
> > GFS2: fsid=data:FSdata.0:   function = gfs2_meta_inval, file = 
> > fs/gfs2/meta_io.c, line = 110
> > GFS2: fsid=data:FSdata.0: about to withdraw this file system
> > GFS2: fsid=data:FSdata.0: telling LM to withdraw
> > GFS2: fsid=data:FSdata.0: withdrawn
> > Pid: 4643, comm: glock_workqueue Not tainted 2.6.28-hardened-r9 #1
> I don't recognise this kernel version, which distro is it from?
> 
> its a kernel with grsecurity applied from gentoo
> 
> 
> Can you reproduce this issue? I've heard of an issue involving rsync,
> but having now tried various different rsync commands, I've not been
> able to reproduce anything that fails.
> 
> 
> I'll try to reproduce it after the reboot, which I have to do it by night, but 
> I'm not sure I'll make something of it, cause the error is spontaneous, while 
> the rsync is ran each day.
> 
Ok. I suspect though that whatever the issue, it has probably been fixed
in more recent kernels, .28 is pretty old now so I'd suggest upgrading
your kernel as one possible solution. I'd be surprised if that doesn't
fix your issue.


[various number removed for brevity]
> >  [<ffffffff802035df>] 0xffffffff802035df
> > 
> This set of numbers is pretty useless without being translated into
> symbols. On the other hand the assertion which you've hit is GFS2
> complaining that its requested that the pages relating to an inode to be
> invalidated, but there are some that have not been removed after that
> invalidation. So in this particular case it doesn't matter,
> 
> 
> 
> Here are you saying that it could be an inconsistency in the FS?
> 
No, its more likely to be an issue in the code. It doesn't look like the
fs is damaged at all, in fact that bug trap is there to prevent damage
to the fs in this particular case,

Steve.



[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]