Samba performance issues: stat calls
Green, Paul
Paul.Green at stratus.com
Fri Apr 4 20:32:34 GMT 2003
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
More information about the samba-technical
mailing list