xfs
[Top] [All Lists]

RE: oops umounting full LVM snapshots

To: "FORRESTER,JUSTIN ""(HP-Loveland,ex1)" <justin_forrester@xxxxxx>
Subject: RE: oops umounting full LVM snapshots
From: Steve Lord <lord@xxxxxxx>
Date: 01 Mar 2002 09:07:49 -0600
Cc: Eric Sandeen <sandeen@xxxxxxx>, "'Xfs Mailing \"List (E-mail)'\"" <linux-xfs@xxxxxxxxxxx>
In-reply-to: <Pine.LNX.4.33.0202282101270.20457-100000@lvjf4965.fc.hp.com>
References: <Pine.LNX.4.33.0202282101270.20457-100000@lvjf4965.fc.hp.com>
Sender: owner-linux-xfs@xxxxxxxxxxx
On Thu, 2002-02-28 at 22:18, FORRESTER,JUSTIN (HP-Loveland,ex1) wrote:
> 
> I was able to get rid of the problem with a simple hack to clear out the
> quota flags in the [in-core] sb if we're mounted ro.  The fs shutdown
> problem went away, as did the subsequent oops.  fyi.

We have to be very careful about how we fix this, what happens to the
root filesystem if it has quotas on it? Quotas on root is possible with
XFS, the flags in the superblock tell us we have quotas, but in that
case we are mounted readonly.

This is definitely on the right track though.

Steve

> 
> Justin
> 
> 
> [lvjf4965 #19%] diff -C 15 xfs_mount.c.orig xfs_mount.c
> *** xfs_mount.c.orig    Fri Feb 22 19:47:23 2002
> --- xfs_mount.c Thu Feb 28 20:27:26 2002
> ***************
> *** 942,971 ****
> --- 942,980 ----
>                 cmn_err(CE_WARN, "XFS: failed to read RT inodes");
>                 rvp->v_flag |= VPURGE;
>                 VMAP(rvp, rip, vmap);
>                 VN_RELE(rvp);
>                 vn_purge(rvp, &vmap);
>                 goto error3;
>         }
> 
>         /*
>          * If fs is not mounted readonly, then update the superblock
>          * unit and width changes.
>          */
>         if (update_flags && !(vfsp->vfs_flag & VFS_RDONLY))
>                 xfs_mount_log_sbunit(mp, update_flags);
> 
> +       /*
> +        * HACK - prevent quotas from being used in read-only mode.
> +        * xfs_qm_mount_quotas currently causes xact to occur, which fails
> +        * (badly) on a ro mount.  Quick fix is to just disable quotas on
> +        * ro mounts for now by clearing qflags in in-core sb. --JustinF
> +        */
> +       if (XFS_MTOVFS(mp)->vfs_flag & VFS_RDONLY)
> +               xfs_mount_reset_sbqflags(mp);
> +
>         quotaflags = 0;
>         needquotamount = B_FALSE;
>         quotaondisk = XFS_SB_VERSION_HASQUOTA(&mp->m_sb) &&
>                 mp->m_sb.sb_qflags & (XFS_UQUOTA_ACCT|XFS_GQUOTA_ACCT);
>         /*
>          * Figure out if we'll need to do a quotacheck.
>          * The requirements are a little different depending on whether
>          * this fs is root or not.
>          */
>         rootqcheck = (mp->m_dev == rootdev && quotaondisk &&
>                       ((mp->m_sb.sb_qflags & XFS_UQUOTA_ACCT &&
>                         (mp->m_sb.sb_qflags & XFS_UQUOTA_CHKD) == 0) ||
>                        (mp->m_sb.sb_qflags & XFS_GQUOTA_ACCT &&
>                         (mp->m_sb.sb_qflags & XFS_GQUOTA_CHKD) == 0)));
>         needquotacheck = rootqcheck ||  XFS_QM_NEED_QUOTACHECK(mp);
> 
> 
> 
> 
> On 27 Feb 2002, Eric Sandeen wrote:
> 
> > Ok, with Steve's help I think we're getting this narrowed down.  There
> > seem to be 2 issues:
> >
> > 1) umounting snapshot causes I/O error & filesystem shutdown
> > 2) subsequent oops
> >
> > The first seems to be that when quota is enabled, _mount_ causes a
> > transaction via xfs_qm_mount_quotas.  Now the log is dirty, it must be
> > flushed on umount, but we're ro -> error -> shutdown.
> >
> > The second seems to follow from the first, if after this error LVM frees
> > a buffer that pagebuf subsequently wants to free again, things fall
> > down.  We've seen the oops in various unrelated places.  Not as clear on
> > this one yet, but I'll try error injection over an LVM volume and see
> > what happens.  But if we can fix the first problem, the second will go
> > away in this _particular_ case.  :)
> >
> > FWIW, I have not seen any compiler dependency for this problem yet...
> >
> > -Eric
> >
> 
-- 

Steve Lord                                      voice: +1-651-683-3511
Principal Engineer, Filesystem Software         email: lord@xxxxxxx


<Prev in Thread] Current Thread [Next in Thread>