From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1757199Ab2IJOAT (ORCPT ); Mon, 10 Sep 2012 10:00:19 -0400 Received: from mail.parknet.co.jp ([210.171.160.6]:37158 "EHLO mail.parknet.co.jp" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1755849Ab2IJOAQ (ORCPT ); Mon, 10 Sep 2012 10:00:16 -0400 From: OGAWA Hirofumi To: Namjae Jeon Cc: "Steven J. Magnani" , Al Viro , akpm@linux-foundation.org, bfields@fieldses.org, linux-kernel@vger.kernel.org, Namjae Jeon , Ravishankar N , Amit Sahrawat Subject: Re: [PATCH v2 1/5] fat: allocate persistent inode numbers References: <1346774264-8031-1-git-send-email-linkinjeon@gmail.com> <20120904161747.GJ23464@ZenIV.linux.org.uk> <87harc34d9.fsf@devron.myhome.or.jp> <87y5knz6l5.fsf@devron.myhome.or.jp> <1347020137.2223.13.camel@iscandar.digidescorp.com> <87oblfpmnb.fsf@devron.myhome.or.jp> <87k3w3ph8d.fsf@devron.myhome.or.jp> Date: Mon, 10 Sep 2012 23:00:02 +0900 In-Reply-To: (Namjae Jeon's message of "Mon, 10 Sep 2012 21:03:46 +0900") Message-ID: <87har6kmfx.fsf@devron.myhome.or.jp> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.2.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Namjae Jeon writes: > Yes, It is true(current VFAT of -mm tree is not stable). Although we > set lookupcache=none while mounting, ESTALE error can still occur in > rename case. > So there still remain ESTALE error issue from rename case on current -mm tree. > plz See the step as the following > 1. on client write to file. > 2. on client, move/rename file. > 3. on server, do drop_caches. etc to somehow evict indoe number so > that it gets new inode number > 4. on client, resume the program to write to file. write will fail > (write: Stale NFS file handle) Since rename() will be disabled on stable ino patches, this will be unfixable, so rather maybe it is worse. Did you checked why it returns -ESTALE? Or rename() issue also is unfixable on -mm? > And ...... > If we mount NFS with lookupcache=none, FAT file lookup performance is > severely dropped. > LOOKUP performance is very poor on slow network and slow device. I do > not recommend to disable lookup cache on NFS. > And that is why reconstructing inode is already implemented in other > filesystem (e.g. EXT4, XFS etc..) > Currently lookupcache is enabled by default in NFS, it means users > already have disclosed and experienced ESTALE issues on NFS over VFAT. > > I agree wth you to make NFS over VFAT read-only filesystem to avoid all issues. > Eventually we can make it writable with rename limitation when we > decide that it is pretty stable in mainline. > So, I suggest to add 'nfs_ro' mount option instead of 'nfs' option. -mm seems to be more stable than I thought. As he said, sounds like rename() is an only known issue on -mm, true? And are you tried https://lkml.org/lkml/2012/6/29/381 patches? It sounds like to improve performance by enabling lookupcache. I'd like to be knowing the critical reason we have to replace it. Thanks. -- OGAWA Hirofumi