From: OGAWA Hirofumi <hirofumi@mail.parknet.co.jp>
To: Namjae Jeon <linkinjeon@gmail.com>
Cc: "Steven J. Magnani" <steve@digidescorp.com>,
Al Viro <viro@zeniv.linux.org.uk>,
akpm@linux-foundation.org, bfields@fieldses.org,
linux-kernel@vger.kernel.org,
Namjae Jeon <namjae.jeon@samsung.com>,
Ravishankar N <ravi.n1@samsung.com>,
Amit Sahrawat <a.sahrawat@samsung.com>
Subject: Re: [PATCH v2 1/5] fat: allocate persistent inode numbers
Date: Mon, 10 Sep 2012 23:00:02 +0900 [thread overview]
Message-ID: <87har6kmfx.fsf@devron.myhome.or.jp> (raw)
In-Reply-To: <CAKYAXd-k4yVV3h8k0kcFMsyGnOVckYRjXi8fkZrLtjuWVi7Eqw@mail.gmail.com> (Namjae Jeon's message of "Mon, 10 Sep 2012 21:03:46 +0900")
Namjae Jeon <linkinjeon@gmail.com> 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 <hirofumi@mail.parknet.co.jp>
next prev parent reply other threads:[~2012-09-10 14:00 UTC|newest]
Thread overview: 33+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-09-04 15:57 [PATCH v2 1/5] fat: allocate persistent inode numbers Namjae Jeon
2012-09-04 16:17 ` Al Viro
2012-09-05 14:08 ` Namjae Jeon
2012-09-05 14:56 ` OGAWA Hirofumi
2012-09-06 6:46 ` Namjae Jeon
2012-09-06 12:19 ` OGAWA Hirofumi
2012-09-06 13:39 ` Namjae Jeon
2012-09-07 7:01 ` Namjae Jeon
2012-09-07 12:15 ` Steven J. Magnani
2012-09-09 9:32 ` OGAWA Hirofumi
2012-09-09 11:29 ` OGAWA Hirofumi
2012-09-10 12:03 ` Namjae Jeon
2012-09-10 14:00 ` OGAWA Hirofumi [this message]
2012-09-11 12:00 ` Namjae Jeon
2012-09-11 12:31 ` OGAWA Hirofumi
2012-09-11 15:13 ` Namjae Jeon
2012-09-11 15:47 ` OGAWA Hirofumi
2012-09-12 14:12 ` Namjae Jeon
2012-09-12 14:32 ` J. Bruce Fields
2012-09-12 17:03 ` OGAWA Hirofumi
2012-09-12 17:11 ` J. Bruce Fields
2012-09-12 17:38 ` OGAWA Hirofumi
2012-09-12 17:45 ` J. Bruce Fields
2012-09-12 18:49 ` OGAWA Hirofumi
2012-09-13 8:11 ` Namjae Jeon
2012-09-13 8:33 ` OGAWA Hirofumi
2012-09-13 11:20 ` J. Bruce Fields
2012-09-13 12:17 ` OGAWA Hirofumi
2012-09-13 14:24 ` Namjae Jeon
2012-09-13 14:46 ` J. Bruce Fields
2012-09-13 15:34 ` OGAWA Hirofumi
2012-09-14 8:51 ` Namjae Jeon
2012-09-10 12:28 ` Steven J. Magnani
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87har6kmfx.fsf@devron.myhome.or.jp \
--to=hirofumi@mail.parknet.co.jp \
--cc=a.sahrawat@samsung.com \
--cc=akpm@linux-foundation.org \
--cc=bfields@fieldses.org \
--cc=linkinjeon@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=namjae.jeon@samsung.com \
--cc=ravi.n1@samsung.com \
--cc=steve@digidescorp.com \
--cc=viro@zeniv.linux.org.uk \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.