On Wed, Dec 24, 2008 at 01:06:17AM -0500, Ted Unangst wrote:
> On Tue, Dec 23, 2008 at 11:54 PM, Denis Doroshenko
> <[email protected]> wrote:
> >> even if it worked, you won't be able to run fsck after the fact.
> >
> > could you please be more informative? won't it work because of FFS2 or
> > because of 1.5TB? it seems that the man page for growfs(8) doesn't say
> > a word about FFS2, although it contains a few don't. also, growfs(8)
> > could abort on the filesystem that is obviously not suitable to be
> > grown.
>
> I don't think fsck will be able to allocate enough memory to run, this
> has been mentioned a few times.
>
> As a general matter, I'm a bit of a downer on ffs2 because I think
> it's the wrong solution. FFS was (and is) great for its problem
> domain, but outside the comfort zone it's not so hot.
>
> So I'd advise not making such large filesystems, regardless of whether
> it can be made to work or not in a particular situation.
>
> As for growfs, it generally requires a degree of foresight one doesn't
> have, or tricksy games afterward.
>
> The tools are provided because they may be of use, but that's not to
> imply OpenBSD is the ideal multi-terabyte file server.
>
> That's my opinion anyway.
In general I tend to agree with tedu. Though you can reduce the
fsck_ffs memory usage by using larger fragment and/or block sizes. But
of course growfs cannot change them after initial newfs.
Considering the buggy output, I'd say growfs has never been tested
very well since the move to 64-bit block numbers. I could blame
myself, but I keep forgetting that growfs even exists. I avoid it.
-Otto
