public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Per-Olof Pettersson <lkml.lists@peope.net>
To: Jamie Lokier <lfs@tantalophile.demon.co.uk>,
	linux-kernel@vger.kernel.org
Subject: Re: Introducing FUSE: Filesystem in USErspace
Date: Sun, 18 Nov 2001 17:35:30 +0100	[thread overview]
Message-ID: <3BF7E352.5090700@peope.net> (raw)
In-Reply-To: <200111121128.MAA15119@duna207.danubius> <20011117175253.A5003@kushida.jlokier.co.uk>

Jamie Lokier wrote:

> Miklos Szeredi wrote:
> 
>>    - Thin layer in kernel. Minimal caching, predictable behavior.
>>
> 
> Minimal caching?  I would hope for maximal caching, for when userspace
> is able to say "yes the page you have is still valid".  Preferably
> without a round trip to userspace for every page.

Caching userspace filesystems is dependant of the implimentation. You 
would need to send some info to the kernel-part saying "Yes this part 
can be cached this long without a signal to userspace".

This would be equal to the caching-mechanism in a Web-server.

Most often the userspace-part would not know what parts will not change 
in a certain amount of time.. But then again.. Some implementations could.

Another way could be an explicit call to the kernel by the Userspace 
File System saying "Now this caching is no longer valid".

One implementation with static data could be a fs that is tied to a prog 
retrieving statistical data eg. Perhaps it is supposed to be run each 
hour. Then you would know "good enough" that the data has not been 
changed until next update. But suppose you manually restart the update 
of data, you would need to tell the kernel that caching of old data is 
not valid anymore.

Thing is you need the kernel-part to be told what can be cached, what 
cannot and how long it can be cached.

Then you would need a mechanism for the Userspace-part to make a caching 
invalid.

There is probably more into this than just these fundamentals.. And a 
simple working (not buggy) FS is preferred than a complicated (possibly 
buggy) FS that will never be released and is difficult to write 
userspace code for IMHO.

Best regards
Per-Olof Pettersson


  reply	other threads:[~2001-11-18 16:37 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2001-11-12 11:28 Introducing FUSE: Filesystem in USErspace Miklos Szeredi
2001-11-17 17:52 ` Jamie Lokier
2001-11-18 16:35   ` Per-Olof Pettersson [this message]
2001-11-19  8:48   ` Miklos Szeredi

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=3BF7E352.5090700@peope.net \
    --to=lkml.lists@peope.net \
    --cc=lfs@tantalophile.demon.co.uk \
    --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