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:00:18 +0900 Message-ID: <1355122818.7291.82.camel@kjgkr> References: <1354946143-7730-1-git-send-email-linkinjeon@gmail.com> <1355100235.7291.52.camel@kjgkr> <1355114244.7291.60.camel@kjgkr> Reply-To: jaegeuk.kim@samsung.com Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-DLedWhmgv3NDzB/bwrRA" Cc: linux-fsdevel@vger.kernel.org, linux-f2fs-devel@lists.sourceforge.net, Namjae Jeon , Amit Sahrawat To: Namjae Jeon Return-path: Received: from mailout1.samsung.com ([203.254.224.24]:29161 "EHLO mailout1.samsung.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752174Ab2LJHA3 (ORCPT ); Mon, 10 Dec 2012 02:00:29 -0500 Received: from epcpsbgm1.samsung.com (epcpsbgm1 [203.254.230.26]) by mailout1.samsung.com (Oracle Communications Messaging Server 7u4-24.01(7.0.4.24.0) 64bit (built Nov 17 2011)) with ESMTP id <0MES00CBFZFUZV80@mailout1.samsung.com> for linux-fsdevel@vger.kernel.org; Mon, 10 Dec 2012 16:00:23 +0900 (KST) Received: from [12.52.126.105] by mmp1.samsung.com (Oracle Communications Messaging Server 7u4-24.01(7.0.4.24.0) 64bit (built Nov 17 2011)) with ESMTPA id <0MES00FHXZGN1590@mmp1.samsung.com> for linux-fsdevel@vger.kernel.org; Mon, 10 Dec 2012 16:00:23 +0900 (KST) In-reply-to: Sender: linux-fsdevel-owner@vger.kernel.org List-ID: --=-DLedWhmgv3NDzB/bwrRA Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 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 failure a= t > >> >> 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 lookup > >> >> operation > >> >> for ".." to get the parent information using the on-disk inode numb= er. > >> >> > >> > > >> > 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 wor= k > >> > 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 show= s =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. >=20 > 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. >=20 > The benefit is: > It also saves the lookup() to be performed for =E2=80=9C..=E2=80=9D in th= e 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? Thanks, --=20 Jaegeuk Kim Samsung --=-DLedWhmgv3NDzB/bwrRA 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) iQIcBAABAgAGBQJQxYiDAAoJEEAUqH6CSFDSO8QQAIMBeBWmkxWCI27ty+WQc1rS 7dayGgllFP4vjdUgjVBfI7FOQN32cqViEcIzsLsUEIG7OyaeijN418KlXxZ7HRHb 2d/onm+GuKbtmfyCE2ROqclwRROYEceN+LvYt9IBB1p8qSQbjQrHrUoTHXqcxWYg shfQKLcvEENvga0yPUzJjzqkuzhzZ30vnZwi6whgBxQRbdFEHIoO5EznJ3L/rxkh pORNUHEO++C4wY42YSbSBvwswc7QyrIUw7FPjLyjFnrEMAbHPUwnwwtPQ9t+gW3C VPkGU8FBbWcJtiAbcvJHB46Ze6J6A0lOHdGal4GEDIFCNw3bHbdlb3JU6Gb1z1WF Dgiu/kg7bWf2lPwcvQVCyM17aTuRYaLruS5Oud6VXt1zNp14VKrnAFKkQwsbGBWm xTH7krJIqNVwce5y6NHKFQmUwB1gwq0DSM/KNurbYycgNoFDWU9N6DQgbUaSO5yi EN+QBf90yWlQGnvf47pJKSs2NvCV/3v6d+Z+hchxvHCuFRYV2w0ELkQILFoFtU4A bBnq8mibMmKvWvdUAwhhivOkgIPg0C0EEnK/QMqupnJgL+aYiNyhlF2JmnPWFCEX zj0rmJewWfqu6aQ53WdJUWxL4vyLSEU9E5llS+Y0KrpcNZhdTz34dtrAwYlcDA2l rObKGrGRcnPAB86N8PMO =gmws -----END PGP SIGNATURE----- --=-DLedWhmgv3NDzB/bwrRA--