much about it. As a KDE developer,
I'm not much involved in filesystems, so maybe I'm just looking for the wrong
keywords?
Fred
--
Fred Schaettgen
[EMAIL PROTECTED]
a userspace daemon at a later time.
If just the test for the existance of the change monitor flag could be made
efficient enough, then the overhead during regular operation would be
negligible.
I hope that this outline was clear enough to let you tell me if this is
possible or why it isn't :)
bye and a happy new year to one half of the world!
Fred
--
Fred Schaettgen
[EMAIL PROTECTED]
On Saturday 01 January 2005 01:51, you wrote:
> Fred Schaettgen wrote on Fri, 31 Dec 2004 10:47:14 +0100:
> > The purpose btw. is to find all modified files in a tree as fast as
> > possible. There are quite a lot of application which would benefit from
> > it: desktop s
plemented 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
[EMAIL PROTECTED]
file systems. Maybe that's the reason I had to ask my
question here. Or where else am I allowed to ask such a question in your
opinion?
Fred
--
Fred Schaettgen
[EMAIL PROTECTED]
You may be right.
But I thought it might still be worth trying. Especially since reiser4 with
it's heavily advertised plugin system seems to be somewhat more open to
extensions. And I'm sure that a much smaller extension than those of the BeOS
fs would be sufficient.
Fred
--
Fred Schaettgen
[EMAIL PROTECTED]
tore the cached metadata. If the FS just reports the
changed files somehow, you can decide what metadata needs to be invalidated
in userspace.
And since you have to call back to userspace for the zipfile scenario anyway,
why not let userspace do the metadata cache invalidation too?
Fred
--
Fred Schaettgen
[EMAIL PROTECTED]
me time.
Is it possible for reiser4 to do a number of - rarley, but still - deeply
nested transactions?
regards
Fred
--
Fred Schaettgen
[EMAIL PROTECTED]
On Tuesday 11 January 2005 15:41, Edward Shishkin wrote:
> Fred Schaettgen wrote:
> >I'm trying to get started with my idea of recursive mtimes, which where
> >discussed a few days ago, but I'm stuck a little. Maybe someone with some
> >more knowlege about r
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
pert, but isn't the free space just a a rough estimation? You
can't know in advance what the average file size will be etc. Maybe reiser4
is just more conservative. What matters is how much data is actually stored
on the disk the moment it runs full.
Fred
--
Fred Schaettgen
[EMAIL PROTECTED]
On Thursday, 22. September 2005 18:41, Edward Shishkin wrote:
> Grzegorz Jaśkiewicz wrote:
> >I think there should be file attribute that says whether it is
> >compressed/whatever/ or not.
>
> Right. All the plugins responsible for compression, etc.. will be observed
> via pseudo-file interface
>
>
On Thursday, 22. September 2005 22:03, Edward Shishkin wrote:
> Fred Schaettgen wrote:
> >I don't quite understand how the file plugin concept scales once we get
> > more of them. For instance if I want to have an additional attribute
> > attached to my files, which c
13 matches
Mail list logo
