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 > >
