Re: [OpenAFS] Linux find command inconsistent

2015-09-16 Thread John Sopko
Thanks, I briefly checked it out and it looks like it will give me the
volume/mountpoint list.

On Tue, Sep 15, 2015 at 4:12 PM, Michael Meffie  wrote:
>
>> See above. The RHEL6/Ubuntu result is likely to be the better one.
>>
>> In any case, find and AFS have never been friends and probably can't be.
>>
>> OpenAFS releases since 1.6.10 include the volscan(8) utility. It will not be
>> quite as trivial to use for your purposes since you need to run it on volumes
>> and stitch paths as seen by clients together yourself, but for just that
>> reason results will be meaningful - for example in the presence of circular
>> mounts. And it's much more efficient too.
>
> A small perl script called 'afs-vol-paths' is available in the openafs-contrib
> afs-tools repo on github which will process the output of volscan from each
> server to generate full paths. It will detect cycles too.  The repo is 
> located at:
>
> https://github.com/openafs-contrib/afs-tools
>
> and the file is under the admin directory.
>
> Thanks,
> Mike
>
> --
> Michael Meffie 



-- 
John W. Sopko Jr.
University of North Carolina
Computer Science Dept CB 3175
Chapel Hill, NC 27599-3175

Fred Brooks Building; Room 140
Computer Services
email: sopko AT cs.unc.edu
phone: 919-590-6144
___
OpenAFS-info mailing list
OpenAFS-info@openafs.org
https://lists.openafs.org/mailman/listinfo/openafs-info


Re: [OpenAFS] Linux find command inconsistent

2015-09-16 Thread John Sopko
On Tue, Sep 15, 2015 at 2:04 PM, Stephan Wiesand
 wrote:
>
> On Sep 15, 2015, at 15:46 , John Sopko wrote:
>
>> I run a monthly report to find all mount points and volumes using the
>> linux find command. I used to run this on Red Hat 5 for years. I moved
>> the script to Red Hat 6 and found after testing that on Red Hat 6 and
>> 7 and Ubuntu 14.04 the find command give inconsistent results and does
>> not find nearly as many files as Red Hat 5 does.
>>
>> I can copy the Red Hat 5 find binary to Red Hat 6 which executes ok
>> but still has a problem.
>
> The same "problem"?

I mean running the rhel5 executable on a rhel6 afs client machine does
not find all the directories as it does on rhel5. The rhel5 machine
always finds more directories then rhel6, rhel7 and Ubuntu 14.04, I
trust rehl5 the most.

>
>> I tried serveral client machines.
>>
>> For example on Red Hat 5 I run a command to find all directories and count 
>> them:
>>
>> % lsb_release -d
>> Description:Red Hat Enterprise Linux Client release 5.11 (Tikanga)
>>
>> |sopko@kramer:56% pwd
>> /afs/cs.unc.edu/project
>>
>> % find . -noleaf -type d | wc -l
>> 343403
>>
>> On Red Hat 6 I get:
>>
>> % lsb_release -d
>> Description:Red Hat Enterprise Linux Workstation release 6.7 (Santiago)
>>
>> |sopko@lark1:81% pwd
>> /afs/cs.unc.edu/project
>>
>> |sopko@lark1:82% find . -noleaf -type d | wc -l
>> find: `./par/Last_Backup/Last_Backup': No such device
>
> This suggests the client is refusing to recurse into the very same backup 
> volume (I assume "par" is a volume root and "par/Last_Backup" is a mount 
> point for the corresponding .backup volume?).

Some users mount their backup volume for easy access. I meant to
remove these messages and missed this one since it has never been an
issue on rhel5 and the find command does keep going on rhel6. I don't
think this is the issue.

>
>> 38763
>>
>> I also like to use the find command to set afs acl's on directories
>> but can not trust it to work.
>>
>> I am running 1.6.11 on the servers, 1.6.9 on the rhel5 client and
>> 1.6.11 on the rhel6 client and 1.6.14 on Ubuntu. Can anyone shed any
>> light on what is going on?
>
>
> See above. The RHEL6/Ubuntu result is likely to be the better one.
>
> In any case, find and AFS have never been friends and probably can't be.
>
> OpenAFS releases since 1.6.10 include the volscan(8) utility. It will not be 
> quite as trivial to use for your purposes since you need to run it on volumes 
> and stitch paths as seen by clients together yourself, but for just that 
> reason results will be meaningful - for example in the presence of circular 
> mounts. And it's much more efficient too.
>

I will look at volscan, thanks for your input.



-- 
John W. Sopko Jr.
University of North Carolina
Computer Science Dept CB 3175
Chapel Hill, NC 27599-3175

Fred Brooks Building; Room 140
Computer Services
email: sopko AT cs.unc.edu
phone: 919-590-6144
___
OpenAFS-info mailing list
OpenAFS-info@openafs.org
https://lists.openafs.org/mailman/listinfo/openafs-info


Re: [OpenAFS] Linux find command inconsistent

2015-09-15 Thread Stephan Wiesand

On Sep 15, 2015, at 15:46 , John Sopko wrote:

> I run a monthly report to find all mount points and volumes using the
> linux find command. I used to run this on Red Hat 5 for years. I moved
> the script to Red Hat 6 and found after testing that on Red Hat 6 and
> 7 and Ubuntu 14.04 the find command give inconsistent results and does
> not find nearly as many files as Red Hat 5 does.
> 
> I can copy the Red Hat 5 find binary to Red Hat 6 which executes ok
> but still has a problem.

The same "problem"?

> I tried serveral client machines.
> 
> For example on Red Hat 5 I run a command to find all directories and count 
> them:
> 
> % lsb_release -d
> Description:Red Hat Enterprise Linux Client release 5.11 (Tikanga)
> 
> |sopko@kramer:56% pwd
> /afs/cs.unc.edu/project
> 
> % find . -noleaf -type d | wc -l
> 343403
> 
> On Red Hat 6 I get:
> 
> % lsb_release -d
> Description:Red Hat Enterprise Linux Workstation release 6.7 (Santiago)
> 
> |sopko@lark1:81% pwd
> /afs/cs.unc.edu/project
> 
> |sopko@lark1:82% find . -noleaf -type d | wc -l
> find: `./par/Last_Backup/Last_Backup': No such device

