On Tuesday 22 May 2001 20:20, David N. Lombard wrote:
> Rik van Riel wrote:
> > On Tue, 22 May 2001, Daniel Phillips wrote:
> > > On Tuesday 22 May 2001 12:29, Daniel Phillips wrote:
> > > > http://nl.linux.org/~phillips/htree
> > >
> > > Oops, nl.linux.org was down for 'unscheduled maintainance
Rik van Riel wrote:
>
> On Tue, 22 May 2001, Daniel Phillips wrote:
> > On Tuesday 22 May 2001 12:29, Daniel Phillips wrote:
>
> > > http://nl.linux.org/~phillips/htree
> >
> > Oops, nl.linux.org was down for 'unscheduled maintainance' and seems
> > to have come back up with some some http iss
> > was _just_ copied from another file system (still in buffer/cache).
> You might consider rebooting to flush the cache.
>
Is it possible to achieve the same by umounting/mounting the file system?
--ricardo
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the bo
Ricardo Galli wrote:
> I was equally suprised, not only due to the wall-clock time but also to the
> CPU. So, I think the cache is the major player when compiling a kernel that
> was _just_ copied from another file system (still in buffer/cache).
You might consider rebooting to flush the cache.
On Tue, 22 May 2001, Daniel Phillips wrote:
> On Tuesday 22 May 2001 12:29, Daniel Phillips wrote:
> > http://nl.linux.org/~phillips/htree
>
> Oops, nl.linux.org was down for 'unscheduled maintainance' and seems
> to have come back up with some some http issues.
>
> Rik?
[/home]# chmod a+x *
On Tuesday 22 May 2001 12:29, Daniel Phillips wrote:
> The measured create and rename times for Ext2 look pretty silly,
> don't they? OK, I know that my htree directory index patch isn't part
> of Ext2 yet, but at least lets mention that this is a solved problem.
>
> http://nl.linux.org/~phillip
Forbidden
You don't have permission to access /~phillips/htree on this server.
Apache/1.3.14 Server at nl.linux.org Port 80
On 05/22, Daniel Phillips rearranged the electrons to read:
> On Tuesday 22 May 2001 04:4
On Tuesday 22 May 2001 04:41, Ricardo Galli wrote:
> Hi,
> you can find at http://bulma.lug.net/static/ a few new benchmarks
> among Reiser, XFS and Ext2 (also one with JFS).
>
> This time there is a comprehensive Hans' Mongo benchmarks
> (http://bulma.lug.net/static/mongo/ )and a couple of
> My apologies, I meant that the make is probably compiler bound (I said CPU
> bound) not FS bound.
We undertood ;-)
> > cp -ar, and I would like Yura to try to reproduce the cp -ar as
> > it seems too
> > good to be true.
> We find that one must use cp and similar utilities (not
The cp -a fig
My apologies, I meant that the make is probably compiler bound (I said CPU
bound) not FS bound.
We find that one must use cp and similar utilities (not compilers) to become FS
bound when using a Linux FS (unlike the older Unixes for which compiles were
considered excellent benchmarks).
Hans Reis
Ricardo Galli wrote:
>
> Hi,
> you can find at http://bulma.lug.net/static/ a few new benchmarks among
> Reiser, XFS and Ext2 (also one with JFS).
>
> This time there is a comprehensive Hans' Mongo benchmarks
> (http://bulma.lug.net/static/mongo/ )and a couple of kernel compilations and
Hi,
you can find at http://bulma.lug.net/static/ a few new benchmarks among
Reiser, XFS and Ext2 (also one with JFS).
This time there is a comprehensive Hans' Mongo benchmarks
(http://bulma.lug.net/static/mongo/ )and a couple of kernel compilations and
read/write/fsync operations tests (I
12 matches
Mail list logo
