Bug 195278 - gjournal UFS: svn update /usr/ports panics with corrupt directory emulators/aqemu/files missing `.' and `..'
Summary: gjournal UFS: svn update /usr/ports panics with corrupt directory emulators/a...
Status: New
Alias: None
Product: Base System
Classification: Unclassified
Component: kern (show other bugs)
Version: 10.1-RELEASE
Hardware: i386 Any
: --- Affects Only Me
Assignee: freebsd-bugs mailing list
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2014-11-22 08:14 UTC by Kenneth Salerno
Modified: 2014-11-23 06:45 UTC (History)
0 users

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Kenneth Salerno 2014-11-22 08:14:55 UTC
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.
Comment 1 Kenneth Salerno 2014-11-22 08:36:48 UTC
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"
Comment 2 Kenneth Salerno 2014-11-22 12:12:04 UTC
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
Comment 3 Kenneth Salerno 2014-11-23 06:45:37 UTC
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.