Date: Wed, 20 Jul 2005 15:05:23 +0200 From: "Thomas E. Zander" <riggs@rrr.de> To: Eric Anderson <anderson@centtech.com> Cc: freebsd-fs@freebsd.org, freebsd-current@freebsd.org Subject: Re: mksnap_ffs takes 4-5 minutes? Message-ID: <20050720130523.GT782@marvin.riggiland.au> In-Reply-To: <42DE3C1F.9070704@centtech.com> References: <42DD64AB.3000605@centtech.com> <20050720094830.GR782@marvin.riggiland.au> <42DE3C1F.9070704@centtech.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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. 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? Riggs -- - "[...] I talked to the computer at great length and -- explained my view of the Universe to it" said Marvin. --- And what happened?" pressed Ford. ---- "It committed suicide." said Marvin.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20050720130523.GT782>