[Gluster-users] sticky bit?

[Matthew Wilkins]

hi,

thanks Raghavendra for your reply.

On Tue, Apr 14, 2009 at 9:13 PM, Raghavendra G
<raghavendra at zresearch.com> wrote:
> Hi Matthew,
>
> When the node to which the file gets hashed does not have enough free space,
> file gets created on another node having enough free space and a zero byte
> sized file with its sticky bit set is created on the hashed node. The zero
> byte sized with its sticky bit set file is a special file which dht
> identifies as a "linkfile". linkfile has enough information set in its
> extended attributes to identify the node in which file is actually stored.

sounds a totally plausible explanation, and i am sure you are correct, but
i just can't quite get it!  please read below.

>> [root at mu-rhdev1 glusterfs]# vi /mnt/foo1
>> [root at mu-rhdev1 glusterfs]# ls -l /mnt/ /export/brick0/
>> /export/brick0/:
>> total 4
>> -rw-r--r-T 1 root root 3 Apr  8 14:55 foo1
>
> sticky bit here identifies that mu-rhdev1:/export/brick0/foo1 is a
> "linkfile to"  the file mu-rhdev2:/export/brick0/foo1

the size of mu-rhdev1:/export/brick0/foo1 is 3, and the size of
mu-rhdev2:/export/brick0/foo1 is 0.  that
would seem to indicate to me that the link is the other way, but why
would that be so (this is a nufa
set up).  to confirm or deny i tried using getfattr -d
/export/brick0/foo1 (on both servers) but don't
get anything back.  also there is lots of room on both bricks.

thanks for any further clarification!

matt




>
>>
>> /mnt/:
>> total 4
>> -rw-r--r-T 1 root root 3 Apr  8 14:55 foo1
>>
>> and on mu-rhdev2 i see:
>>
>> [root at mu-rhdev2 mnt]# ls -l /mnt/ /export/brick0/
>> /export/brick0/:
>> total 4
>> ---------T 1 root root 0 Apr  8 14:55 foo1
>>
>> /mnt/:
>> total 4
>> -rw-r--r-T 1 root root 3 Apr  8 14:55 foo1
>>
>> so what are those sticky bits doing there?  also why is foo1 showing
>> up in mu-rhdev2:/export/brick0?  is this a namespace?
>
>  read the above explanation.
>
>>
>> now i create a file on mu-rhdev2:
>>
>> [root at mu-rhdev2 mnt]# vi /mnt/foo2
>> [root at mu-rhdev2 mnt]# ls -l /mnt/ /export/brick0/
>> /export/brick0/:
>> total 8
>> ---------T 1 root root 0 Apr  8 14:55 foo1
>> -rw-r--r-- 1 root root 5 Apr  8 14:55 foo2
>>
>> /mnt/:
>> total 8
>> -rw-r--r-T 1 root root 3 Apr  8 14:55 foo1
>> -rw-r--r-- 1 root root 5 Apr  8 14:55 foo2
>>
>> no sticky bits on foo2!  and on mu-rhdev1 it looks like:
>>
>> root at mu-rhdev1 glusterfs]# ls -l /mnt/ /export/brick0/
>> /export/brick0/:
>> total 4
>> -rw-r--r-T 1 root root 3 Apr  8 14:55 foo1
>>
>> /mnt/:
>> total 8
>> -rw-r--r-T 1 root root 3 Apr  8 14:55 foo1
>> -rw-r--r-- 1 root root 5 Apr  8 14:55 foo2
>>
>> foo2 doesn't show up as zero size in /export/brick0, perhaps it will
>> over time or if i stat it from mu-rhdev1?
>
>
> here foo2 gets hashed to mu-rhdev2 and since mu-rhdev2 has enough disk
> space, foo2 is actually stored there (not the linkfile).
>
>>
>> thanks for any help in clarifying what is happening here.  here is my
>> config:
>>
>> volume posix
>>  type storage/posix
>>  option directory /export/brick0
>> end-volume
>>
>> volume locks
>>  type features/locks
>>  subvolumes posix
>> end-volume
>>
>> volume brick
>>  type performance/io-threads
>>  subvolumes locks
>> end-volume
>>
>> volume server
>>  type protocol/server
>>  option transport-type tcp
>>  option auth.addr.brick.allow *
>>  subvolumes brick
>> end-volume
>>
>> volume mu-rhdev1
>>  type protocol/client
>>  option transport-type tcp
>>  option remote-host mu-rhdev1
>>  option remote-subvolume brick
>> end-volume
>>
>> volume mu-rhdev2
>>  type protocol/client
>>  option transport-type tcp
>>  option remote-host mu-rhdev2
>>  option remote-subvolume brick
>> end-volume
>>
>> volume nufa
>>  type cluster/nufa
>>  option local-volume-name `hostname`
>>  subvolumes mu-rhdev1 mu-rhdev2
>> end-volume
>>
>> volume writebehind
>>  type performance/write-behind
>>  option cache-size 1MB
>>  subvolumes nufa
>> end-volume
>>
>> # before or after writebehind?
>> volume ra
>>  type performance/read-ahead
>>  subvolumes writebehind
>> end-volume
>>
>> volume cache
>>  type performance/io-cache
>>  option cache-size 512MB
>>  subvolumes ra
>> end-volume
>>
>>
>>
>> matt
>>
>> _______________________________________________
>> Gluster-users mailing list
>> Gluster-users at gluster.org
>> http://zresearch.com/cgi-bin/mailman/listinfo/gluster-users
>
>
>
> --
> Raghavendra G
>
>