Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 20 Oct 2004 19:42:33 +1000
From:      Peter Jeremy <PeterJeremy@optushome.com.au>
To:        Pawel Jakub Dawidek <pjd@freebsd.org>
Cc:        Current <freebsd-current@freebsd.org>
Subject:   Re: panic: swap_pager_isswapped: failed to locate all swap meta blocks
Message-ID:  <20041020094233.GC79646@cirb503493.alcatel.com.au>
In-Reply-To: <20041018085337.GG73767@darkness.comp.waw.pl>
References:  <7m7jqjhojv.wl@black.imgsrc.co.jp> <20040924122508.GG9550@darkness.comp.waw.pl> <20040924143224.GG47816@dan.emsphone.com> <20040925095549.GH9550@darkness.comp.waw.pl> <20040925200747.GE83620@cirb503493.alcatel.com.au> <20041018085337.GG73767@darkness.comp.waw.pl>

next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, 2004-Oct-18 10:53:37 +0200, Pawel Jakub Dawidek wrote:
>+> As an alternative approach, rather than marking swap clean on a
>+> shutdown, why not have a flag in the object's metadata that says "this
>+> object doesn't need synchronising on a reboot".  If the flag is set,
>+> then gmirror just sets both sides as synchronised and active on boot.
>+> This is the approach taken by HP Tru64 LSM.  (Though one improvement
>+> you could make over LSM would be to document the flag).
>
>Such a flag only makes sense for the whole mirror, not selected components,
>right?

The flag would be at the volume level.

>This doesn't fix the case when one has file systems and swap on the same
>mirror, but could be helpful in some cases.

This depends on how you build your filesystems.  If you create a
single vinum volume and use disklabel to partition it, then I agree
that marking the whole volume as "no recovery needed" doesn't help.
If you have multiple vinum volumes with each filesystem/swap on a
distinct volume then a per-volume flag will work.

LSM does not support mixing filesystems and swap on a single volume.
Vinum allows either approach and it's not particularly clear which is
preferable, though there appear to be advantages in avoiding disklabel
(and its limitations).

-- 
Peter Jeremy



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