xfs
[Top] [All Lists]

Re: raid1 (u)mount error

To: Steve Lord <lord@xxxxxxx>
Subject: Re: raid1 (u)mount error
From: Chris Wedgwood <cw@xxxxxxxx>
Date: Tue, 10 Sep 2002 11:57:23 -0700
Cc: thomas <tom@xxxxxxxx>, linux-xfs@xxxxxxxxxxx
In-reply-to: <1031683668.22845.102.camel@xxxxxxxxxxxxxxxxxxxx>
References: <527280437.20020910155814@xxxxxxxx> <20020910182241.GA5230@xxxxxxxxxxxxx> <1031682497.22845.97.camel@xxxxxxxxxxxxxxxxxxxx> <20020910184228.GA5323@xxxxxxxxxxxxx> <1031683668.22845.102.camel@xxxxxxxxxxxxxxxxxxxx>
Sender: linux-xfs-bounce@xxxxxxxxxxx
User-agent: Mutt/1.4i
On Tue, Sep 10, 2002 at 01:47:48PM -0500, Steve Lord wrote:

> Hmm, the code I am thinking of went on August 16th, so probably you
> already had it.

Yes, I'm pretty sure I would have.  I will check though.

> So one open for the raid resync, and one for the mount - both of
> those are outside XFS's control.

Yes.

It seems for any other FS other than / you can remount the
raid-superblock RO with "ref == 1" as the reference that is open is
the process calling the ioctl to remount RO.  For / fs, you always
have a second reference and this screws you.

I'm actually not sure how / is supposed to work on RAID so perhaps I
have this wrong.

> The attempt to replay the log by making the filesystem writable in
> the middle of this operation is probably what gets thrown here. We
> remount read/write, run recovery, then remount readonly again,
> finally user space does its own remount read/write.

Possibly, but this should get released again making XFS no different
than any other fs... so I'm not sure XFS is to blame.

I will try to get call-chains from *all* calls to the open on /dev/md0
and see what falls out.  I should probably also get release
information too :)



  --cw


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