[lkml]   [2004]   [Aug]   [31]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: silent semantic changes with reiser4
Hash: SHA1
Christer Weinigel wrote:
| Pavel Machek <> writes:
|>Okay, that does work, it just is not really nice. Just as reserving
|>fixed ammount of space for disk cache is bad, reserving fixed ammount
|>of space for ccache (and similar) is bad. When there are few of such
|>caches, balancing between them starts to matter...
| So try to convince them to use the same cache daemon or the same
| shared cache manager library then. It isn't all that different from
| implementing a kernel interface that everyone is supposed to use.

You're right, it's not. Is there some huge performance loss by having a
kernel interface that then turns around and calls a userland daemon? If
yes, I can understand the argument. If no, then the kernel interface
should ultimately be able to replace gnome-vfs -- and it should rely
heavily on userland utilities.

Caching is very generic. It's so generic that there should be exactly
one cache manager, the way there is exactly one VM manager for Linux.
If there's a choice, choose it at boot or compile-time.

Abiword uses gzipped files. So does gnumeric, gnucash, cube (a cute
little game engine), and many others. There's no way every single one
will suddenly use a new library/daemon. But with plugins and
intelligent caching, any kind of compression could be supported without
the app needing to support it natively -- either it goes in a compressed
folder or the user browses to it and changes an attribute.

| A cache manager daemon could sit and watch the free space on the disk
| every other second and start deleting the cached files (according to
| some LCU heuristics or whatever) whenever free space is getting low.

Agreed. The daemon should go in userspace. But the interface should be
in the kernel. Just as no one suggested putting tar in the kernel, I
don't think anyone would really insist that the daemon needs to go in
the kernel.

That is, unless critical system files start actually being cached
streams of the actual package from the distro... But this way leads to
madness. Any serious issues here are better solved by an initrd.

| I belive the kernel could give some assistance to make it easier to
| see if a file has been modified, I remember that a few suggestions
| were thrown around the last time Samba and dcache aliases were
| discussed on l-k. I definitely belive that kind of infrastructure
| belongs in the kernel. But the cache manager itself, no.

Isn't there already dnotify?

Dnotify is wrong here, because I don't think it would be sane in a
sufficiently large setup. But wouldn't it be nice if the kernel not
only told you whether a file has been modified, but told you immediately
after it was modified?

Yet another reason why there has to be a common cache and significant
kernel management -- if I've got a drive of less than, say, 5 gigs, I am
simply not willing to reserve any large amount of it for cache. Take
the example of a source tarball being automatically extracted and the
contents cached.
Version: GnuPG v1.2.4 (GNU/Linux)
Comment: Using GnuPG with Thunderbird -
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at
 \ /
  Last update: 2005-03-22 14:05    [from the cache]
©2003-2014 Jasper Spaans. hosted at Digital Ocean