Re: bleh. Re: ufs_rename panic

2003-02-21 Thread Yevgeniy Aleynikov
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 [EMAIL PROTECTED

Re: bleh. Re: ufs_rename panic

2003-02-19 Thread Yevgeniy Aleynikov
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.infospaceinc.com Discover what you can do.TM To Unsubscribe: send

Re: patch #3 (was Re: bleh. Re: ufs_rename panic)

2001-10-19 Thread Yevgeniy Aleynikov
. 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 Aleynikov Infospace, Inc. SysAdmin, USE Work: (206)357-4594

Re: bleh. Re: ufs_rename panic

2001-10-11 Thread Yevgeniy Aleynikov
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 = 0101