Samba performance issues: stat calls

[Richard Sharpe]

On Fri, 4 Apr 2003, Green, Paul wrote:

> I do have a copy of the POSIX-96 and POSIX-2001 standards here.

OK, I screwed up.

What I really meant to say was that we keen time in nano-seconds or 
hundredths of microseconds (which requires a 64-bit field), but our Posix 
subsystem converts that to seconds since the Epoch, and then in Samba we 
convert back again.
 
> st_atime, st_mtime, and st_ctime are required to have the time_t type, and
> further required to count in units of seconds since the Epoch.  POSIX-96
> defers to the ISO C standard for time_t.  POSIX-2001 says (under
> sys/types.h) that time_t must be an integer or real-floating(!) arithmetic
> type.
> 
> The 1990 C standard says time_t is an arithmetic type capable of
> representing times.
> The 1999 C standard adds that the range and precision of time_t are
> implementation defined.
> 
> So, Steve is right. POSIX itself is fine. Some particular implementation is
> the issue.
> 
> Probably more than you wanted to know.
> 
> PG
> 
> 
> -----Original Message-----
> From: Steve Langasek [mailto:vorlon at netexpress.net]
> Sent: Friday, April 04, 2003 2:22 PM
> To: Richard Sharpe
> Cc: Andrew Bartlett; Simo Sorce; Multiple recipients of list
> SAMBA-TECHNICAL
> Subject: Re: Samba performance issues: stat calls
> 
> 
> On Fri, Apr 04, 2003 at 10:19:57AM -0800, Richard Sharpe wrote:
> > On Fri, 4 Apr 2003, Simo Sorce wrote:
> 
> > > On Fri, 2003-04-04 at 19:53, Richard Sharpe wrote:
> > > > On Fri, 4 Apr 2003, Andrew Bartlett wrote:
> > > > 
> > > > > On Thu, 2003-04-03 at 18:06, Michael B.Allen wrote:
> > > > > > On Wed, 2 Apr 2003 19:26:36 -0800 (PST)
> > > > > > Richard Sharpe <rsharpe at richardsharpe.com> wrote:
> > > > > > 
> > > > > > > That looks like an average of more than one stat call per SMB.
> Not good!
> > > > > > 
> > > > > > Don't you have to stat each label in a path as you walk it?
> > > > > 
> > > > > Yes, given how Samba works, one stat per smb is actually pretty
> low...
> > > > 
> > > > Well, stat just hit number 1 problem for me :-)
> > > > 
> > > > I have got to look at converting it to an IOCTL in our case, because
> our 
> > > > file system keeps times a 64-bit quantities, but POSIX is so aweful
> that 
> > > > we have to convert them to 32-bits in our POSIX subsystem and then
> back to 
> > > > 64-bits in Samba.
> 
> > > even in 64bit systems??
> 
> > The standard POSIX stat call returns 32-bit times, I believe.
> 
> On my 64-bit Linux systems, I have:
> 
> struct stat
> { 
>     [...]
>     __time_t st_atime;          /* Time of last access.  */
>     __time_t st_mtime;          /* Time of last modification.  */
>     __time_t st_ctime;          /* Time of last status change.  */
>     [...]
> }
> 
> AFAIK (and I don't have a copy of the spec handy to confirm -- just
> manpage references), POSIX only defines that these members should be
> 'time_t', it does not define the size of time_t itself.  I see __time_t
> defined here as a 'long int', which makes it 64-bit on 64-bit
> architectures.
> 
> So I don't think your hands are tied by POSIX zipties here, though of
> course changing the size of a member of a published structure is
> difficult in its own right.
> 
> 

-- 
Regards
-----
Richard Sharpe, rsharpe[at]ns.aus.com, rsharpe[at]samba.org, 
sharpe[at]ethereal.com, http://www.richardsharpe.com