From owner-freebsd-current@FreeBSD.ORG Fri Jul 22 12:16:57 2005 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 04A9316A433; Fri, 22 Jul 2005 12:16:57 +0000 (GMT) (envelope-from anderson@centtech.com) Received: from mh2.centtech.com (moat3.centtech.com [207.200.51.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6290043D78; Fri, 22 Jul 2005 12:16:34 +0000 (GMT) (envelope-from anderson@centtech.com) Received: from [10.177.171.220] (neutrino.centtech.com [10.177.171.220]) by mh2.centtech.com (8.13.1/8.13.1) with ESMTP id j6MCGVtT089947; Fri, 22 Jul 2005 07:16:33 -0500 (CDT) (envelope-from anderson@centtech.com) Message-ID: <42E0E39E.8020009@centtech.com> Date: Fri, 22 Jul 2005 07:16:30 -0500 From: Eric Anderson User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.7.8) Gecko/20050603 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Thomas E. Zander" References: <42DD64AB.3000605@centtech.com> <20050720094830.GR782@marvin.riggiland.au> <42DE3C1F.9070704@centtech.com> <20050720130523.GT782@marvin.riggiland.au> In-Reply-To: <20050720130523.GT782@marvin.riggiland.au> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-fs@freebsd.org, freebsd-current@freebsd.org Subject: Re: mksnap_ffs takes 4-5 minutes? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Jul 2005 12:16:57 -0000 Thomas E. Zander wrote: > Hi, > > On Wed, 20. Jul 2005, at 6:57 -0500, Eric Anderson wrote > according to [Re: mksnap_ffs takes 4-5 minutes?]: > > >>A 2tb filesystem with the standard newfs options takes about 30 minutes >>to mksnap.. That's unusable really, because the filesystem is suspended >>for so long. Even empty 2tb filesystems take forever, so it's related >>to the amount of inodes. >> >>How can we make this snappier? > > > For the moment we can workaround by setting inode density appropriately > when creating the fs. However this is only feasible if you know what > your users are going to do with the fs; it also doesn't help when you > *need* a large fs containing many small files. > In the long run, dynamic inode (de)allocation would be nice to have. It doesn't seem to make a difference on how much of the filesystem is actually used. It seems to be dependent on how many inodes there are, or maybe more appropriately, how many cylinder groups. > Also...what about the 'preparation' time for snapping? IIRC McKusick > said that the lion's share of snapping time is used to delay pending > transactions before actually doing the snap. > There are quite some scenarios in which you can be certain that there > is no file opened for writing, so a snap could be taken immediately. > Would it be feasible to implement this feature? Or am I completely > wrong? The snap seemed to suspend the filesystem nearly immediately, and kept it suspended for quite some time - I would say probably more than half the time. In order for snapshots to be very useful, it must work on large filesystems (100GB+) in a reasonable amount of time (a few seconds would be ok). I know for certain that one test filesystem (2Tb) had nothing on it, no processess using the filesystem at all, and it took well over an hour to run mksnap on it. Maybe mksnap is broken somehow? Eric -- ------------------------------------------------------------------------ Eric Anderson Sr. Systems Administrator Centaur Technology A lost ounce of gold may be found, a lost moment of time never. ------------------------------------------------------------------------