2008/11/4 Volodymyr Kostyrko <[EMAIL PROTECTED]> > 2008/11/4 Gabriel Lavoie <[EMAIL PROTECTED]>: > > When building this setup I got one big problem. If the root filesystem > (/) > > was on a gjournal provider, an unclean shutdown when data was being > written > > on the disk rendered the system completely unbootable. I got this > message: > > > > GEOM_MIRROR: Device mirror/gm launched (2/2) > > GEOM_JOURNAL: Journal 3672855181: mirror/gma contains data. > > GEOM_JOURNAL: Journal 3672855181: mirror/gma contains journal. > > GEOM_JOURNAL: Journal 3868799910: mirror/gmd contains data. > > > > GEOM_JOURNAL: Journal 3868799910: mirror/gmd contains journal. > > GEOM_JOURNAL: Journal mirror/gmd consistent. > > Just one thing - you have two separate journaled partitions, one > journal per one partition.
Yes, this is the test setup I made with one journal for / and one journal for /usr. Only an unclean journal on / rendered the journal unbootable. An unclean journal on /usr gave me no problem. If I put the journal on the slice level, with the root filesystem over the journal. Resetting the system while writing data on any filesystem causes the problem as the journal is shared to the root filesystem too. > > > > Trying to mount root from ufs:/dev/mirror/gm.journal > > > > Manual root filesystem specification: > > <fstype>:<device> Mount <device> using filesystem <fstype> > > > > eg. ufs:da0s1a > > ? List valid disk boot devices > > <empty line> Abort manual input > > > > > > mountroot> ? > > > > List of GEOM managed disk devices: > > > > mirror/gmd.journal mirror/gmd mirror/gmc mirror/gma mirror/gm > ad10s1c > > ad10s1b ad8s1c ad8s1b ad10s2 ad10s1 ad8s1 ad10 ad8 acd0 > > > > As you can see, in the proposed list of disk devices devices to boot on, > > "mirror/gm.journala" is absent. As I and Ivan Voras, that I contacted > about > > this problem, found, the GEOM_JOURNAL thread that is supposed to mark the > > journal consistent takes too much time to do it with the root > filesystem's > > provider and the kernel try to mount a device that doesn't yet exist. A > bug > > report has been opened about this problem. For my final setup I decided > to > > put the root filesystem on a separate mirrorred slice of 1GB. Since this > > slice isn't often written on, not many rebuilds should occur in case of > > power failure. And I made my "power failure" test by hitting the reset > > button while writing data on this filesystem and the rebuild on 1GB > doesn't > > takes too much time (at most 20-30 seconds). > > Good to hear it, i've fallen for that too, but the machine isn't > powercycled at all and runs on guaranteed power. I had the similar > problems with described setup on virtual test machine too, yet > entering anything at mountroot> prompt gave gjournal a chance to keep > up and needed partition comes up eventually... I didn't reported that, > thought it was a virtual machine issue. > Same thing here, I had a backup installation on another slice and when I gave this one on the prompt, as soon as I hit Enter, GEOM_JOURNAL was marking the journal consistent. I'm happy to hear that I'm not the only one that had this problem. As for my setup. I put / on its own 1GB mirrored slice with auto-synchronization and soft-updates and I put the other filesystems (/home /usr /var /tmp) on a second fully mirrored/journalised slice (with the journal at the slice level), with auto-synchronization on power failure turned off and "async" mount option. As for the bug report, I consider this is an easily reproductible bug and I hope it will be solved soon! :) > > > Now I have the question. Why the "load" algorith wasn't recommended? Is > it > > fixed in 7.0-RELEASE-p5? > > Nope... > > http://www.freebsd.org/cgi/query-pr.cgi?pr=113885 > > -- > Sphinx of black quartz judge my vow. > Gabriel -- Gabriel Lavoie [EMAIL PROTECTED] _______________________________________________ email@example.com mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]"