x86, 1 GB RAM. Issue in 10.0-RELEASE and 10.1-RELEASE. GEOM_JOURNAL UFS2 mount options for file system containing /usr/ports: rw,noatime,async,gjournal Whenever I run "svn update /usr/ports" a kernel panic ensues from UFS corruption, when the system boots, GEOM_JOURNAL thinks everything is peachy, mounts FS consistent even though there is a corruption. If I hit that corrupt dir with "svn update /usr/ports" system panics again. An "fsck -fy /" fails to fix the issue automatically (bad block cannot be written) so I am always forced to go into "fsdb /dev/label/rootfs", "findblk BLOCK", "inode INODE", "clri INODE", "q", "fsck -fy /" to fix the issue. I really want to use "svn" instead of "portsnap" but this repeatable FS corruption issue is preventing me from doing so.
Single PATA disk with GPT partition label, GEOM_ELI, 4 GB journal provider, 65 GB data provider, GEOM_LABEL: /dev/label/rootfs = ada0p4.eli.journal ada0p3.eli: 4 GB journal provider ada0p4.eli: 65 GB data provider FS created with "newfs -J"
STEPS TO REPRODUCE: 1. From a clean and consistent file system # rm -fr /usr/ports # mount -u -o ro / # fsck -fy / # fsck -fy / # mount -u -o rw,noatime,async 2. Checkout ports subversion tree # svn checkout http://svn0.us-east.freebsd.org/ports/head /usr/ports 3. Update ports subversion tree # svn update /usr/ports <=== kernel panic, reboot 4. UFS file system is now corrupt with directory missing `.' and `..' # mount -u -o ro / # fssck -fy / <=== fails to write block # fsck -fy / <=== fails to write block # fsck -fy / <=== fails to write block # fsck -fy / <=== must fix manually # fsdb /dev/label/rootfs <=== marked dirty # fsck -fy / <=== marked clean 5. Glutton for punishment # mount -u -o rw,noatime,async # svn update /usr/ports <==== another kernel panic
Seems to be caused by vfs.unmapped_buf_allowed=1, even though this is a bare metal laptop and not a VM as was reported in the 10 errata. Maybe what I have in common with FreeBSD in a VM is small amount of RAM on my laptop and vfs.unmapped_bufspace is too large for high I/O? Also, when I changed vfs.unmapped_buf_allowed to 0 and rebooted there were further file system corruptions detected during use that were not detected previously when vfs.unmapped_buf_allowed was set to 1, not sure if this is a coincidence. After fsdb clri, fsck -fy, fsck -fy, I was able to run svn update /usr/ports without an error.