From owner-freebsd-chat@FreeBSD.ORG Fri Apr 16 07:43:32 2004 Return-Path: Delivered-To: freebsd-chat@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1EB8116A4CE for ; Fri, 16 Apr 2004 07:43:32 -0700 (PDT) Received: from hutcs.cs.hut.fi (hutcs.cs.hut.fi [130.233.192.7]) by mx1.FreeBSD.org (Postfix) with ESMTP id A011D43D41 for ; Fri, 16 Apr 2004 07:43:31 -0700 (PDT) (envelope-from kirma@cs.hut.fi) Received: from kirma (helo=localhost) by hutcs.cs.hut.fi with local-esmtp (Exim 4.30) id 1BEUZ0-0004Dt-C0 for freebsd-chat@freebsd.org; Fri, 16 Apr 2004 17:43:30 +0300 Date: Fri, 16 Apr 2004 17:43:30 +0300 (EEST) From: Jari Kirma To: freebsd-chat@freebsd.org Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: Shadow filesystems [was Re: Pair donates 20,000 to Poul-Henning Kamp??] X-BeenThere: freebsd-chat@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Non technical items related to the community List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Apr 2004 14:43:32 -0000 > Hmmm... that's a coincidence. Is this the same sort of thing as the > 'Shadow Drive' function under Windows 2003? That is, a system that > keeps backup copies of files etc. over time, so if you happen to > accidentally delete something you shouldn't have, you can resurrect it > without having to go running to your Sys-admin to beg them to get it > back from the backup tapes. Sounds conceptually like a slightly more > elaborate version the old VMS file versioning thing, or the GNU > numbered backup trick you can do with emacs etc. I played with the idea of "reliable undelete" functionality some time ago. The essential idea was to reduce those unfortunate cases where a user has created large amounts of creative stuff (in university, that'd be code, essay or something like that at the last minute before the deadline:), and being tired after all work, fumbled and deleted the work in some unbelievably idiotic way. There wouldn't be a trace of it in backups, because the file was created after last backup snapshot and deleted before the next, so, only something like "reliable undelete" would do the work, and probably do it in 95% of those different stupid errors. The main idea was to hook unlink/rename routines so that in some way controlled cases they would actually either move the file to be removed to certain location and a userland daemon would be notified to handle it further, or the file handle would be given to the daemon in some magical way and kernel would wait it to move it. One more addition, hooking of truncate/ftruncate to zero would provide some protection against cp, but that would be more complicated to implement. In essence, this would provide versioned files, although strangely the versions would be snapshots of files at their destruction time... and it wouldn't matter if file existed for a month or a second, version would be generated if wanted. Of course, context switching and disk updates would probably increase, as well as file systems getting filled, and potentially more fragmented due "delayed unlinks." -kirma