killer application

[Francisco J Ballesteros]

I have a benchmark designed for our file server
application.

Make sure hg sync runs a lot faster than it does
in macos.

Right now it's a shame how that runs in Plan 9.

[ron minnich]

I think if I don't screw it up that the mmventi with embedded 9p
server should make things much better. We know that it gives a 10x
improvement on writes even without the integrated 9p server. The
mmventi is done, I'm just trying to figure out how to integrate the
moral equivalent of vacfs into it. This requires a bit of thinking
about how to redo the VtCache stuff. I'm not sure, most of the time,
that I'm smart enough for this kind of work, but we'll see where it
goes :-)

Plan 9 file systems have been far too slow for at least 10 years, and
with each passing year have gotten relatively slower as compared to
competitors. It's sad because in the 1990 timeframe they were way
faster. We at Sandia no longer see kenfs as the answer for a long list
of reasons (and I don't intend to revisit that discussion, only to
present a conclusion we reached after a lot of work, so let's,
*please!*, not start that up again. That's not what this list is for).

I also think it would make sense to reconsider the "file system" as
stored in the venti -- is there a layout that makes more sense for
performance? I'm not sure, yet, but it's worth thinking about.

ron

[erik quanstrom]

> Plan 9 file systems have been far too slow for at least 10 years, and
> with each passing year have gotten relatively slower as compared to
> competitors. It's sad because in the 1990 timeframe they were way
> faster. We at Sandia no longer see kenfs as the answer for a long list
> of reasons (and I don't intend to revisit that discussion, only to
> present a conclusion we reached after a lot of work, so let's,
> *please!*, not start that up again. That's not what this list is for).

geesh. relax. i promise not to suggest anything.

- erik

[Christian Neukirchen]

ron minnich <rmin...@gmail.com> writes:

> Plan 9 file systems have been far too slow for at least 10 years,

HFS has been too. :)

--
Christian Neukirchen <chneuk...@gmail.com> http://chneukirchen.org

[Francisco J Ballesteros]

Sorry :-D
still laughing.

But yes, I agree (with both of you) that it would be good to rethink
how the thing works. But let get everything still ongoing fixed first :)

[Bakul Shah]

On Tue, 27 Sep 2011 10:26:32 PDT ron minnich <rmin...@gmail.com> wrote:
>
> (and I don't intend to revisit that discussion, only to
> present a conclusion we reached after a lot of work, so let's,
> *please!*, not start that up again. That's not what this list is for).

:-)

> I also think it would make sense to reconsider the "file system" as
> stored in the venti -- is there a layout that makes more sense for
> performance? I'm not sure, yet, but it's worth thinking about.

Are you suggesting venti as a (flash) filesystem? Don't think
venti is right as a filesystem -- an ability to forget is
important in a filesystem (as opposed to an archival system).
Why not just reuse an existing storage layout/clustering
solution (ignoring a small matter of programming for the
moment).

From the subject line I thought you guys had found a killer
app for nix to takeover from lunix :-)

[Francisco J Ballesteros]

Yes, a damn fast file server running in a nix box.
Or that´s the idea. We´d like to exploit what we can do
with cores and numa information to make it faster.

[erik quanstrom]

>
> But yes, I agree (with both of you) that it would be good to rethink
> how the thing works. But let get everything still ongoing fixed first :)

the only real comment i have on file servers, is that you're going to have
a hard time competing on raw speed. especially if you wish to also be
robust in the face of outages. it's just a hard problem even to be correct.

- erik

[Francisco J Ballesteros]

Sure. But that´s the game.
Of course I´d only compete with those file servers that are correct
(or at least are close to that).

[ron minnich]

I like venti due to its inherent non-duplicate-writing nature. That in
turn means a memory-based venti can work pretty well. I've had
discussions with sites about the size of their venti and in almost
every case they have tiny ventis. That's my interest.

ron

[Steve Simon]

Ok,

I would like to contribute to nix but I am stumped at the first hurdle.

how do I bootstrap myself into the mercurical world, I have installed
the puthon and mercurical contrib packages fron the labs server but they
are not functional.

is there a nix server running 9p that I could pull the mercurical pkg from?

-Steve

[Francisco J Ballesteros]

If you download nix using unix then you can use pm/install, say, using
9vx, and go from there.

We should perhaps build an iso daily and put it on the web. But didn´t
have time yet
to do so.

[Francisco J Ballesteros]

sorry. pm/install is a command in nix.

[John Floren]

How are they not functional? Note that you'll need stallion/mercurial,
not the other one. Those work for me. You should be able to clone once
you have those.

John

[Steve Simon]

> How are they not functional? Note that you'll need stallion/mercurial,
> not the other one. Those work for me. You should be able to clone once
> you have those.

I tried an old package, I will try stallion tomorrow.

-Steve

[erik quanstrom]

here's an extension for playing nice with factotum:

/n/sources/contrib/stallion/src/mercurial/factotum.py

- erik

[Francisco J Ballesteros]

you could send it through code review.

I wouldn´t like many different bits and pieces to be found here and there,
just to find some of them are not compatible with some others.
That´s why we are taking the burden of using codereview in the first place.

[John Floren]

Stuff like this can go into the packages too.

John

[Francisco J Ballesteros]

But I think that, given that code review can be teached to use factotum,
it would be better to change it so it does it that way. It might require
a change to std. packages so that we try to load the factotum module
and fall back to passwd asking otherwise.

[erik quanstrom]

On Tue Sep 27 18:20:36 EDT 2011, ne...@lsub.org wrote:
> But I think that, given that code review can be teached to use factotum,
> it would be better to change it so it does it that way. It might require
> a change to std. packages so that we try to load the factotum module
> and fall back to passwd asking otherwise.

i use this thing. it's seamless.

- erik

[erik quanstrom]

On Tue Sep 27 17:40:03 EDT 2011, ne...@lsub.org wrote:
> you could send it through code review.
>
> I wouldn´t like many different bits and pieces to be found here and there,
> just to find some of them are not compatible with some others.
> That´s why we are taking the burden of using codereview in the first place.
>
> On Tue, Sep 27, 2011 at 11:16 PM, erik quanstrom <quan...@quanstro.net> wrote:

it's not my code, so i would feel odd submitting it.

- erik

[erik quanstrom]

i don't know about anybody else, but i just can't use enough disk
space for this to matter. is dedup really a killer app if you're not
doing vdi? (vdi, aka 3270 terminals learn to do real graphics, or
x terminals on the opposite of steroids.)

- erik

[Noah Evans]

It's perfectly fine to submit open source code on codereview, although
it's good manners to acknowledge who wrote it if you know who did.

Noah

[Charles Forsyth]

"so let's,
*please!*, not start that up again. That's not what this list is for"

preceded by a long post that starts it up again!