Here's the deal:
I striped 2 640GB drives, put GELI on top of that, used gpart to slice up and label 16 partitions, then added journaling to the partitions via gjournal+newfs.
The first hint of a problem was that, after having arranged my fstab file using /dev/gpt labels, they (the /dev/gpt labels) vanished after the next reboot, so I had to re-write fstab in single user mode to use the full /dev/stripe/stripe0.elip[1-16].journal names. It's nasty looking, but it worked reliably since.
Some time later, I decide that the performance of UFS+GJOURNAL isn't great for a fringe case (projects with hundreds of thousands of directories and millions of files), so I decide to scrub the partition and give reiserfs a try (ZFS had also performed miserably).
I unmount the partition, run a [cmd=]gjournal stop[/cmd] on its provider, but the [cmd=]gjournal clear[/cmd] on the consumer fails.
After scratching my head for a few minutes, I see that the original /dev/gtp/foo.journal label had re-appeared! So I repeated the previous gjournal commands on those devices... which caused the original /dev/stripe/ .journal device to reappear.
Rinse, repeat.
So, is there a way to remove the gpt label so this stops happening? I've tried running [cmd=]gpart modify -l "" ...[/cmd] (shows as "null" in a "gpart show" listing) but that didn't help. Even when I stopped the /dev/stripe provider, and there didn't appear to be anything in /dev/gpt, I still could not run [cmd=]gjournal clear[/cmd] or [cmd=]gpart delete[/cmd] or even [cmd=]dd[/cmd] over the device to clear the journal label, as the device was locked/busy.
Short of booting to recovery media to nuke gjournal from that partition when geom_journal is totally unloaded, is there *any* way to fix this mess I've gotten myself into? I've seen allusions to threads talking about the perils of combining gjournal with labels (*after* I tried my dandy new partition scheme, of course), but I have been unable to locate these threads, nor have I been able to find a graceful solution to the problem.
Any ideas?
I striped 2 640GB drives, put GELI on top of that, used gpart to slice up and label 16 partitions, then added journaling to the partitions via gjournal+newfs.
The first hint of a problem was that, after having arranged my fstab file using /dev/gpt labels, they (the /dev/gpt labels) vanished after the next reboot, so I had to re-write fstab in single user mode to use the full /dev/stripe/stripe0.elip[1-16].journal names. It's nasty looking, but it worked reliably since.
Some time later, I decide that the performance of UFS+GJOURNAL isn't great for a fringe case (projects with hundreds of thousands of directories and millions of files), so I decide to scrub the partition and give reiserfs a try (ZFS had also performed miserably).
I unmount the partition, run a [cmd=]gjournal stop[/cmd] on its provider, but the [cmd=]gjournal clear[/cmd] on the consumer fails.
After scratching my head for a few minutes, I see that the original /dev/gtp/foo.journal label had re-appeared! So I repeated the previous gjournal commands on those devices... which caused the original /dev/stripe/ .journal device to reappear.
Rinse, repeat.
So, is there a way to remove the gpt label so this stops happening? I've tried running [cmd=]gpart modify -l "" ...[/cmd] (shows as "null" in a "gpart show" listing) but that didn't help. Even when I stopped the /dev/stripe provider, and there didn't appear to be anything in /dev/gpt, I still could not run [cmd=]gjournal clear[/cmd] or [cmd=]gpart delete[/cmd] or even [cmd=]dd[/cmd] over the device to clear the journal label, as the device was locked/busy.
Short of booting to recovery media to nuke gjournal from that partition when geom_journal is totally unloaded, is there *any* way to fix this mess I've gotten myself into? I've seen allusions to threads talking about the perils of combining gjournal with labels (*after* I tried my dandy new partition scheme, of course), but I have been unable to locate these threads, nor have I been able to find a graceful solution to the problem.
Any ideas?