tunefs question

[Richard Noorlandt]

2007/6/9, Rick C. Petty <rick-freebsd at kiwi-computer.com>:
>
> On Sat, Jun 09, 2007 at 12:30:04AM +0200, Richard Noorlandt wrote:


> > Large filesystems don't seem to be very well
> > supported at the moment.
>
> Where do you arrive at this conclusion?  UFS2 supports large filesystems
> very well.  The only known problems have to do with snapshots and full
> filesystems, and these affect large filesystems as well as small.


It seems true that UFS itself supports large filesystems quite well. What I
actually meant here is the fact that may other parts of the system don't
support it very well. In particular, using growfs poses a bit of a problem.
At the moment one can easily create and operate a large filesystem. But once
you want to grow it, boot from it (ok, true... why would someone want that?)
or perhaps want to do something non-standard with it, you'll tend to run
into trouble. Though I have the idea that this is the case in most current
operating systems and/or programs.

> I hope (and believe) ZFS will settle this. It
>
> Then you are mistaken.  ZFS has large memory requirements, and as you grow
> the filesystem you require more memory.  UFS has a small memory
> footprint...  it only requires memory for one cylinder group (superblock
> plus free bitmaps), plus all indirect blocks, in addition to the
> referenced
> blocks for each file open.


This might be true, but when you use ZFS on a dedicated fileserver this is
less of an issue. Though I haven't really looked into the ZFS details yet.
Using it on FreeBSD in its current state is no option for me anyway.

I also don't see ZFS as a replacement for UFS, but in certain situations I
think they could complement eachother quite well. It's all about picking the
right filesystem for the task at hand, and I'm happy that ZFS adds something
completely different to choose from.

This is not meant to critical to ZFS..  each file system has its own perks
> and problems.  UFS has been tested and used for much longer, at least with
> the default newfs parameters.  Also, it's called fast file system for a
> reason.


A name doesn't define characteristics. The name Fast Filesystem was given to
it years ago, and things change. Though the fact that it was never replaced
could be an indication that it must be a solid performer.

> And when you change the number of inodes at filesystem creation, what
> effect
> > will it have when you run growfs later on? Will it expand the filesystem
> > with an equal inode density, or is it expanded with the default density?
>
> growfs currently doesn't look at inode density.  If you run growfs on a
> filesystem without modifying the size, it will allocate extra metadata
> blocks and could end up failing if the filesystem is nearly full.  growfs
> wasn't developed at the same time as newfs, and the authors decided to
> ignore inode density as an option.  IMO, this is a bug.  Although the
> density is not stored as a parameter in the superblock, it is trivial to
> compute.  Someday I'll probably get around to sending them a patch.


That's bad news, since I was planning to use growfs in the future. From
various growfs related discussions I started to wonder if there is any
coordinated effort to completely revise it. All I see is a bunch of not very
well tested patches, making growfs a very risky tool to use. It would be
great if it was to be completely fixed and debugged, especially because it
is part of the base system. Too bad that I don't have time to delve into it
myself.

I guess I'll refrain from tweaking the filesystem that has to grow in the
future. Too bad for the wasted space, but at the moment I think there are
too many issues involved. For all the other filesystems, your inode advice
is of great help.

Best regards,

Richard