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. > > Thanks. > > Thanks, > > > > -- > > Jaegeuk Kim > > Samsung > > > -- > To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in > the body of a message to majordomo@xxxxxxxxxxxxxxx > More majordomo info at http://vger.kernel.org/majordomo-info.html -- Jaegeuk Kim Samsung
Attachment:
signature.asc
Description: This is a digitally signed message part
