Re: Help wanted for statvfs extension

Mike Hall <[e-mail]> wrote in message news:<[e-mail]>...
> Daniel Berger wrote:
> 
> > Is the mntent.h file in different locations depending on the OS?  That
> > will need to be solved if that's the case.
> 
> Yep.

I don't know nearly enough about the preprocessor or ruby.h to know
how to do this.  Like I said, my C is *rusty*.  I've also discovered
that the C books I own only briefly touch on the preprocessor (if at
all).  Time for a book run. :)

<snip>
 
> Does Solaris even have 'getmntent'?
> Hmm...  yup!  And it's totally different.  Yee-hah!
> You/I need to include 'mnttab.h'.
> Also change default '/etc/mtab' to '/etc/mnttab'.
> Redo all the field names.
> Redo file open/close.
> 
> Maybe have one core section, and separate os-dependent files?

Actually, couldn't some of this be handled in the makefile somehow? 
Time to bust out "Managing projects with make" (ORA).  I just happened
to be skimming over the Ellemtel coding standards and one of the
things they mentioned is that you shouldn't use path names in
'include' statments.  It should be handled by the make file.  So,
ideally we should have "#include <statvfs.h>" without the "sys", and
have the makefile deal with locating it.

> 
> > Also, why did you create an internal struct to store basetypes (fsid)?
> >  Isn't that information already stored in the statvfs struct as
> > 'basetype' (f_basetype)?
> 
> Never heard of that.  Not on Lx?  We only get 'f_type' number
> in the 'statfs' and get to decode it.  Didn't think a Ruby 
> programmer would care much about 0xEF53.

Time for a preprocessor directive, methinks. I've got Linux (Mandrake)
at home and Solaris at work, so it makes for a good comparison.

> 
> > Also, what happens if I don't send a path as an argument to stat()?
>  
> 	> Filesystem.stat
> 	ArgumentError: wrong # of arguments(0 for 1)
> 
> Same as 'File.open' with no file name.
> I guess it could default to root?
> 
> > Can I iterate over each filesystem? e.g.
>  
> > Filesystem.stat("/tmp") { |fs|
> >    p fs.size
> >    p fs.name
> > }
> 
> No, it doesn't accept blocks. 
> It returns a Ruby structure with all the members populated.
> It gets all the info at once.
> 
> Using a block seems like the same thing as:
> 
> 	Time.new { |t| 
> 	  p t.years
> 	  p t.months
> 	}
> 
> Didn't see the need for it.  Were my eyes closed?

I see two potential problems here.  First, what if I want data on
every filesystem, instead of just one?  I mean, that's what a 'df'
command without arguments produces.  I think an iterator would be
polite since it's very possible I'll want to deal with information on
every filesystem, not just one.  Another possibility would be to
return an array of hashes (or some data struct - I'm thinking in Perl
at the moment). Or both.

Let me provide you with an example to hammer in the point.  You have
been given the task of monitoring disk space on 50 hosts.  You aren't
familiar with the filesystem layout on most (or any) of them.  Your
boss says he wants you to write a Ruby program that checks each and
every filesystem on every host once per hour.  If any filesystem on
any host reaches a capacity of 98% or higher, send the boss a page.

If you have to pass the path name as an argument you're hosed because
you *don't know* all the filesystem names (other than root).  But if
you don't have to know them in advance, you can just iterate over
every one in turn.

Second, you mentioned that it gets info "all at once".  What happens
if I do this:

fs = Filesystem.stat('/some/dir')
puts fs.bavail
copy(some_huge_file, copy_of_some_huge_file)
puts fs.bavail

Will the second call use an updated value or will it use a stored
value?  While I understand it may be a bit slower, I definitely think
that each call should be dynamic.  If your module already does this,
please disregard. :)

Well, there it is.  Comments (by all) welcome.

Regards,

Dan