From: DENIEL Philippe <philippe.deniel@CEA.FR>
To: Dave Chinner <david@fromorbit.com>
Cc: xfs@oss.sgi.com
Subject: Re: open_by_handle on a file ?
Date: Tue, 25 May 2010 10:44:47 +0200 [thread overview]
Message-ID: <4BFB8DFF.5040306@cea.fr> (raw)
In-Reply-To: <20100512222147.GD13617@dastard>
Thank you Dave, you were definitely right. I used the XFS mount point as
the argument to path_to_fshandle and it now woks perfectly. :-)
This leads me to another question : now that I can convert a path to
fhandle and use it to open a file or a directory, I can use getdents and
the ATFILE_SOURCE functions (mkdirat, linkat, ....) to implement the NFS
logic (I just have to "open_by_handle" to get the fs to the related fs
object and operate on it). The idea behind this is implementing a NFS
server in Userspace with XFS specific capabilites.
In fact, the NFS on which a minor issue remains is LOOKUP (and it could
become a major issue since LOOKUP is called very often). To lookup on an
object knowing its parent directory's handle and its name, I can perform
an "openat" followed by a xfs related "fd_to_handle" and close the fd
once the operation is done. But it seems a bit "heavy" to me. Is there
another (lighter) way of getting the handle to an object knowing its
name and parent directory (may be by a call to xfsctl ?).
Regards,
Philippe
Dave Chinner a écrit :
> On Wed, May 12, 2010 at 05:39:44PM +0200, DENIEL Philippe wrote:
>
>> Hi,
>>
>> I start using libhandle.so from xfsprogs-3.0.3 package. I meet an
>> issue here : I can get a handle from files or directory.
>> When used on diretories, open_by_handle works fine : I can read
>> entries in it by using getdents, create stuff / removing stuff by
>> using the ATFILE_FUNCTION (mkdirat, renameat, ...)
>>
>> Trouble start when I want to open a file with open_by_handle. I have
>> a small test program that does this :
>>
>> rc = path_to_fshandle( path_dir, (void **)(&fshandle),
>> &fshandlelen) ;
>> if( rc < 0 ) exit( -1)
>> rc = path_to_handle( path_dir, (void **)(&filehandle), &handlelen) ;
>> if( rc < 0 ) exit( -1 )
>>
>> fd = open_by_handle( filehandle, handlelen, O_RDONLY ) ;
>> printf( "open_by_handle: fd=%d \n", fd ) ;
>> if( fd < 0 )
>> printf( "----> Error=%d | %s\n", errno, strerror( errno ) ) ;
>>
>> The open_by_handle failed with errno=20 aka ENOTDIR, which is true,
>> this is a file and no directory.
>>
>
> I think that is because the path_dir points to a regular file and
> so path_to_fshandle() is generating a fshandle that points to a file
> instead of a directory. This handle is cached inside libhandle, and
> then use for subsequent handle calls like open_by_handle(). The
> kernel rejects the request is the fshandle does not point to a
> directory.
>
> Try using the mount point or a directory within the mount for
> the path_to_fshandle() call and see if that fixes the problem.
>
> Cheers,
>
> Dave.
>
_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs
prev parent reply other threads:[~2010-05-25 8:42 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-05-12 15:39 open_by_handle on a file ? DENIEL Philippe
2010-05-12 22:21 ` Dave Chinner
2010-05-25 8:44 ` DENIEL Philippe [this message]
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=4BFB8DFF.5040306@cea.fr \
--to=philippe.deniel@cea.fr \
--cc=david@fromorbit.com \
--cc=xfs@oss.sgi.com \
/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.