From owner-freebsd-fs@FreeBSD.ORG Fri Jan 13 14:39:55 2006 Return-Path: X-Original-To: freebsd-fs@freebsd.org Delivered-To: freebsd-fs@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B533B16A41F for ; Fri, 13 Jan 2006 14:39:55 +0000 (GMT) (envelope-from anderson@centtech.com) Received: from mh1.centtech.com (moat3.centtech.com [207.200.51.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1EECF43D8C for ; Fri, 13 Jan 2006 14:39:43 +0000 (GMT) (envelope-from anderson@centtech.com) Received: from [10.177.171.220] (neutrino.centtech.com [10.177.171.220]) by mh1.centtech.com (8.13.1/8.13.1) with ESMTP id k0DEdfYe003418 for ; Fri, 13 Jan 2006 08:39:41 -0600 (CST) (envelope-from anderson@centtech.com) Message-ID: <43C7BBAE.4040600@centtech.com> Date: Fri, 13 Jan 2006 08:39:42 -0600 From: Eric Anderson User-Agent: Thunderbird 1.5 (X11/20060112) MIME-Version: 1.0 To: freebsd-fs@freebsd.org References: <200601131334.k0DDYZEA024957@lurza.secnetix.de> In-Reply-To: <200601131334.k0DDYZEA024957@lurza.secnetix.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.87.1/1239/Thu Jan 12 05:36:22 2006 on mh1.centtech.com X-Virus-Status: Clean Subject: Re: preventing deadlocks in snapshot directories - unexplained X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Jan 2006 14:39:55 -0000 Oliver Fromme wrote: > user wrote: > > I have asked this before, but nobody answered ... > > Many people tend to be reluctant answering questions > from anonymous users (or they don't bother reading their > questions at all). > > > If you have multiple snapshots, how do you segregate them in order to > > avoid the deadlocks that the ".snap" directory is supposed to fix ? > > As far as I know, using that directory is just a matter of > convention. You can place snapshots anywhere else, and it > doesn't make a difference. The only thing special about > ".snap" is that it is created by default by newfs(1), and > it is expected to exist by the snapshot support of the > dump(8) and fsck(8) tools (for dumping live file systems > and background fsck, respectively). > > > I understand why a snapshot is created in (mount)/.snap - but what if I > > have multiple snapshots running simultaneously ? > > It doesn't make a difference. > > > cd /.snap > > rm -rf snap3 > > > > the _entire_ /.snap directory locks up until that command completes. > > Well, yes, certain file system operations are blocked > until the removal of the snapshot is complete, which > can take quite some time, depending on the size of the > file system, because a lot of data has to be updated. > So, that blocking is to be expected (unfortunately). > > > So, this leads me to conclude that actually, I need to do this: > > > > /.snap/snapshot_file > > /.snap2/snapshot_file > > /.snap3/snapshot_file > > No, it doesn't make a difference. As far as I know, the > snapshot code doesn't care about the directory name where > the snapshot files are placed. > Well, its ok to put snapshots anywhere, but when operations on a snapshot file are in progress, stat calls on the snapshot file will block. I think this is his problem. I wonder how painful it would be to have stat's on snapshot files return with (something) when a snapshot operation is in progress, instead of blocking, or even if that is possible. Eric -- ------------------------------------------------------------------------ Eric Anderson Sr. Systems Administrator Centaur Technology Anything that works is better than anything that doesn't. ------------------------------------------------------------------------