On Sat, 5 Jan 2008 16:03:55 +0100 Pawel Jakub Dawidek <pjd_at_FreeBSD.org> wrote: > On Wed, Jan 02, 2008 at 11:43:27AM +0900, srwadleigh wrote: > > I am having a strange problem with gjournal on a thinkpad T41, > > > > I am running: 7.0-PRERELEASE - Wed Jan 2 06:05:20 JST 2008 > > And have the problem with both a custom and generic kernel. > > > > If I load gjournal through loader.conf or compile GEOM_JOURNAL into > > the kernel, upon reboot all my slices change, and break booting. > > > > ad0s1a becomes ad0a > > ad0s1d becomes ad0d, and so on.. > > > > If I manually run gjournal load after boot the slices are fine, > > everything works as expected. > > > > Here is my journal setup: > > > > /dev/ad0s1f.journal 64G /usr/home > > > > Geom name: gjournal 2080874044 > > ID: 2080874044 > > Providers: > > 1. Name: ad0s1f.journal > > Mediasize: 70812433920 (66G) > > Sectorsize: 512 > > Mode: r1w1e1 > > Consumers: > > 1. Name: ad0s1f > > Mediasize: 71886176256 (67G) > > Sectorsize: 512 > > Mode: r1w1e1 > > Jend: 71886175744 > > Jstart: 70812433920 > > Role: Data,Journal > > > > > > Doing some research on the list I found a similar problem in the > > past with gmirror, where the slice and device ending at the same > > place was being confused. The solution suggested there seemed to be > > to hardcode the provider names into the metadata. > > > > http://lists.freebsd.org/pipermail/freebsd-stable/2005-May/014448.html > > > > My question is, is this possibly the same issue now with gjournal? > > and is it possible to hardcode provider names after a journal has > > been created? > > Just unmount the file system, stop the journal and call 'gjournal > label' with exactly the sam parameters as originally plus '-h' option. > I will try this, currently my journal is on the same slice as data so I get the used by file system message. I may have to re-configure with a dedicated journal slice so I can use the -f option? Thanks for the help! I will see how it goes. srw
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:39:25 UTC