This last weekend, I converted my /home partition to a journaled filesystem. I did this by dumping it, using gjournal label -f on the partiton, then newfs -J and restore.
So far as I can tell, the result is correct and functional, except for one thing.
Every day, I run a script that does a dump on all of the filesystems at varying levels, but always with -L and -C. /home is the only journaled filesystem, and twice now in the last 5 days, the system has paniced at some point during the process (I can tell this because /etc/dumpdates shows dumps for all the filesystems except this one).
This is a 7.1-RELEASE-p1 system. geom-journal is being loaded as a module.
Despite the fact that I have dumpon set up, I get nothing at all in /var/crash. The first panic was because of "snapacct_ufs2: bad block", but I have no information at all about the panic last night. I only know that I didn't get the cron e-mail I usually get, the uptime of the machine goes back to when /home would have been dumped, and /etc/dumpdates shows that it didn't happen.
I suspect that creating the snapshot is causing the trouble. ffs_mksnap takes a good 10 minutes to complete. The filesystem has about 8 GB of data in it and is well over 200 GB in total size (so over 95% empty).
The machine has 1 GB of total RAM and I used the default 1 GB journal size. I did so because all of the tutorials suggest that the workload on this machine (mail server for 2 people, web) shouldn't require anything extraordinary. If this is being caused by the journal being overrun, would a 'gjournal sync' immediately before the dump help?
The good news is that despite the panics, it appears that the journal is doing its job. 'fsck -n' on the live filesystem doesn't turn up anything unexpected (one unref file and the free block count wrong), and there are no messages in the boot dmesg other than the note that the journal is consistent.
So far as I can tell, the result is correct and functional, except for one thing.
Every day, I run a script that does a dump on all of the filesystems at varying levels, but always with -L and -C. /home is the only journaled filesystem, and twice now in the last 5 days, the system has paniced at some point during the process (I can tell this because /etc/dumpdates shows dumps for all the filesystems except this one).
This is a 7.1-RELEASE-p1 system. geom-journal is being loaded as a module.
Despite the fact that I have dumpon set up, I get nothing at all in /var/crash. The first panic was because of "snapacct_ufs2: bad block", but I have no information at all about the panic last night. I only know that I didn't get the cron e-mail I usually get, the uptime of the machine goes back to when /home would have been dumped, and /etc/dumpdates shows that it didn't happen.
I suspect that creating the snapshot is causing the trouble. ffs_mksnap takes a good 10 minutes to complete. The filesystem has about 8 GB of data in it and is well over 200 GB in total size (so over 95% empty).
The machine has 1 GB of total RAM and I used the default 1 GB journal size. I did so because all of the tutorials suggest that the workload on this machine (mail server for 2 people, web) shouldn't require anything extraordinary. If this is being caused by the journal being overrun, would a 'gjournal sync' immediately before the dump help?
The good news is that despite the panics, it appears that the journal is doing its job. 'fsck -n' on the live filesystem doesn't turn up anything unexpected (one unref file and the free block count wrong), and there are no messages in the boot dmesg other than the note that the journal is consistent.