Samba performance issues: stat calls

[Green, Paul]

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

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.

-- 
Steve Langasek
postmodern programmer