Message-ID: <87vcfjfa14.fsf@devron.myhome.or.jp>
Date:	Thu, 13 Sep 2012 02:03:51 +0900
From:	OGAWA Hirofumi <hirofumi@...l.parknet.co.jp>
To:	"J. Bruce Fields" <bfields@...ldses.org>
Cc:	Namjae Jeon <linkinjeon@...il.com>,
	"Steven J. Magnani" <steve@...idescorp.com>,
	Al Viro <viro@...iv.linux.org.uk>, akpm@...ux-foundation.org,
	linux-kernel@...r.kernel.org,
	Namjae Jeon <namjae.jeon@...sung.com>,
	Ravishankar N <ravi.n1@...sung.com>,
	Amit Sahrawat <a.sahrawat@...sung.com>
Subject: Re: [PATCH v2 1/5] fat: allocate persistent inode numbers

"J. Bruce Fields" <bfields@...ldses.org> writes:

>> > Supposing, the server/client state is after cold boot, and client try to
>> > rename at first without any cache on client/server.
>> >
>> > Even if this state, does the server return ESTALE? If it doesn't return
>> > ESTALE, I can't understand why it is really unfixable.
>> Hi OGAWA.
>> Server will not return ESTALE in this case. because the client does
>> not have any information for files yet.
>
> It does if the client mounted before the server rebooted.  NFS is
> designed so that servers can reboot without causing clients to fail.
> (Applications will just see a delay during the reboot.)
>
> It probably isn't possible to this work in the case of fat.
>
> But from fat's point of view there probably isn't much difference
> between a filehandle lookup after a reboot and a filehandle lookup after
> the inode's gone from cache.

This is talking about to retry by client side, not server side solution.
What happens if client retry after got ESTALE? (Yes, this would not be
the solution for all NFS clients. But, I guess this solution can be for
linux NFS client.)

> I really don't see what you can do to help here.  Won't anything that
> allows looking up an uncached inode by filehandle also risk finding the
> wrong file?

On other view (as server side solution), we are thinking there is
possible to make the stable filehandle on FAT if we disabled some
operations (e.g. rename(), unlink()) which change inode location in FAT.

Yes, it would be stable, but supporting limited operations.

This is server side solution, and we comparing it with client solution.

>> > If it returns ESTALE, why does it return? I'm assuming the previous code
>> > path is the cached FH path.
>> The main point for observation is the file handle-which is used for
>> all the NFS operation.
>> So for all the NFS operation(read/write....) which makes use of the
>> NFS file handle in between if there is a change in inode number
>> It will result in ESTALE.
>> Changing inode number on rename happened at NFS server by inode cache
>> eviction with memory pressure.
>> 
>> lookupcache is used at NFS client to reduce number of LOOKUP operations.
>> But , we can still get ESTALE if inode number at NFS Server change
>> after LOOKUP, although lookupcache is disable.
>> 
>> LOOKUP return NFS FH->[inode number changed at NFS Server] ->
>> But we still use old NFS FH returned from LOOKUP for any file
>> operation(write,read,etc..)
>> -> ESTALE will be returned.

Yes.  And I'm expecting as client side solution,

-> ESTALE will be returned -> discard old FH -> restart from LOOKUP ->
make cached inode -> use returned new FH.

Yeah, I know this is unstable (there is no perfect solution for now),
but if this works, this doesn't limit any operations.

We would want to compare client solution (-mm) and server solution
(stable ino). Or I'd like to know which my knowledges/understanding are
wrong here.
-- 
OGAWA Hirofumi <hirofumi@...l.parknet.co.jp>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists