On Wed, Aug 15, 2012 at 06:06:23PM -0400, J. Bruce Fields wrote:

On Thu, Aug 16, 2012 at 01:02:37AM +0400, Cyrill Gorcunov wrote:

quoted

On Wed, Aug 15, 2012 at 04:45:46PM -0400, J. Bruce Fields wrote:

quoted

On Wed, Aug 15, 2012 at 01:21:20PM +0400, Cyrill Gorcunov wrote:

quoted

To provide fsnotify object inodes being watched without
binding to alphabetical path we need to encode them with
exportfs help. This patch adds a helper which operates
with plain inodes directly.

I don't get it--this seems like a really roundabout way to get inode and
generation number, if that's all you want.

We can re-open the targets via filehandle on restore, this was the idea.
All this series aimed to achieve the way to restore objects after checkpoit,
thus we need to provide additional information which would be enough.

For this to work it'll need to be something you can pass to
open_by_handle_at, won't it?

Yes, and for inotify we print out this handled via fdinfo, later on restore
we use it together with open_by_handle_at.

quoted

quoted

On the other hand, if you want a real filehandle then wouldn't you want
to e.g. call the filesystem's ->encode_fh() if necessary, as
exportfs_encode_fh() does?

Well, one of the problem I hit when I've been trying to use encode_fh
is that every new implementation of encode_fh will require some size
(even unknown) in buffer where encoded data pushed. Correct me please
if I'm wrong. But with export_encode_inode_fh there is a small buffer
with pretty known size needed on stack needed for printing data in
fdinfo.

You can just give encode_fh a too-small data and let it fail if it's not
big enough.

(In practice I think everyone supports NFSv3 filehandles which have a
maximum size of 64 bytes.)

I'll think about it, thanks!

	Cyrill