Re: UTF-8 and case-insensitivity

[Helge Hafting]

On Thu, Feb 19, 2004 at 12:11:32PM +0000, Paulo Marques wrote:
> tridge@xxxxxxxxx wrote:
> 
> >Currently dnotify doesn't give you the filename that is being
> >added/deleted/renamed. It just tells you that something has happened,
> >but not enough to actually maintain a name cache in user space.
> 
> This might be a crazy / stupid idea, so flame at will :)
> 
> Wouldn't it be possible to do a samba "super-server" mode, in which samba 
> would assume that it controlled the directories it is exporting?
> 
> In this mode a "corporate" Samba server, serving Windows clients, could 
> improve performance by assuming that its cache was always up-to-date.
> 
> If if we wanted to access the directory locally we could always mount 
> locally using samba, and access the files anyway, albeit a lot slower and 
> without linux permissions, etc.
> 
You don't really need to go to such extremes.  Samba can use dnotify,
and run with caching and great performance as long as nobody touch
the files in other ways.  There is no need to _enforce_ it though,
samba can cope by invalidating the cache on those rare occations
the files are accessed in other ways. It won't happen often, because:

1. Linux/nfs people have no business in a directory full of
   windows .dll's and .exe's
2. On a corporate server you simply tell people to stay out.
   nfs may export another set of homedirs for the unix people.

> What we would gain was the ability to say "I want to give priority to my 
> samba server" (and set it to "super-server" mode) or "my priority is to the 
> linux native filesystem, and just want to share my files with windows users 
> anyway" (and keep using samba as always).
>
Thanks to dnotify even the "linux priority" setup will be able to benefit
from a cache.  Particularly if we can get a dnotify that doesn't trip
when samba is the one making changes.  


Helge Hafting
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/