linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: OGAWA Hirofumi <hirofumi@mail.parknet.co.jp>
To: "Steven J. Magnani" <steve@digidescorp.com>
Cc: Namjae Jeon <linkinjeon@gmail.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: Sun, 09 Sep 2012 18:32:08 +0900	[thread overview]
Message-ID: <87oblfpmnb.fsf@devron.myhome.or.jp> (raw)
In-Reply-To: <1347020137.2223.13.camel@iscandar.digidescorp.com> (Steven J. Magnani's message of "Fri, 07 Sep 2012 07:15:37 -0500")

"Steven J. Magnani" <steve@digidescorp.com> writes:

> On Fri, 2012-09-07 at 16:01 +0900, Namjae Jeon wrote: 
>> Hi. OGAWA.
>> 
>> I checked read-only option for export on FAT.
>> I think that there are 3 approaches as mentioned below.
>> 
>> 1. As per the current scenario – user already has the option of
>> setting ‘ro’ in /etc/exports – so that can also be used to make it
>> read-only.
>> 	
>> 2. Forcefully set to “read-only” while executing FAT export operation.
>> -> As you know, we can set read-only(ro) export in /etc/exports.
>> If we set read-only export regardless of /etc/exports, This is "HACK"
>> and it will work regardless of user setting.
>> 
>> 3. When FAT is mounted with -onfs option,-> Make it ‘ro’ at the mount
>> time itself.
>> -> It is simple to implement, but VFAT of NFS Server will be set to
>> read-only as well as NFS client.
>
> I argue against (2) and (3). A change that drops any possibility of
> NFS-mounting VFAT filesystems read-write will break my use case. Where
> ESTALE is an issue, there are client-side solutions, either mounting
> with lookupcache=none (which admittedly has a severe performance impact)
> or the VFS patches to handle ESTALE that are working their way towards
> mainline. I recognize that not everyone can take advantage of
> client-side features, but options (2) and (3) make life worse for those
> who can.

What is your use case?  I'm assuming current NFS support of FAT is not
unstable behavior even with your patches. Is this true?

Well, this plan is to provide the stable/clean read-only behavior at
first.  After that, make it writable with some limitations (e.g. rename
may be unsupported).

If your patches in -mm is enough for now, we will not need to do those.
Namjae, were you tested it? or what are you thinking?
-- 
OGAWA Hirofumi <hirofumi@mail.parknet.co.jp>

  reply	other threads:[~2012-09-09  9:33 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 [this message]
2012-09-09 11:29                   ` OGAWA Hirofumi
2012-09-10 12:03                     ` Namjae Jeon
2012-09-10 14:00                       ` OGAWA Hirofumi
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=87oblfpmnb.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).