From owner-freebsd-current Mon Mar 19 7: 3: 7 2001 Delivered-To: freebsd-current@freebsd.org Received: from mail.iserver1.net.Netz-Werker.NET (srv1.iserver1.net.Netz-Werker.NET [195.122.150.67]) by hub.freebsd.org (Postfix) with ESMTP id 0966A37B719 for ; Mon, 19 Mar 2001 07:03:00 -0800 (PST) (envelope-from tomsoft@Netz-Werker.COM) Received: (from tomsoft@localhost) by mail.iserver1.net.Netz-Werker.NET (8.8.8/8.8.8) id QAA01366; Mon, 19 Mar 2001 16:00:19 +0100 (CET) (envelope-from tomsoft) Message-ID: <20010319160019.63468@Netz-Werker.NET> Date: Mon, 19 Mar 2001 16:00:19 +0100 From: Thomas To: Andrea Campi , Thomas Cc: current@freebsd.org Subject: Re: growfs References: <20010311141337.A510@webcom.it> <20010317110034.62878@Netz-Werker.NET> <20010318165749.A725@webcom.it> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.89i In-Reply-To: <20010318165749.A725@webcom.it>; from Andrea Campi on Sun, Mar 18, 2001 at 04:57:49PM +0100 Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG 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