This suggests the client is refusing to recurse into the very same backup 
volume (I assume "par" is a volume root and "par/Last_Backup" is a mount point 
for the corresponding .backup volume?).

> 38763
> 
> I also like to use the find command to set afs acl's on directories
> but can not trust it to work.
> 
> I am running 1.6.11 on the servers, 1.6.9 on the rhel5 client and
> 1.6.11 on the rhel6 client and 1.6.14 on Ubuntu. Can anyone shed any
> light on what is going on?


See above. The RHEL6/Ubuntu result is likely to be the better one.

In any case, find and AFS have never been friends and probably can't be.

OpenAFS releases since 1.6.10 include the volscan(8) utility. It will not be 
quite as trivial to use for your purposes since you need to run it on volumes 
and stitch paths as seen by clients together yourself, but for just that reason 
results will be meaningful - for example in the presence of circular mounts. 
And it's much more efficient too.

___
OpenAFS-info mailing list
OpenAFS-info@openafs.org
https://lists.openafs.org/mailman/listinfo/openafs-info


Re: [OpenAFS] Linux find command inconsistent

2015-09-15 Thread Brandon Allbery
On Tue, 2015-09-15 at 18:04 +, Stephan Wiesand wrote:
> OpenAFS releases since 1.6.10 include the volscan(8) utility. It will not be 
> quite as trivial to use for your purposes since you need to run it on volumes 
> and stitch paths as seen by clients together yourself, but for just that 
> reason results will be meaningful - for example in the presence of circular 
> mounts. And it's much more efficient too.

Is "ws" worth mentioning here? (And, where does that live these days?)

-- 
brandon s allbery kf8nh   sine nomine associates
allber...@gmail.com  ballb...@sinenomine.net
unix openafs kerberos infrastructure xmonadhttp://sinenomine.net
:��T���)b�   b�өzpJ)ߢ�^��좸!��l��b��(���~�+Y���b�ا~�~ȧ~

[OpenAFS] Linux find command inconsistent

2015-09-15 Thread John Sopko
I run a monthly report to find all mount points and volumes using the
linux find command. I used to run this on Red Hat 5 for years. I moved
the script to Red Hat 6 and found after testing that on Red Hat 6 and
7 and Ubuntu 14.04 the find command give inconsistent results and does
not find nearly as many files as Red Hat 5 does.

I can copy the Red Hat 5 find binary to Red Hat 6 which executes ok
but still has a problem. I tried serveral client machines.

For example on Red Hat 5 I run a command to find all directories and count them:

% lsb_release -d
Description:Red Hat Enterprise Linux Client release 5.11 (Tikanga)

 |sopko@kramer:56% pwd
/afs/cs.unc.edu/project

% find . -noleaf -type d | wc -l
343403

On Red Hat 6 I get:

% lsb_release -d
Description:Red Hat Enterprise Linux Workstation release 6.7 (Santiago)

 |sopko@lark1:81% pwd
/afs/cs.unc.edu/project

 |sopko@lark1:82% find . -noleaf -type d | wc -l
find: `./par/Last_Backup/Last_Backup': No such device
38763

I also like to use the find command to set afs acl's on directories
but can not trust it to work.

I am running 1.6.11 on the servers, 1.6.9 on the rhel5 client and
1.6.11 on the rhel6 client and 1.6.14 on Ubuntu. Can anyone shed any
light on what is going on?



-- 
John W. Sopko Jr.
University of North Carolina
Computer Science Dept CB 3175
Chapel Hill, NC 27599-3175

Fred Brooks Building; Room 140
Computer Services
email: sopko AT cs.unc.edu
phone: 919-590-6144
___
OpenAFS-info mailing list
OpenAFS-info@openafs.org
https://lists.openafs.org/mailman/listinfo/openafs-info


Re: [OpenAFS] Linux find command inconsistent

2015-09-15 Thread Michael Meffie

> See above. The RHEL6/Ubuntu result is likely to be the better one.
> 
> In any case, find and AFS have never been friends and probably can't be.
> 
> OpenAFS releases since 1.6.10 include the volscan(8) utility. It will not be
> quite as trivial to use for your purposes since you need to run it on volumes
> and stitch paths as seen by clients together yourself, but for just that
> reason results will be meaningful - for example in the presence of circular
> mounts. And it's much more efficient too.

A small perl script called 'afs-vol-paths' is available in the openafs-contrib
afs-tools repo on github which will process the output of volscan from each
server to generate full paths. It will detect cycles too.  The repo is located 
at:

https://github.com/openafs-contrib/afs-tools

and the file is under the admin directory.

Thanks,
Mike

-- 
Michael Meffie 
___
OpenAFS-info mailing list
OpenAFS-info@openafs.org
https://lists.openafs.org/mailman/listinfo/openafs-info