hi,
On Sun, Sep 16, 2001 at 06:18:29PM +0900, ASANO Masahiro wrote:
> On Fri, 14 Sep 2001 11:14:30 +1100, Nathan Scott wrote:
> > On Thu, Sep 13, 2001 at 10:49:33PM +0900, ASANO Masahiro wrote:
> > > I cannot mount the snapshot filesystem of the XFS filesystem.
> > > To make the snapshot, I used xfs_freeze. Why it couldn't be mounted?
> > >
> > > # lvcreate -L 132m -n masano1 vg0
> > > # mkfs.xfs /dev/vg0/masano1
> > > # mount -t xfs /dev/vg0/masano1 /mnt/masano1
> > > # xfs_freeze -f /mnt/masano1
> > > # lvcreate -L 60m -n masano2 -s /dev/vg0/masano1
> > > # xfs_freeze -u /mnt/masano1
> > > # mount -t xfs -o ro,nouuid /dev/vg0/masano2 /mnt/masano2
> > >
> > > XFS mounting filesystem lvm(58,1)
> > > XFS: WARNING: recovery required on readonly filesystem.
> > > XFS: write access unavailable, cannot proceed.
>
> > In your case, it seems the driver has marked /dev/vg0/masano1
> > as readonly (I don't know why that would be - looks like LVM).
>
> Nope. The readonly error occurred on "/dev/vg0/masano2" (snapshot
> side).
Sorry - my mistake - thats what I meant (the snapshot).
> I tried to mount /dev/vg0/masano2 with "-o ro", so it is
> readonly.
No, that doesn't mark the _device_ readonly it marks the
_filesystem_ readonly. Journaling filesystems override
this temporarily during mount if the log must be replayed.
But if the device is readonly (as is the case with a snap-
shot), then that overriding cannot happen, the log cannot
be replayed, and so the filesystem cannot be mounted.
It sounds like the problem is that the log was not dirty
previous to this mod, but it is now still dirty on the
snapshot (and it shouldn't be).
> "/dev/vg0/masano1" seems writable.
>
> lvm(58,0) >> /dev/vg0/masano1 >> original fs
> lvm(58,1) >> /dev/vg0/masano2 >> snapshot (ro)
>
> But the snapshot could be mounted with this sequence before 28th Aug.
>
> > > I noticed this may be occurred from "8/28 Merge irix6.5f:irix:101630a".
>
> I looked into xfs_recover() and found that the condition
> "(tail_blk != head_blk)" in xfs_recover() at fs/xfs/xfs_log_recover.c
> changed to true with adding xfs_fs_log_dummy() at fs/xfs/xfs_fsops.c.
> Is it right?
That condition basically equates to "do I need to do recovery".
Sounds like previously (and correctly I think) this would have
been false on the snapshot, but now it is true (ie. the snapshot
has a dirty log - bad).
Eric? Sounds like this mod may have introduced an XFS
bug in Linux...
thanks.
--
Nathan
|