Re: Recursive mtime implementation questions

[David Masover <ninja@slaphack.com>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

- -----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1



Fred Schaettgen wrote:
| On Thursday 13 January 2005 14:15, you wrote:
|
|>Fred Schaettgen wrote:
|
| ...
| ..
|
|>>>There is a union (file_plugin_data) in struct reiser4_inode to keep
|>>>features specific
|>>>for file plugins.
|>>
|>>I can't use that union, since my plugin would call the methods of the
|>>original file plugin of a file,
|>
|>Let's first specify the notification interface. Should it be kernel
|>messages, or
|>should the fs write something to /proc? (I don't have ideas)
|
|
| Actually I didn't think about active notification at all. The idea is
to set
| an timestamp for each monitored file, which is reset for the file
itself and
| the whole path(s) upwards when the file is changed.
| A userspace program which manages an index will find the newly changed
files
| by looking at that timestamp in some base directory and descending
into each
| subdirectory for which this timestamp is more recent than a saved
timestamp
| or if the timestamp isn't set at all. On the way back, the missing
timestamps
| will be updated.
| So it's by design a single-shot "notification" and you would have to
poll a
| single file to be able to update your stored data continously. This
should be
| adequate for applications which index large parts of the file system. For
| other needs, inotify will be the better solution.

Can't we use inotify on that single file, or even its own attribute (as
a meta-file) that we'd otherwise have to poll?  Sorry to nitpick, I just
want to be very clear at this stage.

| The pseudo-file interface could look like this:
| file/..../watch/m_timestamp [r]
| dir/..../watch/m_watch_file [w]
|
| m_timestamp is set for a file, when its name is written into the
| m_watch_file-attribute of one of it's parent directories.
| This will also add a link to the file back to the directory, so that
when the
| file is changed, the timestamp of both the file and the directory (and
so on)
| are reset.
| That's quite expensive, but it will happen only once per file, until the
| timestamp for a file was set again by a crawler.

And what's more, you often wouldn't have to travel farther up the tree
than the parent directory, if that parent is common to a lot of changing
files.

|>>so file_plugin_data is occupied already. I'm not sure
|>>if adding another field outside that union would make reiser4 perform any
|>>worse, but I was just hoping that this plugin can be implemented without
|>>any overhead at all as long as it is not used. A new feature is much more
|>>easily accepted if it doesn't affect you if you don't use it.
|>
|>This is why you need a new object plugin with its own methods.
|
|
| Ok, so creating a new file type called "watched_file" seems really the
right
| way.
| This still leaves the problem where to save per-inode data for this
plugin
| without having to increase the size of a reiser4_inode in general. I
don't
| care much, so before anyone else complains, I'll stop thinking about it ;)

The trick is converting normal files to watched_files.

- -----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.6 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iQIVAwUBQecKfHgHNmZLgCUhAQLLnxAAlgKzroTX0MTy/VVOLKr+4l+34/2g32AB
Rg9+kQWIeVpGfzyLpSy0DhO/0Mt01/9zDkvgYRGwgGhfw496BFPtkF/YvmlcFPbs
Txm5x/HiYjHinb5xah/Eq3lkTov/Y4eEyXvPJWk74MOS3MF/NAB8zuQ6ZLKf5LDT
w3eVxdMA/ubbpL6JmcCImeueJEdZ8ZXf+oI3AsQVmPW4gbaIZkCXxUem574BoVQc
tT6F7S9dmETw6M+VlSj0txWWE8iVwJ43QKErUSIpGgXVxSvE6pB97HrgD0oAwBrz
G1v+6ODRaW20zYdAbxH619Moq8KsubucWcwxSsHCK5mGSrwFqK1ry0w6CqxCXgxT
OiyNzPlW2WWZumRqmpI250EyS7JP7jdI+/xQFTB7OMr+9Pbveplrxm7BvRNwVKjB
y1G8F/hUDGaL0Rfb8ogG9tLMeNrVUpOOJ9gWBqnw7WglTxDUgmanNADzK1gEt1/E
HHh3tJDqFV0JR+zb+MhZt2OLJ9goGDEAva4Ckc8IGahkya13W/lj2eAP4c5jdi3O
OHW1UvHq4qBOlQyUQzHTjZVJqkb66e8OWUwb7+BTrXcbagNgOameDVhipEjZMn4+
LdrGjySWu4YFX/u4JAiyP0G1daiAqZ7bQ5amBh3JE0K0auRiConI0//iDwdXq+4e
O8piUEsBnQ8=
=Yb7h
- -----END PGP SIGNATURE-----
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.6 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iQIVAwUBQecKqXgHNmZLgCUhAQKxHQ/9Fb7IPLnqcHuhNK01djVpDLfc/7L7TRVG
4dU7cG27VDGrqbRjXOIdtjwBSxcKO0+pQHcGccMpd7+gNu6Z+xVzcivj0qBBhrcY
wIU4lPM6r2Izbj73b5qEOAh/UtX1+cfyJ5gihDl69sIlePZF0lgmYhTxvz9L24Sx
QFvw76Ei1UvSncP7QIkn9znZiPUTTi57Xs9u5vX5HI9tVQWQgvPxwbOeN4T25RC/
IY6kd507oGgz3kRKcd5ji3UDXcgFcdvaFWn7gWd3uGSqK44KujX5D3NDNs3P18JM
9D0xGUyUgd/Nuxokb+qmGTmAVTaUYOoWSMOUYFpt3mlwDgZZ5+dH4pIA2cH3qCpe
uQZVi3n7fPPpE+Q9BrgaPn+vmkZ9yoqEt5Zzlp58AtlXmtNnmuBOYH7BO3iXyz8U
wGPLNAsFpTByA1p08QVRyuBkzCG9jw1a7dlwpMrsoaOH7k/2Yw/vhW1B/CgyUnAP
aQCRYIGkekUc6XSM0uhaCDyF3wMTsn0Ec1aI9ZzObfA0IOh0is9vzBc6cXRAvHcs
sbY0DBVD7vhLNwvEfrN6JYKrvxdfJ+n89Gkd6rn2Jtc7n2m3Fllq3S2Cx+ch87L6
xfRYZGM79HOJB5C7a2HZT4vNWNDsdfXAn3gffsFSSHq558Srz8K27Or3MRCf9Ec5
tI201Z6LZo4=
=f3Th
-----END PGP SIGNATURE-----