From mboxrd@z Thu Jan 1 00:00:00 1970 From: Wendy Cheng Date: Tue, 27 Feb 2007 15:04:25 -0500 Subject: [Cluster-devel] [GFS2 Patch] pass formal ino in do_filldir_main In-Reply-To: <1172510168.3246.16.camel@localhost.localdomain> References: <1170823892.3414.3.camel@d-cthon07-w-63.Connectathon.ORG> <1170845370.11001.417.camel@quoit.chygwyn.com> <1170887711.7725.14.camel@d-cthon07-w-63.Connectathon.ORG> <1170927758.11001.467.camel@quoit.chygwyn.com> <45DFB779.9000100@redhat.com> <1172504728.11001.614.camel@quoit.chygwyn.com> <1172510168.3246.16.camel@localhost.localdomain> Message-ID: <45E48EC9.3020408@redhat.com> List-Id: To: cluster-devel.redhat.com MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Steven Whitehouse wrote: > In the mean time no_formal_ino will still exist, its just that it won't > be used as the lookup key, so theres no on-disk format change to > consider here, all the same fields will continue to have the same > values, so there should be no problem to use it again if required at a > later date, > > ok, as long as we don't rush into removing the code, this is an acceptable plan. We can discuss the issue further when we meet face-to-face next month. In the mean time, will go ahead to make lookup code consistent by tentatively putting no_formal_ino aside. Without the changes, half of the current NFS lookups would fail. We need to have something working right now. I also invite Kent Baxley (one of our TAMs) here to help out with the issue. I recalled he mentioned sometime ago that the "create" table in GFS2-mySQL benchmark was noticeably slow - not sure whether pick_formal_ino() plays any role there. Will give him two gfs2.ko to re-run the benchmark and see what we get. -- Wendy