[PATCH] Fix Name mangling in HEAD
idra at samba.org
Mon Mar 25 15:42:02 GMT 2002
On Mon, 2002-03-25 at 21:36, Andrew Bartlett wrote:
> Simo Sorce wrote:
> > Sorry Andrew but reverting back to 2.2 code is not the way to go on my
> > opinion, I made that code to solve many problems and bugs that apperead
> > in 2.2. code. The way to go is that me and tridge discussed on IRC, eg:
> I'm increasing of the opinion that the 2.2 approach is the only valid
> way to do this. We need an approach that scales with the size of the
> server - and your mangling TDB *DOES NOT*.
I know it currently *DOES NOT SCALE*, I was aware of the problem since
the beginning, and I made this implementationa s a proof of concept to
understand what could be the benefits and the problems.
> The results are quite painful - and I know the code was completely
> *untested* (It caused quite a few problems at my site - hence this and
> previous patches). Even moving to a larger hash presents *major* issues
> in scaleability - your mangling DB would have to be the same order of
> magnitude as the whole filesystem's combined metadata!
It was tested in the limits of my free time, we spotted some bugs, and a
> Worse still, a mangling TDB does not reflect changes in the filesystem -
> we keep stale entries around *for ever*.
Yes unless we put the code into VFS, putting the code there we will have
hooks to unlink call and we can easily remove entries (of course we will
not be able to do so for unix-side deleted ones, but we can easily
afford to create a tool to be run by cron at midnight that will parse
the fs and clean the tdb.
We _need_ the tdb, or every smbd reload/crash/shutdown (or cache limits)
could easly end up changing the mangled name and be sure windows app
will not be happy of that!
As soon as I have time I will address the problem.
Una scelta di liberta': Software Libero.
A choice of freedom: Free Software.
More information about the samba-technical