[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 -

    -----END PGP SIGNATURE-----
    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    [W:0.023 / U:0.900 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site