On Fri, 22 Oct 2010 12:06:37 +0100
Sad Clouds wrote:
> Well if you're allocating memory yourself, then you've just created your
> own application cache.
Say many files were mapped in the process's address space, the OS would
still be responsible of keeping frequently used ones pages active,
poss
On Oct 22, 2:25pm, m...@eterna.com.au (matthew green) wrote:
-- Subject: re: [patch] - add support for >2TB raid devices
| after talking some more with greg oster, i've gone with a suggestion
| from him to not bump the version, since the new field will be zero
| in all existing labels already, so
On Oct 22, 1:21pm, m...@eterna.com.au (matthew green) wrote:
-- Subject: re: [patch] - add support for >2TB raid devices
| that's not what i'm saying.
|
| when version 3 is introduced, all this code will need to be
| fixed. but your idea depends upon version 3 having the same
| basic layout, wh
On Fri, 22 Oct 2010 05:54:48 -0400
Matthew Mondor wrote:
> On Fri, 22 Oct 2010 10:18:52 +0100
> Sad Clouds wrote:
>
> > A pipelined request, say for 10 small files can be served with a
> > single writev() system call (provided those files are cached in
> > RAM), if you rely on kernel file cache
On Fri, 22 Oct 2010 10:18:52 +0100
Sad Clouds wrote:
> A pipelined request, say for 10 small files can be served with a single
> writev() system call (provided those files are cached in RAM), if you
> rely on kernel file cache, you need to issue 10 write() system calls.
Is this also true if the
On Fri, 22 Oct 2010 08:13:34 +0200
Michael van Elst wrote:
> On Thu, Oct 21, 2010 at 10:40:15PM +0100, Sad Clouds wrote:
>
> > I do realise this reinvents kernel file cache, but it gives you a
> > lot more flexibility over what files get cached in memory and you
> > can plug custom algorithms ov
