Hi Dan,
This is a very particular case, as you want robinhood to identify these
2 different filesystem types (GlusterFS and NFS) as the same
filesystem... AFAIK, this cannot be done just by setting something in
robinhood configuration. It will require a few changes in robinhood
code, but shouldn't be hard to achieve.
I think the easier way to match you need would be to define a new fs_key
type, just based on the FS mount path (actually, a hash of it).
Add it to the enum in src/include/global_config.h with other FSKEYs,
and add the right processing in src/common/RobinhoodMisc.c, in
set_fs_info(),
something like:
case FSKEY_MOUNTPATH:
fs_key = hash_name(mountp);
break;
If you do such a change, we'd be pleased to integrate it upstream.
HTH,
Thomas
On 01/13/15 04:04, Dan Mons wrote:
> Hi Thomas, thanks for the reply.
>
> "devid" doesn't work consistently for systems that NFS mount versus
> those that GlusterFS mount. I'm seeing different entries in
> "rbh-report -D", and tools like rbh-find and rbh-du don't work either.
>
> Between GlusterFS systems that use different cluster node hostnames in
> the mount string, it works. So that's one partial solution at least.
> But not for my NFS mounting clients that need to run rbh-find, rbh-du
> and similar tools locally.
>
> Here's some output to demonstrate. I've empted all databases before
> re-running robinhood with the "devid" config value. Note "System 3",
> which is our NFS client, and has an unresolved path string (should
> start with "/prod", but shows up as "12:1" instead).
>
> System 1:
> [root@bne-gprod000 ~]# mount | grep /prod
> bne-gprod000.ce-bne.cuttingedge:/prod on /prod type fuse.glusterfs
> (rw,default_permissions,allow_other,max_read=131072)
> [root@bne-gprod000 ~]# rbh-report -D | head
> Using config file '/etc/robinhood.d/tmpfs/bne-gprod.conf'.
> type, size, user, group, purge class,
> path
> file, 2.64 MB, jperrigo, prod, ,
> /prod/vfx/mako2_e10/store/e10_s050/flips/e10_s050_comp_nuk_v03_jp/e10_s050_comp_nuk_v03_jp.0085.tga
>
> System 2:
> [root@bne-gprod001 ~]# mount | grep /prod
> bne-gprod001.ce-bne.cuttingedge:/prod on /prod type fuse.glusterfs
> (rw,default_permissions,allow_other,max_read=131072)
> [root@bne-gprod001 ~]# rbh-report -D | head
> Using config file '/etc/robinhood.d/tmpfs/bne-gprod.conf'.
> type, size, user, group, purge class,
> path
> file, 2.64 MB, jperrigo, prod, ,
> /prod/vfx/mako2_e10/store/e10_s050/flips/e10_s050_comp_nuk_v03_jp/e10_s050_comp_nuk_v03_jp.0085.tga
>
> System 3:
> root@bne-render15:~# mount | grep /prod
> 192.168.50.34:/prod on /prod type nfs (rw,vers=3,sloppy,addr=192.168.50.34)
> root@bne-render15:~# rbh-report -D | head
> Using config file '/etc/robinhood.d/tmpfs/bne-gprod.conf'.
> type, size, user, group, purge class,
> path
> file, 2.64 MB, jperrigo, prod, ,
> 12:1/vfx/mako2_e10/store/e10_s050/flips/e10_s050_comp_nuk_v03_jp/e10_s050_comp_nuk_v03_jp.0085.tga
>
>
> -Dan
>
> ----------------
> Dan Mons - R&D Sysadmin
> Cutting Edge
> http://cuttingedge.com.au
>
>
> On 12 January 2015 at 18:45, LEIBOVICI Thomas <[email protected]> wrote:
>> Hi Dan,
>>
>> Did you try with "devid" fs_key? It is based on the device id of the
>> filesystem root,
>> so I believe it should be the same for all filesystem clients.
>>
>> Regards
>> Thomas
>>
>>
>> On 01/11/15 23:37, Dan Mons wrote:
>>> Hi all,
>>>
>>> We're running a GlusterFS setup, and finding robinhood answers a lot
>>> of problems when it comes to large filesystem reporting.
>>>
>>> One issue we're having in the configuration is the fs_key value. We
>>> want the rbh-* tools available to all workstation users. The problem
>>> we have is that clients all mount our GlusterFS setup in different
>>> ways.
>>>
>>> Currently I have set:
>>> fs_key = fsname ;
>>>
>>> All of our users, whether they connect via native glusterfs, nfs or
>>> smb, see our cluster mounted as /prod on their POSIX systems. The
>>> problem is that the fs_key value is different on each system, as it
>>> enumerates the fsname based on different information, including fstype
>>> and the hostname of the "server" it connects to (which in our
>>> clustered setup, always looks different per client at mount time).
>>>
>>> Our setup is quite simple - one large clustered file system, with
>>> several different clients (Ubuntu Linux, CentOS Linux, MacOSX)
>>> mounting with different network file systems, but all mounted to the
>>> same point, named /prod. We only want to report on this one
>>> centralised common name space.
>>>
>>> When I run rbh-report -D from different machines, I see this sort of
>>> thing:
>>>
>>> Correct:
>>> file, 1.80 MB, mhanger, prod, ,
>>>
>>> /prod/vfx/adaline/store/sno_172_500/flips/sno_172_500_comp_nuk_v29_mh/sno_172_500_comp_nuk_v29_mh.1043.tga
>>>
>>> Incorrect:
>>> file, 1.80 MB, mhanger, prod, ,
>>>
>>> 8D5E893E:1/vfx/adaline/store/sno_172_500/flips/sno_172_500_comp_nuk_v29_mh/sno_172_500_comp_nuk_v29_mh.1043.tga
>>>
>>> Is there a way I can force the "fs_key" to always be the same string
>>> for all clients and gluster nodes, and bypass the per-system
>>> enumeration?
>>>
>>> -Dan
>>>
>>> ----------------
>>> Dan Mons - R&D Sysadmin
>>> Cutting Edge
>>> http://cuttingedge.com.au
>>>
>>>
>>> ------------------------------------------------------------------------------
>>> Dive into the World of Parallel Programming! The Go Parallel Website,
>>> sponsored by Intel and developed in partnership with Slashdot Media, is
>>> your
>>> hub for all things parallel software development, from weekly thought
>>> leadership blogs to news, videos, case studies, tutorials and more. Take a
>>> look and join the conversation now. http://goparallel.sourceforge.net
>>> _______________________________________________
>>> robinhood-support mailing list
>>> [email protected]
>>> https://lists.sourceforge.net/lists/listinfo/robinhood-support
>>
------------------------------------------------------------------------------
New Year. New Location. New Benefits. New Data Center in Ashburn, VA.
GigeNET is offering a free month of service with a new server in Ashburn.
Choose from 2 high performing configs, both with 100TB of bandwidth.
Higher redundancy.Lower latency.Increased capacity.Completely compliant.
http://p.sf.net/sfu/gigenet
_______________________________________________
robinhood-support mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/robinhood-support
