.sujournal

J

jb_fvwm2

I've filesystems with .sujournal present, but it cannot be removed to re-enable the SUJ, and is not present unless the filesystem is mounted, but is not "active". tunefs suggests a fsck_ffs but then it again refuses. Any one ever fixed something similar? It hardly every fsck's but I'd like to "regularize" it.
 
Maybe disable softupdates, too?

Hmm...keep trying? I'm pretty sure I've deleted this file with a simple `rm .sujournal`, but I forget exactly how. My context is that in 9.0/9.1, FreeBSD reminds me politely that I can't dump snapshots while using soft updates. I *think* my solution was to disable softupdates journaling using tunefs, then disable softupdates, then mount the filesystem read-write, then delete the .sujournal file. For me, I could then dump a snapshot.

But it's been a while. My current solution is to not use snapshots, instead dumping filesystems that are mounted read-only, and otherwise let softupdates journaling do its thing.
 
You can use snapshots with soft updates but not with the soft update journaling. Make sure you have the journal disabled and then try to delete the .sujournal file, if that fails try to delete it in single user mode.
 
Fixed it per mount but not per dmesg. ('no provider below" iirc). Maybe I'll post more should it fsck unexpectedly and not recover using the journal.
 
Were you able to remove .sujournal and use softupdates journaling again on this file system, though?

If I enable SUJ and leave it alone, it will recover from crashes each and every time. But if the journal disagrees with the file system in certain ways, fsck will skip the journal and fall through to full fsck. The easiest way to provoke this behavior is to unmount a file system, then run fsck_ufs on that file system twice.

Otherwise, I don't have enough information to state anything else. "no provider below" makes me think you're having a geom issue of some kind, and that could be a separate issue.
 
You must log in or register to reply here.
Back
Top