Hi Matthew,<br><br>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.<br>
<br><br><br><div class="gmail_quote">On Thu, Apr 9, 2009 at 2:58 AM, Matthew Wilkins <span dir="ltr"><<a href="mailto:daibutsu@gmail.com">daibutsu@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
hi there,<br>
<br>
i am doing some testing of 2.0.0rc7 on two RHEL machines. i have a<br>
nufa setup, my config is below.<br>
files that i create have the sticky bit set on them, why is that? in detail:<br>
<br>
on mu-rhdev1 i create the file /mnt/foo1 (where gluster is mounted on<br>
/mnt), i do an ls<br>
<br>
[root@mu-rhdev1 glusterfs]# vi /mnt/foo1<br>
[root@mu-rhdev1 glusterfs]# ls -l /mnt/ /export/brick0/<br>
/export/brick0/:<br>
total 4<br>
-rw-r--r-T 1 root root 3 Apr 8 14:55 foo1<br>
</blockquote><div><br>sticky bit here identifies that mu-rhdev1:/export/brick0/foo1 is a "linkfile to" the file mu-rhdev2:/export/brick0/foo1<br> <br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<br>
/mnt/:<br>
total 4<br>
-rw-r--r-T 1 root root 3 Apr 8 14:55 foo1<br>
<br>
and on mu-rhdev2 i see:<br>
<br>
[root@mu-rhdev2 mnt]# ls -l /mnt/ /export/brick0/<br>
/export/brick0/:<br>
total 4<br>
---------T 1 root root 0 Apr 8 14:55 foo1</blockquote><div></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><br>
<br>
/mnt/:<br>
total 4<br>
-rw-r--r-T 1 root root 3 Apr 8 14:55 foo1<br>
<br>
so what are those sticky bits doing there? also why is foo1 showing<br>
up in mu-rhdev2:/export/brick0? is this a namespace?</blockquote><div><br> read the above explanation.</div><div> </div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<br>
<br>
now i create a file on mu-rhdev2:<br>
<br>
[root@mu-rhdev2 mnt]# vi /mnt/foo2<br>
[root@mu-rhdev2 mnt]# ls -l /mnt/ /export/brick0/<br>
/export/brick0/:<br>
total 8<br>
---------T 1 root root 0 Apr 8 14:55 foo1<br>
-rw-r--r-- 1 root root 5 Apr 8 14:55 foo2<br>
<br>
/mnt/:<br>
total 8<br>
-rw-r--r-T 1 root root 3 Apr 8 14:55 foo1<br>
-rw-r--r-- 1 root root 5 Apr 8 14:55 foo2<br>
<br>
no sticky bits on foo2! and on mu-rhdev1 it looks like:<br>
<br>
root@mu-rhdev1 glusterfs]# ls -l /mnt/ /export/brick0/<br>
/export/brick0/:<br>
total 4<br>
-rw-r--r-T 1 root root 3 Apr 8 14:55 foo1<br>
<br>
/mnt/:<br>
total 8<br>
-rw-r--r-T 1 root root 3 Apr 8 14:55 foo1<br>
-rw-r--r-- 1 root root 5 Apr 8 14:55 foo2<br>
<br>
foo2 doesn't show up as zero size in /export/brick0, perhaps it will<br>
over time or if i stat it from mu-rhdev1?</blockquote><div> </div><div>here foo2 gets hashed to mu-rhdev2 and since mu-rhdev2 has enough disk space, foo2 is actually stored there (not the linkfile).<br> </div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<br>
<br>
thanks for any help in clarifying what is happening here. here is my config:<br>
<br>
volume posix<br>
type storage/posix<br>
option directory /export/brick0<br>
end-volume<br>
<br>
volume locks<br>
type features/locks<br>
subvolumes posix<br>
end-volume<br>
<br>
volume brick<br>
type performance/io-threads<br>
subvolumes locks<br>
end-volume<br>
<br>
volume server<br>
type protocol/server<br>
option transport-type tcp<br>
option auth.addr.brick.allow *<br>
subvolumes brick<br>
end-volume<br>
<br>
volume mu-rhdev1<br>
type protocol/client<br>
option transport-type tcp<br>
option remote-host mu-rhdev1<br>
option remote-subvolume brick<br>
end-volume<br>
<br>
volume mu-rhdev2<br>
type protocol/client<br>
option transport-type tcp<br>
option remote-host mu-rhdev2<br>
option remote-subvolume brick<br>
end-volume<br>
<br>
volume nufa<br>
type cluster/nufa<br>
option local-volume-name `hostname`<br>
subvolumes mu-rhdev1 mu-rhdev2<br>
end-volume<br>
<br>
volume writebehind<br>
type performance/write-behind<br>
option cache-size 1MB<br>
subvolumes nufa<br>
end-volume<br>
<br>
# before or after writebehind?<br>
volume ra<br>
type performance/read-ahead<br>
subvolumes writebehind<br>
end-volume<br>
<br>
volume cache<br>
type performance/io-cache<br>
option cache-size 512MB<br>
subvolumes ra<br>
end-volume<br>
<br>
<br>
<br>
matt<br>
<br>
_______________________________________________<br>
Gluster-users mailing list<br>
<a href="mailto:Gluster-users@gluster.org">Gluster-users@gluster.org</a><br>
<a href="http://zresearch.com/cgi-bin/mailman/listinfo/gluster-users" target="_blank">http://zresearch.com/cgi-bin/mailman/listinfo/gluster-users</a><br>
</blockquote></div><br><br clear="all"><br>-- <br>Raghavendra G<br><br>