I'm not sure but where is namespace volume in spec-files?
http://gluster.org/docs/index.php/User_Guide#Namespace
"Namespace volume needed because:
- persistent inode numbers.cheers,
- file exists even when node is down."
Alexey.
On Tue, May 12, 2009 at 3:29 AM, Liam Slusser <lslusser@xxxxxxxxx> wrote:
Even with manually fixing (adding or removing) the extended attributes i was never able to get Gluster to see the missing files. So i ended up writing a quick program that searched the raw bricks filesystem and then checked to make sure the file existed in the Gluster cluster and if it didn't it would tag the file. Once that job was done i shut down Gluster, moved all the missing files off the raw bricks into temp storage, and then i restarted Gluster and copied all the files back into each directory. That fixed the missing file problems.Id still like to find out why Gluster would ignore certain files without the correct attributes. Even removing all the file attributes wouldn't fix the problem. I also tried manually coping a file into a brick which it still wouldn't find. It would be nice to be able to manual copy files into a brick, then set an extended attribute flag which would cause gluster to see the new file(s) and copy them to all bricks after a ls -alR was done. Or even better just do it automatically when new files without attributes are found in a brick.thanks,liamOn Wed, May 6, 2009 at 4:13 PM, Liam Slusser <lslusser@xxxxxxxxx> wrote:
To answer some of my own question, looks like those files were copied using gluster 1.3.12 which is why they have the different extended attributes:gluster 1.3.12Attribute "glusterfs.createtime" has a 10 byte value for fileAttribute "glusterfs.version" has a 1 byte value for fileAttribute "glusterfs.dht" has a 16 byte value for filewhile gluster 2.0.0 hasAttribute "afr.brick2b" has a 12 byte value for fileAttribute "afr.brick1b" has a 12 byte value for file
I've been unsuccessful on fixing the attributes, can anybody point me in the right direction?thanks,liam
On Wed, May 6, 2009 at 12:48 PM, Liam Slusser <lslusser@xxxxxxxxx> wrote:
Big thanks to the devel group for fixing all the memory leak issues with the earlier RC releases. 2.0.0 has been great so far without any memory issues what-so-ever.I am seeing some oddities with the replication/distribute translators however. I have three partitions on each gluster server exporting three bricks - We have two servers. The gluster clients replicates each brick between the two servers and then i have a distribute translator for all the replicated bricks - basically gluster raid10.There are a handful of files which have been copied into the gluster volume but since have disappeared, however the physical files exist on both bricks.(from a client)[root@client1 049891002526]# pwd/intstore/data/tracks/tmg/2008_02_05/049891002526[root@client1 049891002526]# ls -al 049891002526_01_09.wma.sigKey01.kls: 049891002526_01_09.wma.sigKey01.k: No such file or directory[root@client1 049891002526]# head 049891002526_01_09.wma.sigKey01.khead: cannot open `049891002526_01_09.wma.sigKey01.k' for reading: No such file or directory[root@client1 049891002526]#(from a server brick)[root@server1 049891002526]# pwd/intstore/intstore01c/gcdata/data/tracks/tmg/2008_02_05/049891002526[root@server1 049891002526]# ls -al 049891002526_01_09.wma.sigKey01.k-rw-rw-rw- 1 10015 root 19377712 Feb 6 2008 049891002526_01_09.wma.sigKey01.k[root@server1 049891002526]# attr -l 049891002526_01_09.wma.sigKey01.kAttribute "glusterfs.createtime" has a 10 byte value for 049891002526_01_09.wma.sigKey01.kAttribute "glusterfs.version" has a 1 byte value for 049891002526_01_09.wma.sigKey01.kAttribute "selinux" has a 24 byte value for 049891002526_01_09.wma.sigKey01.k[root@server1 049891002526]# attr -l .Attribute "glusterfs.createtime" has a 10 byte value for .Attribute "glusterfs.version" has a 1 byte value for .Attribute "glusterfs.dht" has a 16 byte value for .Attribute "selinux" has a 24 byte value for .Nothing in both the client and server logs. I've tried all the normal replication checks and self-heal such as ls -alR. If i copy the file back from one of the bricks into the volume it will show up again however it has a 1/3 chance of getting written to the files original location. So then i end up with two identical files on two different bricks.This volume has over 40 million files and directories so it can be very tedious to find anomalies. I wrote a quick perl script to search 1/25 of our total files in the volume for missing files and md5 checksum differences and as of now its about 15% (138,500 files) complete and has found ~7000 missing files and 0 md5 checksum differences.How could i debug this? I'd image it has something to do with the extended attributes on either the file or parent directory...but as far as i can tell that all looks fine.thanks,liamclient glusterfs.vol:volume brick1atype protocol/clientoption transport-type tcpoption remote-host server1option remote-subvolume brick1aend-volumevolume brick1btype protocol/clientoption transport-type tcpoption remote-host server1option remote-subvolume brick1bend-volumevolume brick1ctype protocol/clientoption transport-type tcpoption remote-host server1option remote-subvolume brick1cend-volumevolume brick2atype protocol/clientoption transport-type tcpoption remote-host server2option remote-subvolume brick2aend-volume
volume brick2btype protocol/clientoption transport-type tcpoption remote-host server2option remote-subvolume brick2bend-volumevolume brick2ctype protocol/clientoption transport-type tcpoption remote-host server2option remote-subvolume brick2cend-volume
volume bricks1type cluster/replicatesubvolumes brick1a brick2aend-volumevolume bricks2type cluster/replicatesubvolumes brick1b brick2bend-volumevolume bricks3type cluster/replicatesubvolumes brick1c brick2cend-volumevolume distributetype cluster/distributesubvolumes bricks1 bricks2 bricks3end-volumevolume writebehindtype performance/write-behindoption block-size 1MBoption cache-size 64MBoption flush-behind onsubvolumes distributeend-volumevolume cachetype performance/io-cacheoption cache-size 2048MBsubvolumes writebehindend-volumeserver glusterfsd.vol:volume intstore01atype storage/posixoption directory /intstore/intstore01a/gcdataend-volumevolume intstore01btype storage/posixoption directory /intstore/intstore01b/gcdataend-volumevolume intstore01ctype storage/posixoption directory /intstore/intstore01c/gcdataend-volumevolume locksatype features/posix-locksoption mandatory-locks onsubvolumes intstore01aend-volumevolume locksbtype features/posix-locksoption mandatory-locks onsubvolumes intstore01bend-volumevolume locksctype features/posix-locksoption mandatory-locks onsubvolumes intstore01cend-volumevolume brick1atype performance/io-threadsoption thread-count 32subvolumes locksaend-volumevolume brick1btype performance/io-threadsoption thread-count 32subvolumes locksbend-volumevolume brick1ctype performance/io-threadsoption thread-count 32subvolumes lockscend-volumevolume servertype protocol/serveroption transport-type tcpoption auth.addr.brick1a.allow 192.168.12.*option auth.addr.brick1b.allow 192.168.12.*option auth.addr.brick1c.allow 192.168.12.*subvolumes brick1a brick1b brick1cend-volumeOn Wed, Apr 22, 2009 at 5:43 PM, Liam Slusser <lslusser@xxxxxxxxx> wrote:
Avati,Big thanks. Looks like that did the trick. I'll report back in the morning if anything has changed but its looking MUCH better. Thanks again!liamOn Wed, Apr 22, 2009 at 2:32 PM, Anand Avati <avati@xxxxxxxxxxx> wrote:Liam,
An fd leak and a lock structure leak has been fixed in the git
repository, which explains a leak in the first subvolume's server.
Please pull the latest patches and let us know if it does not fixe
your issues. Thanks!
Avati
On Tue, Apr 21, 2009 at 3:41 PM, Liam Slusser <lslusser@xxxxxxxxx> wrote:
> There is still a memory leak with rc8 on my setup. The first server in a
> cluster or two servers starts out using 18M and just slowly increases.
> After 30mins it has doubled in size to over 30M and just keeps growing -
> the more memory it uses the worst the performance. Funny that the second
> server in my cluster using the same configuration file has no such memory
> problem.
> My glusterfsd.vol has no performance translators, just 3 storage/posix -> 3
> features/posix-locks -> protocol/server.
> thanks,
> liam
> On Mon, Apr 20, 2009 at 2:01 PM, Gordan Bobic <gordan@xxxxxxxxxx> wrote:
>>
>> Gordan Bobic wrote:
>>>
>>> First-access failing bug still seems to be present.
>>> But other than that, it seems to be distinctly better than rc4. :)
>>> Good work! :)
>>
>> And that massive memory leak is gone, too! The process hasn't grown by a
>> KB after a kernel compile! :D
>>
>> s/Good work/Awesome work/
>>
>> :)
>>
>>
>> Gordan
>>
>>
>> _______________________________________________
>> Gluster-devel mailing list
>> Gluster-devel@xxxxxxxxxx
>> http://lists.nongnu.org/mailman/listinfo/gluster-devel
>
>
> _______________________________________________
> Gluster-devel mailing list
> Gluster-devel@xxxxxxxxxx
> http://lists.nongnu.org/mailman/listinfo/gluster-devel
>
>
_______________________________________________
Gluster-devel mailing list
Gluster-devel@xxxxxxxxxx
http://lists.nongnu.org/mailman/listinfo/gluster-devel