Re: [PATCH v2 1/5] fat: allocate persistent inode numbers

From: OGAWA Hirofumi
Date: Sun Sep 09 2012 - 05:33:21 EST


"Steven J. Magnani" <steve@xxxxxxxxxxxxxxx> 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@xxxxxxxxxxxxxxxxxx>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/