Skip site navigation (1)Skip section navigation (2)
Date:      Mon, 19 Mar 2001 16:00:19 +0100
From:      Thomas <tomsoft@Netz-Werker.COM>
To:        Andrea Campi <andrea@webcom.it>, Thomas <tomsoft@Netz-Werker.COM>
Cc:        current@freebsd.org
Subject:   Re: growfs
Message-ID:  <20010319160019.63468@Netz-Werker.NET>
In-Reply-To: <20010318165749.A725@webcom.it>; from Andrea Campi on Sun, Mar 18, 2001 at 04:57:49PM %2B0100
References:  <20010311141337.A510@webcom.it> <20010317110034.62878@Netz-Werker.NET> <20010318165749.A725@webcom.it>

next in thread | previous in thread | raw e-mail | index | archive | help
Hi,

> > This was completely untested by us, and is not guaranteed to work! I think
> > you were lucky. We move and change blocks on the filesystem, during some
> > time the filesystem is NOT consitent, so if one of those files is accessed than
> > you might run into a panic.
> Sorry? In single user with a readonly / and nothing else? I would have to be
> EXTREMELY unlucky to get any other access while the fs is inconsistent ;-)
> 
> Seriously, I get the point (shit happens doesn't it?), but this prompts my next
> question: isn't this the same as running fsck? Maybe with growfs we have a
> longer window of inconsistency, but the idea is mostly the same. I think there
> should be (probably there already is) a way to "reserve" access to the fs, so
> that no other process can possibly get an inconsistent state.
It's hard to discuss what type of inconsistency there might be in an corrupted
filesystem, compared to what growfs does. But I definitely change a lot of meta
data of the filesystem, sometimes even the location of those in the filesystem.
As the kernel caches a lot of that information, it might fetch now changed
blocks, which no longer contain metadata, and this could bring your system
in an horrible state.
This way is and remains unsupported!
Since FreeBSD-5 has snapshots, we basically now have a way of locking access
to the filesystem, and also can reload most of the metadata. So there will be
a way of growing even mounted filesystems. There is work ongoing on that, but I
expect this to be rather a redesign of growfs, as I dont wan't to lock
the filesystem for the long time of growing.
The current version seen here will be made 64 bit clean, or lets call it usable
on alpha architecture and then MFCed to STABLE. It basically runs fine on
5.*, 4.*, 3.*, 2.2.* and probably also on 2.1.* 2.0.* and whatever, but this
was never tested.
So the development now focusses on getting it clean on alpha, and maybe support
the existence of snapshots in the filesystem.
There are some ideas already for growing even mounted fileystem, but this
will never enter STABLE.

Thomas

-- 
Th.-H.v.Kamptz
Die Netz-Werker GmbH

To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20010319160019.63468>