public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: tridge@samba.org
To: "Theodore Ts'o" <tytso@mit.edu>
Cc: Pascal Schmidt <der.eremit@email.de>, linux-kernel@vger.kernel.org
Subject: Re: UTF-8 and case-insensitivity
Date: Thu, 19 Feb 2004 14:20:44 +1100	[thread overview]
Message-ID: <16436.11148.231014.822067@samba.org> (raw)
In-Reply-To: <20040219024426.GA3901@thunk.org>

Ted,

 > Actually, not necessarily.  What if Samba gets notifications of all
 > filename renames and creates in the directory, so that after the
 > initial directory scan, it can keep track of what filenames are
 > present in the directory?  It can then "prove the negative", as you
 > put it, without having to continuously do directory scans.

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.

That could be changed, so that on a dnotify event you do a fcntl() to
ask for the name of the file. Or perhaps we could cram it into the
structure the signal handler gets passed? I doubt that would make
sense, but maybe some signal guru can tell me otherwise. Maybe we
could even invent a new dnotify system where you do a read on a file
descriptor to get details on what event happened, and give some
"everything has changed" error when you run out of buffers.

If that happened then we could build our own dcache in user space, but
it will be a very second rate dcache, with a racy and slow update
mechanism that will in itself chew cpu. Maybe thats the best we can
do, or maybe I should be asking distro vendors if they would consider
a case-insensitive patch, especially the vendors aiming for
"enterprise" scalability which might include serving windows clients.

 > Yeah, there can be some race conditions, but Samba already has to deal
 > with the race condition where it tries to create "MaKeFiLe" either
 > just before or just after a Posix process creates "Makefile".  

yes, thats true. 

The races aren't my primary concern really. I've spent the last week
doing profiling of a large Samba install, and after fixing a
horrendous scalability problem do to with fcntl locking (more on that
later) the next thing on the profile is stat() and directory
scans. That's why the efficiency of this stuff is a hot topic for me
right now.

It's not all as bleak as perhaps I make it seem though. I suspect
there is still quite a bit of improvement that can be made in Samba
just because our code is so messy that sometimes we do a stat() call
or a directory scan when perhaps we can prove that we don't need
to. The Samba4 code is much cleaner, and maybe we have room to keep
improving things for a couple of years by finding those inefficiencies
and fixing them. We will eventually hit a wall, but it could be a fair
way off. Maybe windows will be dead by then.

Cheers, Tridge

  reply	other threads:[~2004-02-19  3:21 UTC|newest]

