[Gluster-devel] problem with file locking use fcnt

Krishna Srinivas krishna at zresearch.com
Sat Jun 21 15:39:40 UTC 2008


The option will not affect performance, its just a basic security setting.

Krishna

On Sat, Jun 21, 2008 at 12:47 PM, Dale Johnson <dale.johnson at gmail.com> wrote:
> Thanks, that did it.  I did need one extra
>
>  option auth.ip.locks.allow *
>
> for the new volume.
>
> Is there a downside to just always running with this setting?  It seemed like
> my timing tests writing files are pretty much the same, although I did use
> large files to test with.
>
> Dale.
>
> On Fri, Jun 20, 2008 at 3:38 AM, Krishna Srinivas <krishna at zresearch.com> wrote:
>>> volume remote1
>>>  type protocol/client
>>>  option transport-type tcp/client
>>>  option remote-host 2A
>>>  option remote-subvolume brick
>>> end-volume
>>
>> remote-subvolume should be locks, not brick. Same with the
>> other client config.
>>
>> Regards
>> Krishna
>>
>> On Fri, Jun 20, 2008 at 3:28 PM, Dale Johnson <dale.johnson at gmail.com> wrote:
>>>
>>> First, gluster is a great product in a great space, and has been working well.
>>> But I have hit a roadblock trying to do this:
>>>
>>> #include <stdio.h>
>>> #include <fcntl.h>
>>> #include <errno.h>
>>> #include <unistd.h>
>>> #include <string.h>
>>>
>>> int main( int argc, char ** argv ) {
>>>  if( argc == 2 ) {
>>>    int fd = open( argv[1], O_WRONLY | O_TRUNC | O_CREAT, 0666 );
>>>    char s[] = "hello, world\n";
>>>    write( fd, s, sizeof( s ) );
>>>    close( fd );
>>>
>>>    int fd2 = open( argv[1], O_RDONLY );
>>>    char buf[80];
>>>    memset( buf, '\0', sizeof( buf ) );
>>>    read( fd2, buf, sizeof( buf ) );
>>>    printf( "buf: %s\n", buf );
>>>
>>>    struct flock lk;
>>>    lk.l_type = F_RDLCK;
>>>    lk.l_whence = SEEK_SET;
>>>    lk.l_start = 0;
>>>    lk.l_len = 6;
>>>    lk.l_pid = 0;
>>>
>>>    int i = fcntl( fd, F_SETLK, &lk );
>>>    printf( "i=%d,  errno=%d\n", i, errno );
>>>    perror( "foo" );
>>>
>>>    close( fd2 );
>>>  } else {
>>>    printf( "usage: %s <outfile>\n", argv[0] );
>>>    exit( 2 );
>>>  }
>>> }
>>>
>>> and I get this:
>>>
>>> [root at 2D src]# ./a.out /mnt/glusterfs/fooX
>>> buf: hello, world
>>>
>>> i=-1,  errno=38
>>> foo: Function not implemented
>>>
>>> but not on a regular disk
>>>
>>> [root at 2D src]# ./a.out /tmp/fooY
>>> buf: hello, world
>>>
>>> i=0,  errno=0
>>> foo: Success
>>>
>>> I would have expected this to work.  I'm running fuse 2.7.3,
>>> glusterfs-1.3.9, and centos 2.6.18-53.1.21.el5 on intel.
>>>
>>> My config is 2 servers, and 2 clients (running under vmware), and the
>>> server config is:
>>>
>>> volume brick
>>>  type storage/posix
>>>  option directory /data/export
>>> end-volume
>>>
>>> volume locks
>>>  type features/posix-locks
>>>  option manditory on
>>>  subvolumes brick
>>> end-volume
>>>
>>> volume server
>>>  type protocol/server
>>>  option transport-type tcp/server
>>>  option auth.ip.brick.allow *
>>>  subvolumes brick
>>> end-volume
>>>
>>> My client config is:
>>>
>>> volume remote1
>>>  type protocol/client
>>>  option transport-type tcp/client
>>>  option remote-host 2A
>>>  option remote-subvolume brick
>>> end-volume
>>>
>>> volume remote2
>>>  type protocol/client
>>>  option transport-type tcp/client
>>>  option remote-host 2B
>>>  option remote-subvolume brick
>>> end-volume
>>>
>>> volume mirror0
>>>  type cluster/afr
>>>  subvolumes remote1 remote2
>>> end-volume
>>>
>>> I do see this message during the load, but I understand that it's harmless:
>>>
>>> 2008-06-18 13:00:21 D [xlator.c:115:xlator_set_type] xlator:
>>>  attempt to load file
>>> /usr/local/lib/glusterfs/1.3.9/xlator/features/posix-locks.so
>>>
>>> 2008-06-18 13:00:21 D [xlator.c:145:xlator_set_type] xlator: dlsym(notify)
>>>  on /usr/local/lib/glusterfs/1.3.9/xlator/features/posix-locks.so:
>>> undefined symbol: notify -- neglecting
>>>
>>> Thanks in advance,
>>> Dale Johnson
>>>
>>>
>>> _______________________________________________
>>> Gluster-devel mailing list
>>> Gluster-devel at nongnu.org
>>> http://lists.nongnu.org/mailman/listinfo/gluster-devel
>>
>
>
>
> --
> Dale Johnson (dale.johnson at gmail.com)
>





More information about the Gluster-devel mailing list