From owner-freebsd-hackers@FreeBSD.ORG Thu Jul 1 06:23:59 2004 Return-Path: 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 5952D16A4CE for ; Thu, 1 Jul 2004 06:23:59 +0000 (GMT) Received: from smtp107.mail.sc5.yahoo.com (smtp107.mail.sc5.yahoo.com [66.163.169.227]) by mx1.FreeBSD.org (Postfix) with SMTP id 33F1F43D5A for ; Thu, 1 Jul 2004 06:23:59 +0000 (GMT) (envelope-from q_dolan@yahoo.com.au) Received: from unknown (HELO ?172.22.1.10?) (q?dolan@203.13.70.60 with plain) by smtp107.mail.sc5.yahoo.com with SMTP; 1 Jul 2004 06:22:46 -0000 In-Reply-To: <1088648757.56400.5.camel@dirk> References: <20040630115340.L806-100000@kozubik.com> <1088648757.56400.5.camel@dirk> Mime-Version: 1.0 (Apple Message framework v618) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <0FAC476E-CB27-11D8-9145-000D9335C6A0@yahoo.com.au> Content-Transfer-Encoding: 7bit From: Q Date: Thu, 1 Jul 2004 16:22:43 +1000 To: Sam Lawrance X-Mailer: Apple Mail (2.618) cc: freebsd-hackers@freebsd.org Subject: Re: writing to RW-mounted UFS2 snapshots - confirmed. X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Jul 2004 06:23:59 -0000 On 01/07/2004, at 12:25 PM, Sam Lawrance wrote: >> This is unexpected. You can successfully mount the snapshot >> read/write and create and write to files in that snapshot. You can >> also write to files that existed in the snapshot prior to mounting it >> read/write. > > Perhaps the writing is done from a point where the schg flag is not > checked or obeyed? While this may not be "expected" behavior, I am curious why this is something that should be prevented, rather than verified for correctness? By "correct" I mean, that the copy on write process is performed correctly and modifications made to the snapshot don't modify the underlying filesystem elements also. To me this has the potential to allow snapshots to be used in reverse as a sort of an "undo drive", similar to unionfs, where you can make changes to a snapshot without the changes being permanently applied to the live filesystem. This might be useful for testing an upgrade or database recovery on a "staging" snapshot before attempting to modify the real thing. -- Seeya...Q -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- _____ / Quinton Dolan - q_dolan@yahoo.com.au __ __/ / / __/ / / / __ / _/ / / Gold Coast, QLD, Australia __/ __/ __/ ____/ / - / Ph: +61 419 729 806 _______ / _\