Thread overview: 69+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <1q4Si-658-5@gated-at.bofh.it>
     [not found] ` <1q7no-8ss-7@gated-at.bofh.it>
     [not found]   ` <1qfb7-7s5-19@gated-at.bofh.it>
     [not found]     ` <1qmPm-6Gl-11@gated-at.bofh.it>
     [not found]       ` <1qpWI-1Sa-1@gated-at.bofh.it>
     [not found]         ` <1qqpO-2lx-3@gated-at.bofh.it>
     [not found]           ` <1qqzv-2tr-3@gated-at.bofh.it>
     [not found]             ` <1qqJc-2A2-5@gated-at.bofh.it>
     [not found]               ` <1qHAR-2Wm-49@gated-at.bofh.it>
     [not found]                 ` <1qIwr-5GB-11@gated-at.bofh.it>
     [not found]                   ` <1qIwr-5GB-9@gated-at.bofh.it>
     [not found]                     ` <1qIQ1-5WR-27@gated-at.bofh.it>
     [not found]                       ` <1qIZt-6b9-11@gated-at.bofh.it>
     [not found]                         ` <1qJsF-6Be-45@gated-at.bofh.it>
2004-02-19  0:06                           ` UTF-8 and case-insensitivity Pascal Schmidt
2004-02-19  1:01                             ` tridge
2004-02-19  1:08                               ` Hua Zhong
2004-02-19  1:46                                 ` tridge
2004-02-19  2:44                               ` Theodore Ts'o
2004-02-19  3:20                                 ` tridge [this message]
2004-02-19 10:18                                   ` Helge Hafting
2004-02-19 12:11                                   ` Paulo Marques
2004-02-19 19:04                                     ` Helge Hafting
2004-02-19 14:08                                   ` Theodore Ts'o
2004-02-19 20:12                                   ` Robert White
     [not found] <fa.epf5o9k.1rkudgo@ifi.uio.no>
     [not found] ` <fa.idvvhjl.1jge92d@ifi.uio.no>
2004-02-18  1:09   ` Andy Lutomirski
2004-02-17  4:12 tridge
2004-02-17  5:11 ` Linus Torvalds
2004-02-17  6:54   ` tridge
2004-02-17  8:33     ` Neil Brown
2004-02-17 22:48       ` tridge
2004-02-18  0:06         ` Neil Brown
2004-02-18  9:47           ` Helge Hafting
2004-02-17 15:13     ` Linus Torvalds
2004-02-17 16:57       ` Linus Torvalds
2004-02-17 19:44         ` viro
2004-02-17 20:10           ` Linus Torvalds
2004-02-17 20:17             ` viro
2004-02-17 20:23               ` Linus Torvalds
2004-02-17 21:08         ` Robin Rosenberg
2004-02-17 21:17           ` Linus Torvalds
2004-02-17 22:27             ` Robin Rosenberg
2004-02-18  3:02               ` tridge
2004-02-17 23:57         ` tridge
2004-02-17 23:20       ` tridge
2004-02-17 23:43         ` Linus Torvalds
2004-02-18  3:26           ` tridge
2004-02-18  5:33             ` H. Peter Anvin
2004-02-18  7:54             ` Marc Lehmann
2004-02-18  2:37         ` H. Peter Anvin
2004-02-18  3:03           ` Linus Torvalds
2004-02-18  3:14             ` H. Peter Anvin
2004-02-18  3:27               ` Linus Torvalds
2004-02-18 21:31                 ` tridge
2004-02-18 22:23                   ` Linus Torvalds
2004-02-18 22:28                     ` Linus Torvalds
2004-02-18 22:50                       ` tridge
2004-02-18 22:59                         ` Linus Torvalds
2004-02-18 23:09                           ` tridge
2004-02-18 23:16                             ` Linus Torvalds
2004-02-19  8:10                               ` Jamie Lokier
2004-02-19 16:09                                 ` Linus Torvalds
2004-02-19 16:38                                   ` Jamie Lokier
2004-02-19 16:54                                     ` Linus Torvalds
2004-02-19 18:29                                       ` Jamie Lokier
2004-02-19 19:08                                       ` Helge Hafting
2004-02-18  4:08           ` tridge
2004-02-18 10:05             ` Robin Rosenberg
2004-02-18 11:43               ` tridge
2004-02-18 12:31                 ` Robin Rosenberg
2004-02-18 16:48                   ` H. Peter Anvin
2004-02-18 20:00                     ` H. Peter Anvin
2004-02-19  2:53   ` Daniel Newby
2004-02-17  5:25 ` Tim Connors
2004-02-17  7:43 ` H. Peter Anvin
2004-02-17  8:05   ` H. Peter Anvin
2004-02-17 14:25 ` Dave Kleikamp
2004-02-18  0:16 ` Robert White
2004-02-18  0:20   ` Linus Torvalds
2004-02-18  1:03     ` Robert White
2004-02-18 21:48     ` Ville Herva
2004-02-18  2:48   ` tridge
2004-02-18 20:56     ` Robert White

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=16436.11148.231014.822067@samba.org \
    --to=tridge@samba.org \
    --cc=der.eremit@email.de \
    --cc=linux-kernel@vger.kernel.org \
    --cc=tytso@mit.edu \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox