Date: Tue, 30 Sep 2003 16:44:30 -0700 From: "Kevin Oberman" <oberman@es.net> To: "Marc G. Fournier" <scrappy@hub.org> Cc: Lukas Ertl <l.ertl@univie.ac.at> Subject: Re: Improvements to fsck performance in -current ...? Message-ID: <20030930234430.BF3905D07@ptavv.es.net> In-Reply-To: Message from "Marc G. Fournier" <scrappy@hub.org> <20030930202715.C94686@ganymede.hub.org>
next in thread | previous in thread | raw e-mail | index | archive | help
> Date: Tue, 30 Sep 2003 20:28:20 -0300 (ADT) > From: "Marc G. Fournier" <scrappy@hub.org> > > > > On Wed, 1 Oct 2003, Lukas Ertl wrote: > > > > are either of these enhancements back-patchable to the 4.x fsck, or do > > > they require some non-4.x compatible changes to work? > > > > It's not just the fsck application itself, background fsck basically needs > > file system snapshots, which are only available on UFS2, and I'm not sure > > if they can be backported to UFS1 at all. > > Ah, okay, so when I move my servers to 5.x, then I'm going to need to > reformat the systems from scratch, else I lose some serious improvements > ... is there a list somewhere of what UFS2 has over UFS1? "file system > snapshots", is that similar to journalling? I think this is wrong. I have seen no issue in snapshots or background fsck with UFS1 volumes. And, if you mean "jounalling" as in jfs, no. As I understand it, snapshot is an atomic capture of the file system metadata which allows fsck to analyze and repair it on an active file system. (Note: This only applies to softupdate enabled systems as softupdates assure a level of consistency in the metadata that assures that fsck will not make changes to active file space on the file system. To get to UFS2, you must newfs the partition. I don't know of nay other way. The basic improvement in UFS2 is the expansion of many fields to 64 bits to allow for much larger structures. While newfs in V5.1 and CURRENT defaults to UFS2, there are no problems continuing to run UFS1 file systems. Finally, I don't think there is any issue any longer with using soft updates on /. The only reason that root did not default to SU under V4 is that SU disks only periodically update free space information and a small root partition can fill up during an installworld when all of the files in (especially) /sbin are replaces which requires enough space to hold two copies of the directory. Under the default partition sizes in V5, this is really not an issue and all partitions created by sysinstall under V5 will default to SU, including /. If I got some of this wrong, I hope someone will correct it, but I am pretty sure I'm close. -- R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: oberman@es.net Phone: +1 510 486-8634
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20030930234430.BF3905D07>