From owner-freebsd-hackers Fri Mar 3 13:56:14 2000 Delivered-To: freebsd-hackers@freebsd.org Received: from mail.nyct.net (bsd4.nyct.net [204.141.86.6]) by hub.freebsd.org (Postfix) with ESMTP id 5656A37B568 for ; Fri, 3 Mar 2000 13:56:11 -0800 (PST) (envelope-from mbac@bsd4.nyct.net) Received: from localhost (mbac@localhost) by mail.nyct.net (8.8.8/8.8.7) with SMTP id QAA05416; Fri, 3 Mar 2000 16:55:24 -0500 (EST) (envelope-from mbac@bsd4.nyct.net) Date: Fri, 3 Mar 2000 16:55:24 -0500 (EST) From: Michael Bacarella To: Julian Elischer Cc: David Scheidt , freebsd-hackers@FreeBSD.ORG Subject: Re: Copy-on-write filesystem In-Reply-To: <38C0312A.2781E494@elischer.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > > It wouldn't be. This is how NetApp do their .snapshot direcotries. I think > > they have some white papers on it on their website. It's very handy. > > Kirk McKusick is implementing a Copy-on write functionality > for UFS. It is used in conjunction with Soft updates to produce > snapshots. It's not what you asked for, but still relevant > I think. One problem with "Copy-on-write, when applied to > file copies is that you need to assign the blocks up front, even if you > don't copy the data, as otherwise you could run out of space > when the copy is actually needed. That's the only real drawback I've considered. People accept it (barely) when the OS commits to providing virtual memory it does not have, killing processes when the system falls into debt. No one will appreciate that happening to their "permanent" data, especially if the OS decides that the best way to get out of debt is by deleting a file :) -MB To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message