Date: Sun, 13 Nov 2005 14:14:41 -0600 From: Eric Anderson <anderson@centtech.com> To: freebsd-fs@freebsd.org Subject: Re: UFS2 snapshots on large filesystems Message-ID: <43779EB1.5070302@centtech.com> In-Reply-To: <200511131549.jADFn2s5056445@lurza.secnetix.de> References: <200511131549.jADFn2s5056445@lurza.secnetix.de>
next in thread | previous in thread | raw e-mail | index | archive | help
Oliver Fromme wrote: > Oliver Fromme <olli@lurza.secnetix.de> wrote: > > user <user@dhp.com> wrote: > > > On Sun, 6 Nov 2005, Eric Anderson wrote: > > > > [fsck on large file systems taking a long time] > > > > > > Can you elaborate ? Namely, how long on the 2GB filesystems ? > > > > It depends very much on the file system parameters. In > > particular, it's well worth to lower the inode density > > (i.e. increase the -i number argument to newfs) if you > > can afford it, i.e. if you expect to have fewer large > > files on the file system (such as multimedia files). > > I just accidentally pulled the wrong power cord ... > So now I can give you first-hand numbers. :-} > > This is a 250 Gbyte data disk that has been newfs'ed > with -i 65536, so I get about 4 million inodes: > > Filesystem iused ifree %iused > /dev/ad0s1f 179,049 3,576,789 5% > > So I still have 95% of free inodes, even though the > filesystem is fairly good filled: > > Filesystem 1K-blocks Used Avail Capacity > /dev/ad0s1f 237,652,238 188,173,074 30,466,986 86% > > fsck(8) took about 2 minutes, which is acceptable, I > think. Note that I always disable background fsck > (for me personally, it has more disadvantages than > advantages). > > This is what fsck(8) reported when the machin came > back up: > > /dev/ad0s1f: 179049 files, 94086537 used, 24739582 free > (26782 frags, 3089100 blocks, 0.0% fragmentation) 180k inodes seems like a pretty small amount to me. Here's some info from some of my filesystems: # df -i Filesystem 1K-blocks Used Avail Capacity iused ifree %iused Mounted on /dev/amrd0s1d 13065232 1109204 10910810 9% 663 1695079 0% /var /dev/label/vol1 1891668564 1494254268 246080812 86% 68883207 175586551 28% /vol1 /dev/label/vol2 1891959846 924337788 816265272 53% 59129223 185364087 24% /vol2 /dev/label/vol3 1892634994 1275336668 465887528 73% 31080812 213506706 13% /vol3 Even /var has over 1million. I think your tests are interesting, however not very telling of many real-world scenarios. Eric -- ------------------------------------------------------------------------ Eric Anderson Sr. Systems Administrator Centaur Technology Anything that works is better than anything that doesn't. ------------------------------------------------------------------------
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?43779EB1.5070302>