From owner-freebsd-hackers@FreeBSD.ORG  Fri Oct 29 19:56:23 2004
Return-Path: <owner-freebsd-hackers@FreeBSD.ORG>
Delivered-To: freebsd-hackers@freebsd.org
Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125])
	by hub.freebsd.org (Postfix) with ESMTP id B55D416A4CE
	for <freebsd-hackers@FreeBSD.org>;
	Fri, 29 Oct 2004 19:56:23 +0000 (GMT)
Received: from gw.catspoiler.org (217-ip-163.nccn.net [209.79.217.163])
	by mx1.FreeBSD.org (Postfix) with ESMTP id 7956E43D1D
	for <freebsd-hackers@FreeBSD.org>;
	Fri, 29 Oct 2004 19:56:23 +0000 (GMT)
	(envelope-from truckman@FreeBSD.org)
Received: from FreeBSD.org (mousie.catspoiler.org [192.168.101.2])
	by gw.catspoiler.org (8.13.1/8.13.1) with ESMTP id i9TJu8fL027071;
	Fri, 29 Oct 2004 12:56:16 -0700 (PDT)
	(envelope-from truckman@FreeBSD.org)
Message-Id: <200410291956.i9TJu8fL027071@gw.catspoiler.org>
Date: Fri, 29 Oct 2004 12:56:08 -0700 (PDT)
From: Don Lewis <truckman@FreeBSD.org>
To: saggarwa@cs.utah.edu
In-Reply-To: <Pine.GSO.4.50L0.0410291326580.28852-100000@faith.cs.utah.edu>
MIME-Version: 1.0
Content-Type: TEXT/plain; charset=us-ascii
cc: freebsd-hackers@FreeBSD.org
Subject: Re: flushing disk buffer cache
X-BeenThere: freebsd-hackers@freebsd.org
X-Mailman-Version: 2.1.1
Precedence: list
List-Id: Technical Discussions relating to FreeBSD
	<freebsd-hackers.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-hackers>,
	<mailto:freebsd-hackers-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-hackers>
List-Post: <mailto:freebsd-hackers@freebsd.org>
List-Help: <mailto:freebsd-hackers-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-hackers>,
	<mailto:freebsd-hackers-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Fri, 29 Oct 2004 19:56:23 -0000

On 29 Oct, Siddharth Aggarwal wrote:
> 
> Thanks for your reply.
> 
> Hmm. At the moment, the user can send an ioctl to define a checkpoint. But
> I would guess that this could happen between 2 strategy() function calls
> corresponding to the same filesystem operation?

Yes.

> So if there a way to block
> filesystem operations while a snapshot is taken? I can't unmount an active
> filesystem before the snapshot and remount it after. Any suggestions?

Yes, this is done by the following code in ffs_snapshot():

        /*
         * Suspend operation on filesystem.
         */
        for (;;) {
                vn_finished_write(wrtmp);
                if ((error = vfs_write_suspend(vp->v_mount)) != 0) {
                        vn_start_write(NULL, &wrtmp, V_WAIT);
                        vn_lock(vp, LK_EXCLUSIVE | LK_RETRY, td);
                        goto out;
                }
                if (mp->mnt_kern_flag & MNTK_SUSPENDED)
                        break;
                vn_start_write(NULL, &wrtmp, V_WAIT);
        }

I think the snapshot code works at a higher level than what you are
implementing, so I believe that the snapshot code doesn't need to sync
all the files to create a consistent snapshot.  You may run into
problems with syncing unwritten data while writing is suspended, but I'm
not sure because don't understand the code all that well.