I need to respond to this in pieces... first the bit that is bugging
me:
* two new page flags
I need to keep track of two bits of per-cached-page information:
(1) This page is known by the cache, and that the cache must be informed if
the page is going to go away.
I still do not
Daniel Phillips [EMAIL PROTECTED] wrote:
I need to respond to this in pieces... first the bit that is bugging
me:
* two new page flags
I need to keep track of two bits of per-cached-page information:
(1) This page is known by the cache, and that the cache must be informed if
On Tuesday 26 February 2008 06:33, David Howells wrote:
Suppose one were to take a mundane approach to the persistent cache
problem instead of layering filesystems. What you would do then is
change NFS's -write_page and variants to fiddle the persistent
cache
It is a requirement laid
Daniel Phillips [EMAIL PROTECTED] wrote:
This factor of four (even worse on XFS, not quite as bad on Ext3) is
worth ruminating upon. Is all of the difference explained by avoiding
seeks on the server, which has the files in memory?
Here are some more stats for you to consider:
(1) Copy
On Monday 25 February 2008 15:19, David Howells wrote:
So I guess there's a problem in cachefiles's efficiency - possibly due
to the fact that it tries to be fully asynchronous.
OK, not just my imagination, and it makes me feel better about the patch
set because efficiency bugs are fixable
Daniel Phillips [EMAIL PROTECTED] wrote:
On Monday 25 February 2008 15:19, David Howells wrote:
So I guess there's a problem in cachefiles's efficiency - possibly due
to the fact that it tries to be fully asynchronous.
OK, not just my imagination, and it makes me feel better about the
Daniel Phillips [EMAIL PROTECTED] wrote:
The way the client works is like this:
Thanks for the excellent ascii art, that cleared up the confusion right
away.
You know what they say about pictures... :-)
What are you trying to do exactly? Are you actually playing with it, or
just
On Thursday 21 February 2008, David Howells wrote:
David Howells [EMAIL PROTECTED] wrote:
Have you got before/after benchmark results?
See attached.
Attached here are results using BTRFS (patched so that it'll work at all)
rather than Ext3 on the client on the partition backing the
Chris Mason [EMAIL PROTECTED] wrote:
The interesting case is where the disk cache is warm, but the pagecache is
cold (ie: just after a reboot after filling the caches). Here, for the two
big files case, BTRFS appears quite a bit better than Ext3, showing a 21%
reduction in time for the
David Howells [EMAIL PROTECTED] wrote:
Have you got before/after benchmark results?
See attached.
Attached here are results using BTRFS (patched so that it'll work at all)
rather than Ext3 on the client on the partition backing the cache.
And here are XFS results.
Tuning XFS makes a
Well, the AFS paper that was referenced earlier was written around the
time of 10bt and 100bt. Local disk caching worked well then. There
should also be some papers at CITI about disk caching over slower
connections, and disconnected operation (which should still be
applicable today).
Chris Mason [EMAIL PROTECTED] wrote:
Thanks for trying this, of course I'll ask you to try again with the latest
v0.13 code, it has a number of optimizations especially for CPU usage.
Here you go. The numbers are very similar.
David
=
FEW BIG FILES TEST ON
On Friday 22 February 2008 04:48, David Howells wrote:
But looking up the object in the cache should be nearly free - much less
than a microsecond per block.
The problem is that you have to do a database lookup of some sort, possibly
involving several synchronous disk operations.
Right,
Daniel Phillips [EMAIL PROTECTED] wrote:
I am eventually going to suggest cutting the backing filesystem entirely out
of the picture,
You still need a database to manage the cache. A filesystem such as Ext3
makes a very handy database for four reasons:
(1) It exists and works.
(2) It has
Daniel Phillips [EMAIL PROTECTED] wrote:
These patches add local caching for network filesystems such as NFS.
Have you got before/after benchmark results?
I need to get a new hard drive for my test machine before I can go and get
some more up to date benchmark results. It does seem,
Daniel Phillips [EMAIL PROTECTED] wrote:
Have you got before/after benchmark results?
See attached.
These show a couple of things:
(1) Dealing with lots of metadata slows things down a lot. Note the result of
looking and reading lots of small files with tar (the last result). The
On Thu, Feb 21, 2008 at 9:55 AM, David Howells [EMAIL PROTECTED] wrote:
Daniel Phillips [EMAIL PROTECTED] wrote:
Have you got before/after benchmark results?
See attached.
These show a couple of things:
(1) Dealing with lots of metadata slows things down a lot. Note the result
of
Hi David,
I am trying to spot the numbers that show the sweet spot for this
optimization, without much success so far.
Who is supposed to win big? Is this mainly about reducing the load on
the server, or is the client supposed to win even with a lightly loaded
server?
When you say Ext3
[mailto:[EMAIL PROTECTED]
Sent: Thursday, February 21, 2008 2:44 PM
To: David Howells
Cc: Myklebust, Trond; [EMAIL PROTECTED]; [EMAIL PROTECTED];
linux-fsdevel@vger.kernel.org; [EMAIL PROTECTED];
[EMAIL PROTECTED]; [EMAIL PROTECTED]
Subject: Re: [PATCH 00/37] Permit filesystem local caching
Hi David
David Howells [EMAIL PROTECTED] wrote:
Have you got before/after benchmark results?
See attached.
Attached here are results using BTRFS (patched so that it'll work at all)
rather than Ext3 on the client on the partition backing the cache.
Note that I didn't bother redoing the tests that
Daniel Phillips [EMAIL PROTECTED] wrote:
When you say Ext3 cache vs NFS cache is the first on the server and the
second on the client?
The filesystem on the server is pretty much irrelevant as long as (a) it
doesn't change, and (b) all the data is in memory on the server anyway.
The way the
On Thursday 21 February 2008 16:07, David Howells wrote:
The way the client works is like this:
Thanks for the excellent ascii art, that cleared up the confusion right
away.
What are you trying to do exactly? Are you actually playing with it, or just
looking at the numbers I've produced?
Quoting David Howells ([EMAIL PROTECTED]):
These patches add local caching for network filesystems such as NFS.
The patches can roughly be broken down into a number of sets:
(*) 01-keys-inc-payload.diff
(*) 02-keys-search-keyring.diff
(*) 03-keys-callout-blob.diff
Three
Serge E. Hallyn [EMAIL PROTECTED] wrote:
Seems *really* weird that every time you send this, patch 6 doesn't seem
to reach me in any of my mailboxes... (did get it from the url
you listed)
It's the largest of the patches, so that's not entirely surprising. Hence why
I included the URL to
Hi David,
On Wednesday 20 February 2008 08:05, David Howells wrote:
These patches add local caching for network filesystems such as NFS.
Have you got before/after benchmark results?
Regards,
Daniel
-
To unsubscribe from this list: send the line unsubscribe linux-fsdevel in
the body of a
25 matches
Mail list logo
