From: Theodore Tso <tytso@mit.edu>
To: Jan Kara <jack@suse.cz>
Cc: linux-kernel@vger.kernel.org, linux-ext4@vger.kernel.org
Subject: Re: [RFC] [PATCH 3/3] Recursive mtime for ext3
Date: Tue, 6 Nov 2007 14:40:12 -0500 [thread overview]
Message-ID: <20071106194012.GE12857@thunk.org> (raw)
In-Reply-To: <20071106171945.GG23689@duck.suse.cz>
On Tue, Nov 06, 2007 at 06:19:45PM +0100, Jan Kara wrote:
> Intended use case is that application which wants to watch any
> modification in a subtree scans the subtree and sets flags for all
> inodes there. Next time, it just needs to recurse in directories
> having rtime newer than the start of the previous scan. There it can
> handle modifications and set the flag again. It is up to application
> to watch out for hardlinked files. It can e.g. build their list and
> check their mtime separately (when a hardlink to a file is created
> its inode is modified and rtimes properly updated and thus any
> application has an effective way of finding new hardlinked files).
Umm, yuck.
What if more than one application wants to use this facility?
The application is using a global per-inode flag that is written out
to disk. So sweeping the entire subtree and setting this flag will
involve a lot of disk i/o; as does setting a mod-time, since it could
potentially require a large number of inode updates, and then the
application needs to sweep through the subtree and reset the flags
(resulting in more disk i/o). The performance would seem to me to be
really pessimal.
In addition, after you crash, there might not be any application
waiting to watch modifications in that subtree, and yet the flags
would still be set so the system would still be paying the performance
penalties of needing to propagate modtimes until all of the flags
disappear --- and for a large subtree, that might not be for a long,
long time.
So if the goal is some kind of modification notification system that
watches a subtree efficiently, avoiding some of the deficiencies of
inotify and dnotify, the interface doesn't seem to be the right way to
go about things. The fact that only one application at a time can use
this interface, even if you ignore the issues of hard links and the
performance problems and the lack of cleanup after a reboot, seems in
my mind to just be a irreparable fatal flaw to this particular scheme.
Regards,
- Ted
next prev parent reply other threads:[~2007-11-06 19:41 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-11-06 17:15 [RFC] [PATCH 0/3] Recursive mtime for ext3 Jan Kara
2007-11-06 17:18 ` [RFC] [PATCH 1/3] " Jan Kara
2007-11-06 17:19 ` [RFC] [PATCH 2/3] " Jan Kara
2007-11-06 17:19 ` [RFC] [PATCH 3/3] " Jan Kara
2007-11-06 17:40 ` Arjan van de Ven
2007-11-06 18:04 ` H. Peter Anvin
2007-11-07 11:51 ` Jan Kara
2007-11-06 18:01 ` Al Viro
2007-11-07 14:54 ` Jan Kara
2007-11-06 19:40 ` Theodore Tso [this message]
2007-11-07 14:36 ` Jan Kara
2007-11-08 0:20 ` Theodore Tso
2007-11-08 10:56 ` Jan Kara
2007-11-08 14:37 ` Theodore Tso
2007-11-08 15:28 ` Jan Kara
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=20071106194012.GE12857@thunk.org \
--to=tytso@mit.edu \
--cc=jack@suse.cz \
--cc=linux-ext4@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
/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