Current-Users archive
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: ffs:valloc: dup alloc (in 5.0RC3)
On Mon, 23 Mar 2009, Andrew Doran wrote:
> On Mon, Mar 23, 2009 at 07:52:19AM +0000, Iain Hibbert wrote:
>
> > just updating to 5.0RC3 from a slightly older version and I'm getting a
> >
> > panic: ffs_valloc: dup alloc
> >
> > when trying to build a release. The backtrace is
> >
> > ffs_valloc(
> > ufs_mkdir(
> > VOP_MKDIR(
> > sys_mkdir(
> > syscall(
> ...
> > /usr/src /home/plunky/src union
> > rw,nodev,nosuid,noauto,-b
>
> I have seen unionfs chew up ffs file systems first hand. It gets the vnode
> locking badly wrong. It could be the culprit.
Well, I have seen hangups when using multiple make jobs but its usually ok
using just a single process and I've never seen irredeemable failures.
Also, the way I'm using it, its not creating files on the union path (only
the shadow directories) so perhaps its safe enough for now..
> (I am hoping to rewrite it and nullfs at some point in the future to not care
> about locking but that is part of a larger project and I have no ETA.)
Yes, I thought I had seen a comment to that purpose somewhere (perhaps in
CVS history). Can you see any way around the shadow directory problem?
(that they need to exist, and are created during a directory scan - it
requires bodge code in opendir(3) which I found slightly distasteful)
> > reverting ufs/ffs/ffs_alloc.c to version 1.113 does seem to have cleared
> > the problem (one build complete, started another just now),
>
> That is interesting. Is it reproducable?
Alas, maybe not. I've just completed three full builds with the GENERIC
RC3 kernel and no problems occurred so I'm thinking the it was the phase
of the moon, hrm.
iain
Home |
Main Index |
Thread Index |
Old Index