Displaying 4 results from an estimated 4 matches for "no_fsync".
Did you mean:
do_fsync
1997 Jul 16
0
SCO compilation of 1.9.16p10 and higher
...ifndef EVEREST
- #define ftruncate(f,l) syscall(0x0a28,f,l)
- #endif
#define SIGNAL_CAST (void (*)(int))
#define USE_WAITPID
#define USE_GETCWD
#define USE_SETSID
#ifdef SCO3_2_2
! #define NO_EID
#else
#ifndef EVEREST
#define USE_IFREQ
#endif
#endif
#define STATFS4
#define NO_FSYNC
- #ifndef EVEREST
- #define NO_INITGROUPS
- #endif
#define HAVE_PATHCONF
#define NO_GETRLIMIT
#endif
--- 668,689 ----
#include <prot.h>
#define crypt bigcrypt
#endif
#define SIGNAL_CAST (void (*)(int))
#define USE_WAITPID
#define USE_GETCWD
#define USE_SETSID
#ifdef SCO3...
1998 Aug 12
4
NT & Win98 slow copies
...te
> > per 1.5k (!) and one SMBflush per 1.5k!!!
> >
> > Anything above ONE SMBflush per file (at the end)
> > or one SMBwrite per 10k or so indicates a serious problem.
> >
> > A stop-gap measurement to get *usable* performance is
> > recompile with 'NO_FSYNC' defined (or the fsync() call
> > in server.c:sync_file() commented).
>
> This is what I'm going to do for 1.9.18p9, but I will
> parameterize it.
>
> > This removes the silly 'wait until everything is on
> > disk before continuing at every 1.5k', but...
1998 Jul 26
3
Slowdown when copying large files (PR#8617)
...his causes an enormous
slowdown as Samba (quite correctly) does a fsync() on the file after each
write. Combine this with the fact that Windows98 explorer uses very small
write sizes (around 1.5k) and you get really terrible results.
The only way to work around this at present is to add:
#define NO_FSYNC 1
in local.h and recompile Samba. This should give you an enormous speedup.
In one test I did tonight a speedup of a factor of 15 was observed.
As I have not yet witnessed a Windows program using the fsync bit correctly
(they all seem to treat it like flush, which is a quite different thing!)
you...
1998 Jul 27
1
Slowdown when copying large files (PR#8624)
...machine features one or two
> SMBwrite per 1.5k (!) and one SMBflush per 1.5k!!!
>
> Anything above ONE SMBflush per file (at the end) or one SMBwrite per 10k
> or so indicates a serious problem.
>
> A stop-gap measurement to get *usable* performance is recompile with
> 'NO_FSYNC' defined (or the fsync() call in server.c:sync_file()
> commented).
>
This is what I'm going to do for 1.9.18p9, but I will
parameterize it.
> This removes the silly 'wait until everything is on disk before continuing
> at every 1.5k', but doesn't fix the small bl...