From: Fred Schaettgen <namesys.Sch@ttgen.net>
To: reiserfs-list@namesys.com
Subject: Re: Recursive modified-timestamp?
Date: Sat, 1 Jan 2005 12:56:33 +0100 [thread overview]
Message-ID: <200501011256.33535.namesys.Sch@ttgen.net> (raw)
In-Reply-To: <1909372133-BeMail@cr593174-a>
On Saturday 01 January 2005 04:12, you wrote:
...
> That reminds me that the other thing BeOS had was a change notification
> system using messaging. If you requested monitoring of a directory or
> file (with flags to say which kind of changes are of interest) then
> it would send your program a BMessage with the details (such as a file
> being added to a directory).
Do you know if this service was actually provided by the file system or was it
just a clever use of a more simple feature of the fs which allows to do that?
There are certainly a lot of things which could be done, if changed files can
be found quickly, but those things don't need to go into fs itself.
> But I don't think that's quite what you wanted (and isn't as economical
> as your tree of percolated up modification times). Though it would be
> nifty (but useless?) to have a build system (make-like) operating in real
> time - change a source file and the system automatically recompiles it
> immediately.
With "change notification flag" I didn't mean to have the send messages, but
put links to the file into a folder, so a daemon can poll for changes. I
guess polling is better in this case, since it limits the overhead even in
persence of many changes.
It's certainly not most important for build systems, at least as long as the
source tree is reasonable small. Just an example among others.
> > Moving too much logic into the file system has lots of drawbacks. It
> > makes the file system complicated, so it will be less likely to be
> > implemented at all.
>
> True. That's why I think query evaluation should be outside the file
> system, with just the indices in the kernel / file system API. But
> that's another story.
No, that's exacly the story. If you want to index various attributes of files,
so that the index can be quickly updated when it's needed. We don't have to
go into details about what you do with that indices in userspace. What we
need to discuss is what changes to the file system would be neccessary, so
that everything you have in mind could be done efficiently.
I claim that the approach I described...
- ...allows all these things to be done efficiently in userspace.
- ...is the smallest change to the fs neccessary for it.
- ...could be implemented in reiser4 without significant performance losses.
Of course I'm not at all sure about these claims, so that's why I'm asking ;)
bye and a Happy new year (to everyone this time)
Fred
--
Fred Schaettgen
Sch@ttgen.net
next prev parent reply other threads:[~2005-01-01 11:56 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-12-31 9:47 Recursive modfied-timestamp? Fred Schaettgen
2004-12-31 22:49 ` David Masover
2005-01-01 0:43 ` Recursive modified-timestamp? Fred Schaettgen
2005-01-01 3:12 ` Alexander G. M. Smith
2005-01-01 11:56 ` Fred Schaettgen [this message]
2005-01-01 12:28 ` Piotr Neuman
2005-01-01 13:20 ` Fred Schaettgen
2005-01-01 17:08 ` Piotr Neuman
2005-01-01 18:18 ` Fred Schaettgen
2005-01-01 0:51 ` Recursive modfied-timestamp? Alexander G. M. Smith
2005-01-01 21:49 ` Hans Reiser
2005-01-02 4:22 ` AMD64/Reiser4 testing and problems Isaac Chanin
-- strict thread matches above, loose matches on Subject: below --
2005-01-01 18:59 Recursive modified-timestamp? Alexander G. M. Smith
2005-01-02 17:52 ` Hans Reiser
2005-01-06 22:31 ` David Masover
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=200501011256.33535.namesys.Sch@ttgen.net \
--to=namesys.sch@ttgen.net \
--cc=reiserfs-list@namesys.com \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.