the race cannot occur.
If this proves to be too much of a slow down, it would be possible
to only serialize directory renames. As these are (presumably) much
rarer the slow down would be less noticable.
Kirk McKusick
=-=-=-=-=-=
Date: Wed, 19 Feb 2003 15:10:09 -0800
From: Yevgeniy Aleynikov <[EM
e panics is utterly
trivial and I will commit it after I test it.
-Matt
--
Yevgeniy Aleynikov | Sr. Systems Engineer - USE
InfoSpace INC 601 108th Ave NE | Suite 1200 | Bellevue, WA 98004
Tel 425.709.8214 | Fax 425.201.6160 | Mobile 425.418.8924
[EMAIL PROTECTED] | http://www.infospac
ogress at any time. This method is
> used by GFS and probably Linux. This could make the code simply. Maybe
> we can even get rid of the relookup() stuff.
>
> This may reduce concurrency, but rename should not be a frequent
> operation.
>
--
Yevgeniy Aleyniko
Here's another stable panic (not very often but on different boxes too).
--
Yevgeniy Aleynikov
Infospace, Inc.
SysAdmin, USE
Work: (206)357-4594
SMP 2 cpus
IdlePTD 3039232
initial pcb at 2666a0
panicstr: ffs_valloc: dup alloc
panic messages:
---
panic: ffs_valloc: dup alloc
mp_lock = 010
So, it seems to me that the correct fix is to
> *not* release the source after looking it up, but rather hold it
> locked while we look up the destination. We can completely get
> rid of relookup and lots of other hairy code and generally make
> rename much simpler. Am I missing some
5 matches
Mail list logo
