Casey Schaufler [EMAIL PROTECTED] wrote:
+static int smack_task_kernel_act_as(struct task_struct *p,
+ struct task_security *sec, u32 secid)
+{
+ return -ENOTSUPP;
+}
...
+static int smack_task_create_files_as(struct task_struct *p,
+
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
If you get down to it, the thing is about delegating control over part
of namespace to somebody, without letting them control, see, etc. the
rest of it. So I'd rather be very conservative about extra information
we allow to piggyback on that. I don't know... perhaps with stable peer
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
10 matches
Mail list logo