Date: Sun, 13 Nov 2005 16:49:02 +0100 (CET) From: Oliver Fromme <olli@lurza.secnetix.de> To: freebsd-fs@FreeBSD.ORG Subject: Re: UFS2 snapshots on large filesystems Message-ID: <200511131549.jADFn2s5056445@lurza.secnetix.de> In-Reply-To: <200511071301.jA7D14PT038818@lurza.secnetix.de>
next in thread | previous in thread | raw e-mail | index | archive | help
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)
Best regards
Oliver
--
Oliver Fromme, secnetix GmbH & Co. KG, Marktplatz 29, 85567 Grafing
Dienstleistungen mit Schwerpunkt FreeBSD: http://www.secnetix.de/bsd
Any opinions expressed in this message may be personal to the author
and may not necessarily reflect the opinions of secnetix in any way.
"Python tricks" is a tough one, cuz the language is so clean. E.g.,
C makes an art of confusing pointers with arrays and strings, which
leads to lotsa neat pointer tricks; APL mistakes everything for an
array, leading to neat one-liners; and Perl confuses everything
period, making each line a joyous adventure <wink>.
-- Tim Peters
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200511131549.jADFn2s5056445>