Skip site navigation (1)Skip section navigation (2)
Date:      Thu, 27 Feb 2003 12:02:31 +1030
From:      Greg 'groggy' Lehey <grog@FreeBSD.org>
To:        Terry Lambert <tlambert2@mindspring.com>
Cc:        kalts@estpak.ee, Darryl Okahata <darrylo@soco.agilent.com>, current@FreeBSD.ORG
Subject:   Re: Vinum R5 [was: Re: background fsck deadlocks with ufs2 and big disk]
Message-ID:  <20030227013231.GB89235@wantadilla.lemis.com>
In-Reply-To: <3E55F7E8.BD5BF990@mindspring.com>
References:  <20030220200317.GA5136@kevad.internal> <200302202228.OAA03775@mina.soco.agilent.com> <20030221080046.GA1103@kevad.internal> <3E55F7E8.BD5BF990@mindspring.com>

next in thread | previous in thread | raw e-mail | index | archive | help

--wq9mPyueHGvFACwf
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline

On Friday, 21 February 2003 at  1:56:56 -0800, Terry Lambert wrote:
> Vallo Kallaste wrote:
>> The crashes and anomalies with filesystem residing on R5 volume were
>> related to vinum(R5)/softupdates combo. The vinum R5 and system as
>> a whole were stable without softupdates. Only one problem remained
>> after disabling softupdates, while being online and user I/O going
>> on, rebuilding of failed disk corrupt the R5 volume completely.
>> Don't know is it fixed or not as I don't have necessary hardware at
>> the moment. The only way around was to quiesce the volume before
>> rebuilding, umount it, and wait until rebuild finished. I'll suggest
>> extensive testing cycle for everyone who's going to work with
>> vinum R5. Concat, striping and mirroring has been a breeze but not
>> so with R5.
>
> I think this is an expected problem with a lot of concatenation,
> whether through Vinum, GEOM, RAIDFrame, or whatever.

Can you be more specific?  What you say below doesn't address any
basic difference between virtual and real disks.

> This comes about for the same reason that you can't "mount -u"
> to turn Soft Updates from "off" to "on": Soft Updates does not
> tolerate dirty buffers for which a dependency does not exist, and
> will crap out when a pending dirty buffer causes a write.

I don't understand what this has to do with virtual disks.

> This could be fixed in the "mount -u" case for Soft Updates, and it
> can also be fixed for Vinum (et. al.).
>
> The key is the difference between a "mount -u" vs. a "umount ; mount",
> which comes down to flushing and invalidating all buffers on the
> underlying device, e.g.:
>
> 	vn_lock(devvp, LK_EXCLUSIVE | LK_RETRY, p);
> 	vinvalbuf(devvp, V_SAVE, NOCRED, p, 0, 0);
> 	error = VOP_CLOSE(devvp, ronly ? FREAD : FREAD|FWRITE, FSCRED, p);
> 	error = VOP_OPEN(devvp, ronly ? FREAD : FREAD|FWRITE, FSCRED, p);
> 	VOP_UNLOCK(devvp, 0, p);
>
> ... Basically, after rebuilding, before allowing the mount to proceed,
> the Vinum (and GEOM and RAIDFRame, etc.) code needs to cause all the
> pending dirty buffers to be written.  This will guarantee that there
> are no outstanding dirty buffers at mount time, which in turn guarantees
> that there will be no dirty buffers that the dependency tracking in
> Soft Updates does not know about.

I don't understand what you're assuming here.  Certainly I can't see
any relevance to Vinum, RAIDframe or any other virtual disk system.

Greg
--
See complete headers for address and phone numbers
Please note: we block mail from major spammers, notably yahoo.com.
See http://www.lemis.com/yahoospam.html for further details.

--wq9mPyueHGvFACwf
Content-Type: application/pgp-signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.0 (FreeBSD)

iD8DBQE+XWqvIubykFB6QiMRAtTtAKCuHFEsQOjC6TyIeiLtV1/Y/bpolQCgiFdA
pEBI06YoRMZ7g35df56xsQI=
=NlIL
-----END PGP SIGNATURE-----

--wq9mPyueHGvFACwf--

To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20030227013231.GB89235>