From mboxrd@z Thu Jan 1 00:00:00 1970 From: Wendy Cheng Date: Mon, 12 Mar 2007 21:15:08 -0500 Subject: [Cluster-devel] [GFS2] Fix bz 224480, pass on the baton for unlinked, but open inodes In-Reply-To: <20070312215615.GB6083@korben.rdu.redhat.com> References: <1173701913.32601.70.camel@quoit.chygwyn.com> <20070312215615.GB6083@korben.rdu.redhat.com> Message-ID: <45F6092C.7070901@redhat.com> List-Id: To: cluster-devel.redhat.com MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Josef Whiter wrote: >On Mon, Mar 12, 2007 at 12:18:33PM +0000, Steven Whitehouse wrote: > > >>Hi, >> >>This is my current patch to fix bz 224480 which survives my torture test >>of setting the drop_count too low and then running postmark. It needs >>wider testing though as it makes a number of changes to the demote code. >> >>This patch removes the memory allocation which was previously required >>in order to queue a demotion request on a glock. This was mentioned in >>bz 221152 as a future objective. Also, this then allows the use of the >>GLF_DEMOTE flag in GFS2's new ->drop_inode() routine to clear the link >>count on the inode (the callback only occurs if another node tries to >>demote the iopen glock for the inode, and this only happens in the case >>that the link count has hit zero). This ensures that inodes which are >>open, but otherwise with zero link count cannot get "lost" unless a node >>crashes (in which case we have another method of recovering the free >>space). >> >> >> > >I've been running this patch while doing other testing and trying to track down >other problems and I haven't seen any issues, so ACK. > > > > I do believe your testing efforts and have no doubts about Steve's technical skills. However, some of previous patches showed we took in patches liberally without any form of technical review. Wrong approaches could shift bugs into subtle and/or difficult to fix states. The scale of this particular patch is non-trivial. Let's have a real review first. -- Wendy