2012-12-10 (월), 14:25 +0900, Namjae Jeon: > 2012/12/10, Jaegeuk Kim <jaegeuk.kim@xxxxxxxxxxx>: > > 2012-12-10 (월), 12:40 +0900, Namjae Jeon: > >> 2012/12/10, Jaegeuk Kim <jaegeuk.kim@xxxxxxxxxxx>: > >> > 2012-12-08 (토), 14:55 +0900, Namjae Jeon: > >> >> From: Namjae Jeon <namjae.jeon@xxxxxxxxxxx> > >> >> > >> >> 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 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 lookup > >> >> 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 “reconnect” with parent ? and shows “No such > file or directory” for directory paths. Again, you didn't describe why this bug is occurred. Please, analyze the bug scenario first. > > 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 “..” 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 “..”, 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, -- Jaegeuk Kim Samsung
Attachment:
signature.asc
Description: This is a digitally signed message part
