-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
KaiGai,
I've just tried to build this with a separate obj tree: make O=/path.../
~ the build failed as follows:
~ CC security/dummy.o
~ CC security/inode.o
~ CAPSsecurity/cap_names.h
/bin/sh: security/../scripts/mkcapnames.sh: No
Kohei KaiGai 写道:
[2/3] Exporting capability code/name pairs
This patch enables to export code/name pairs of capabilities the running
kernel supported.
supported or supports ?
A newer kernel sometimes adds new capabilities, like CAP_MAC_ADMIN
at 2.6.25. However, we have no interface to
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
On Fri, Feb 22, 2008 at 06:45:32PM +0900, Kohei KaiGai wrote:
I believe it is correct assumption that long type and pointers have
same width in the linux kernel. Please tell me, if it is wrong.
That is correct, it is one of the assumptions that is safe to make. But
you should fix the compiler
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
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