Automated nightly backup hung during mksnap_ffs call from dump; all I/O to that disk blocked in a "D" state. System was otherwise functional. There were no errors in the system logs or on the console and the raid adapter was fully function. Raw I/O to the disk devices (e.g. reads of the "c" partition of the disk that was wedged) remained fully functional during the event. Disk adapter is a 3ware 9650; firmware FE9x 4.08.00.006, driver 3.70.05.001, BBU enabled. It has no faults recorded against it or the drives attached to it. Looks like a race condition/deadlock of some sort in the mksnap_ffs code. The only unique "feature" of this event was that the disk in question was a DBMS storage RAID array and had a VERY large (many thousands of files) directory on it containing the log segments (typically ~1-2MB each, compressed, sequential log files numbering many thousand.) System was unable to be cleared; mksnap_ffs could not be killed and ultimately the machine had to be forcibly rebooted without a sync(). How-To-Repeat: Attempting to replicate at this time. Will update the PR if I am able to do so. The subject machine had been up for more than six months at the time of the fault, and it has not reoccurred as of submission of this PR. Migration to 8.1 on this cluster is taking place, but I am going to put in a significant amount of time in attempting to replicate the problem on 8.0-STABLE (same kernel and binaries) on my test cluster to see if I can provoke the failure; I have an isolated environment in which I can make a decent attempt at recreating the event.
Responsible Changed From-To: freebsd-ia64->freebsd-bugs uname(1) output states amd64 as the platform, so ia64 is not the right category. Since this is very likely not amd64-specific, change category to kern. Update responsible accordingly.
Responsible Changed From-To: freebsd-bugs->freebsd-fs Over to maintainer(s).
Hi as adviced here http://unix.derkeiler.com/Mailing-Lists/FreeBSD/stable/2008-11/msg00210.html I think you need to add > + if (cg % 10 == 0) > + ffs_syncvnode(vp, MNT_WAIT); in any loop, because of depend on size of disk look can take long time. so: --- ffs_snapshot.c.orig 2011-12-09 06:45:11.000000000 +0000 +++ ffs_snapshot.c 2011-12-09 06:49:43.000000000 +0000 @@ -305,7 +305,7 @@ ip->i_flag |= IN_CHANGE | IN_UPDATE; error = readblock(vp, bp, numblks - 1); bawrite(bp); - if (error != 0) + if (error != 0) // why not just if( error ) ??? goto out; /* * Preallocate critical data structures so that we can copy @@ -324,6 +324,10 @@ if (error) goto out; bawrite(ibp); + if (blkno % 10 == 0) + ffs_syncvnode(vp, MNT_WAIT); + if (error) // to be same as line 385 + goto out; } /* * Allocate copies for the superblock and its summary information. @@ -341,6 +345,10 @@ if (error) goto out; bawrite(nbp); + if (loc % 10 == 0) + ffs_syncvnode(vp, MNT_WAIT); + if (error) //to be same as line 385 + goto out; } /* * Allocate all cylinder group blocks. @@ -353,6 +361,8 @@ bawrite(nbp); if (cg % 10 == 0) ffs_syncvnode(vp, MNT_WAIT); + if (error) //to be same as line 385 + goto out;. } /* * Copy all the cylinder group maps. Although the but I not shure. Please confirm -- Ñ óâàæåíèåì, Êîíüêîâ mailto:kes-kes@yandex.ru
For bugs matching the following criteria: Status: In Progress Changed: (is less than) 2014-06-01 Reset to default assignee and clear in-progress tags. Mail being skipped