From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jaegeuk Kim Subject: Re: [PATCH 5/5] f2fs: Fix for parent inode information during server cache eviction Date: Mon, 10 Dec 2012 16:19:35 +0900 Message-ID: <1355123975.7291.88.camel@kjgkr> References: <1354946143-7730-1-git-send-email-linkinjeon@gmail.com> <1355100235.7291.52.camel@kjgkr> <1355114244.7291.60.camel@kjgkr> <1355122818.7291.82.camel@kjgkr> Reply-To: jaegeuk.kim@samsung.com Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-eFwRs81fQDt1jvRw8YY/" Cc: linux-fsdevel@vger.kernel.org, linux-f2fs-devel@lists.sourceforge.net, Namjae Jeon , Amit Sahrawat To: Namjae Jeon Return-path: Received: from mailout4.samsung.com ([203.254.224.34]:15783 "EHLO mailout4.samsung.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751910Ab2LJHTm (ORCPT ); Mon, 10 Dec 2012 02:19:42 -0500 Received: from epcpsbgm1.samsung.com (epcpsbgm1 [203.254.230.26]) by mailout4.samsung.com (Oracle Communications Messaging Server 7u4-24.01(7.0.4.24.0) 64bit (built Nov 17 2011)) with ESMTP id <0MET009790CI5P60@mailout4.samsung.com> for linux-fsdevel@vger.kernel.org; Mon, 10 Dec 2012 16:19:40 +0900 (KST) Received: from [12.52.126.105] by mmp2.samsung.com (Oracle Communications Messaging Server 7u4-24.01(7.0.4.24.0) 64bit (built Nov 17 2011)) with ESMTPA id <0MET00EFE0CSQU40@mmp2.samsung.com> for linux-fsdevel@vger.kernel.org; Mon, 10 Dec 2012 16:19:40 +0900 (KST) In-reply-to: Sender: linux-fsdevel-owner@vger.kernel.org List-ID: --=-eFwRs81fQDt1jvRw8YY/ Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 2012-12-10 (=EC=9B=94), 16:11 +0900, Namjae Jeon: > 2012/12/10, Jaegeuk Kim : > > 2012-12-10 (=EC=9B=94), 14:25 +0900, Namjae Jeon: > >> 2012/12/10, Jaegeuk Kim : > >> > 2012-12-10 (=EC=9B=94), 12:40 +0900, Namjae Jeon: > >> >> 2012/12/10, Jaegeuk Kim : > >> >> > 2012-12-08 (=ED=86=A0), 14:55 +0900, Namjae Jeon: > >> >> >> From: Namjae Jeon > >> >> >> > >> >> >> Test Case: > >> >> >> [NFS Client] > >> >> >> ls -lR . > >> >> >> > >> >> >> [NFS Server] > >> >> >> while [ 1 ] > >> >> >> do > >> >> >> echo 3 > /proc/sys/vm/drop_caches > >> >> >> done > >> >> >> > >> >> >> Error: "No such file or directory" > >> >> >> > >> >> >> When cache is dropped at the server, it results in lookup failur= e > >> >> >> at > >> >> >> the > >> >> >> NFS client. Even though the file exists. Looking at the code to > >> >> >> rebuild > >> >> >> the inode in case of cache eviction. It tries to initiate a look= up > >> >> >> operation > >> >> >> for ".." to get the parent information using the on-disk inode > >> >> >> number. > >> >> >> > >> >> > > >> >> > Could you describe why this patch resolves that bug? > >> >> > Before applying this, we need to figure out why that bug is > >> >> > occurred. > >> >> > IMO, from the viewpoint of functionality, ".." resolution should > >> >> > work > >> >> > too. > >> >> dotdot entry of f2fs is stored when creating only directory not > >> >> regular file. Am I correct ? > >> > > >> > Yep. > >> > > >> >> So when the parent of file was evicted, I thought we could not get > >> >> parent inode number of file thoughout dotdot entry. > >> > > >> > What do you mean the parent of file? Isn't it a directory? > >> > > >> >> And f2fs inode is having parent inode number unlike other fs. so I > >> >> think we can use this special thing by storing f2fs_inode_info. > >> > > >> > f2fs stores a dotdot dentry *likewise* other fs. > >> > The pino in f2fs_inode is specially added for POR intentionally. > >> > > >> > Still I cannot imagine the bug scenario. > >> When we observed the issue in NFS operations. We found that the issues > >> occurs while trying to =E2=80=9Creconnect=E2=80=9D with parent ? and s= hows =E2=80=9CNo such > >> file or directory=E2=80=9D for directory paths. > > > > Again, you didn't describe why this bug is occurred. > > Please, analyze the bug scenario first. > Okay, I will look into more. > > > >> > >> As a matter of fact - we were also checking the on-disk layout for the > >> f2fs_inode. We found that since, F2FS inode is keeping a reference to > >> the parent-inode within its on-disk information. So, we should use the > >> same information to reconstruct the parent in case of eviction. > >> > >> The benefit is: > >> It also saves the lookup() to be performed for =E2=80=9C..=E2=80=9D in= the directory > >> entry block while trying to reconnect with the parent. Instead we can > >> directly use the parent inode number in the inode and generate from > >> that point itself. Even though the get_parent() code was made similar > >> to other filesystem which generally do not have reference to the > >> parent inode - so they need to perform a lookup for =E2=80=9C..=E2=80= =9D, but in this > >> case we sincerely thought we can get rid of that method. > >> So, we did not tried to figure out what could be possible solution in > >> the current scenario. > >> As per your reference, parent inode number for on-disk inode is > >> introduced for POR intentionally. So, we should not use information > >> for any reconstruction? > > > > Of course, we can enhance the directory operations by using the "pino". > > But what I concern is how to resolve the bug by this enhancement patch. > > This is not a bug fix patch. Isn't it? > Yes, It is not bug fix. this is new method using f2fs's special thing. > Agreed, I will analyse why this bug occur first. let's discuss again > whether we fix bug or use new method. >=20 > And please check the rest of patches except this patch. Other patches look good to me. And I'm testing and seeing the codes one more time. Thank you for contribution. :) >=20 > Thanks. > > > > Thanks, > > > > -- > > Jaegeuk Kim > > Samsung > > --=20 Jaegeuk Kim Samsung --=-eFwRs81fQDt1jvRw8YY/ Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) iQIcBAABAgAGBQJQxY0HAAoJEEAUqH6CSFDSqwcP/0YZ9+6MR74lPwgv3MRhhBnz VEHL1HKjFAj5jEJQz562A7z/evDP8mBGAU4jdDPNuekSEVvajaFap4rapQdwHkMO c8aeI2g8n3VHemBmvTTuPdfQ+E+MVAoexFU+v+VaTNuCuwPuEDqWAgAtDJumTr5M TLfpV6FiabY0DxMcPzoCYuu5MYxwOtwXxP2EeuJIchR/Hi1TcC6XNhLoViQDu9Tx MD1aeBxwHo4/Ck+WgD6765UWmZpHabR1lQD3MICPfE/OsmqyrG9dwS+hGF+7UP2N UAbu6/CZ/0oB9KGTIjYgqauXFsKBODFfR3CXmojd8pTN6wGJnEqg5KSl3X23W8wC 28memPcaTlGpO8Zg+MDaqkPzmgFVpbIHehpGnkwv6nuiFHKI+PJZKnuCH7arROPL fw+zqAzm/aHGpA0t/UZLJQx4CZYFzOzfZK5622a0KFYlJFYUPTEVTa5TItvfXz/l 2Ti9RhyxgzNI+Q1blrSpb6JLN59WssS1gbr7OrCHAy1RDp7EE9uMRz9oZWGpgiGL KDhJuYMiobtU2ETTuv5x1CyK/n7ljIln8LVvvaHEuflxx4AKCvRh+GP2goX/5St1 vmW7l12oTeBv2kqa/KhS8m3eewOtTJl0MHNIGnhpmcmBdO3OqBK+M8253GiieNw9 LizOVcXyuz25kMXdRFob =yOcK -----END PGP SIGNATURE----- --=-eFwRs81fQDt1jvRw8YY/--