ok, let's say that i want to read a 2 gb file :)
2010/10/16 :
> when you are in kiev, video streams YOU!
>
> --
> cinap
>
>
> -- Forwarded message --
> From: dorin bumbu
> To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net>
> Date: Sat, 16 Oct 2010 02:30:42 +0300
> Subject
when you are in kiev, video streams YOU!
--
cinap
--- Begin Message ---
2010/10/16 erik quanstrom :
> On Fri Oct 15 17:14:18 EDT 2010, bumbudo...@gmail.com wrote:
>> 2010/10/15 erik quanstrom :
>> >> isn't tag field for this intended?
>> >
>> > [...]
>> >
>> >> so this means to me that a client ca
2010/10/16 erik quanstrom :
> On Fri Oct 15 17:14:18 EDT 2010, bumbudo...@gmail.com wrote:
>> 2010/10/15 erik quanstrom :
>> >> isn't tag field for this intended?
>> >
>> > [...]
>> >
>> >> so this means to me that a client can send some T-messages and then
>> >> (or concurrently) wait the R-messag
On Fri Oct 15 17:14:18 EDT 2010, bumbudo...@gmail.com wrote:
> 2010/10/15 erik quanstrom :
> >> isn't tag field for this intended?
> >
> > [...]
> >
> >> so this means to me that a client can send some T-messages and then
> >> (or concurrently) wait the R-messages.
> >> in inferno from mount(1) and
It is probably worth trying. However, it wouldn't make copying a file
from sources any faster, or help a Blue Gene node do a snapshot any
quicker.
John
2010/10/15 Julius Schmidt :
> Perhaps I'm getting this all wrong, but to me this seems like an
> interesting idea, especially if you consider th
CPUs have big caches to move the code closer to the data (well a copy of the
data anyway).
Closeness in general is good, the question is what to move and how :-)
Dave
2010/10/15 Julius Schmidt
> Perhaps I'm getting this all wrong, but to me this seems like an
> interesting idea, especially if
Perhaps I'm getting this all wrong, but to me this seems like an
interesting idea, especially if you consider the impact of being "near
the files" on some classically considered computationally stressy tasks
like compiling (esp. with kencc). So moving the code near the data
definitely seems worth
2010/10/15 erik quanstrom :
>> isn't tag field for this intended?
>
> [...]
>
>> so this means to me that a client can send some T-messages and then
>> (or concurrently) wait the R-messages.
>> in inferno from mount(1) and styxmon(8) i deduced that this case is
>> also considered.
>> it's true that
9fans,
I am making the IWP9 attendees list and am missing one name; it is the
9fan who recorded the audio of all the sessions. Could you send me
email with your name?
Thanks,
-Skip
if anyone is still in seattle my google redirect is 513-3BRUCEE
There are definitely cases when moving the code instead of the data
makes sense. But that discussion is mostly unrelated to the one on how
to make the file I/O work better over high-latency links.
2010/10/15 erik quanstrom :
> On Fri Oct 15 12:33:19 EDT 2010, lu...@ionkov.net wrote:
>> What if the
On Fri Oct 15 12:33:19 EDT 2010, lu...@ionkov.net wrote:
> What if the data your process needs is located on more than one
> server? Play ping-pong?
one either plays ping pong with the process or data. one
could imagine cases where the former case makes sense.
- erik
On Fri, Oct 15, 2010 at 01:49:58PM +0200, Enrico Weigelt wrote:
> * Tharaneedharan Vilwanathan wrote:
> > hi,
> >
> > about a year back, someone mentioned about a tool or utility for
> > archiving/storage like venti. it has de-duplication and uses hashing
> > mechanism. i think it runs on linux m
> And even if you get that right, it may not work well on hardware. We
> saw cases with linux migration, while migrating from one x86 to
> another, where valid FP values would cause the target to get an FP
> trap. Made no sense, but it's what happened, because the two x86's
> were different *implem
2010/10/15
> i wonder if making 9p work better over high latency connections is
> even the right answer to the problem. the real problem is that the
> data your program wants to work on in miles away from you and
> transfering it all will suck. would it not be cool to have a way to
> teleport/m
hi thomas,
yes, this is the one. thanks a lot! i couldnt find it because my
search keywords didnt match.
regards
dharani
On Fri, Oct 15, 2010 at 3:20 AM, Thomas Östreicher
wrote:
> On Fri, Oct 15, 2010 at 7:35 AM, Tharaneedharan Vilwanathan
> wrote:
>> hi,
>>
>> about a year back, someone ment
On Fri, 15 Oct 2010 18:19:50 +0200 cinap_len...@gmx.de wrote:
>
> i wonder if making 9p work better over high latency connections is
> even the right answer to the problem. the real problem is that the
> data your program wants to work on in miles away from you and
> transfering it all will suck
2010/10/15 Nemo :
> So, when I hear migration, I just tend to see what happens after it has
> been implemented and faces the spaghethy phase.
And even if you get that right, it may not work well on hardware. We
saw cases with linux migration, while migrating from one x86 to
another, where valid F
2010/10/15 Charles Forsyth :
>>The transition from a stream to the packet-oriented file IO protocol has
>>never been comfortable.
>
> `RPC-oriented' might be more accurate than `packet-oriented', given the
> way that streams are implemented.
Correct.
ron
back to the 80s, or was it 70s?
many people have implemented migration.
the first i remember is swaping (yes, not paging) out a process, then swapping
it back into a different machine. iirc, it might be the sprite unix, not quite
sure.
the point is, the migrated process still needs all the conne
>The transition from a stream to the packet-oriented file IO protocol has never
>been comfortable.
`RPC-oriented' might be more accurate than `packet-oriented', given the
way that streams are implemented.
If the mechanism cannot be applied to every (even wrong) problem, then
it still doesn't solve the file I/O over high-latency links issue that
we started with first.
2010/10/15 :
> if it doesnt help, you apply the mechanism to the wrong problem :) or
> the mechanism is not that usefull as i though
if it doesnt help, you apply the mechanism to the wrong problem :) or
the mechanism is not that usefull as i thought... thanks ron for your
comment! i was just hoping to get some responses from the osprey
dudes as they had it on ther slides :)
--
cinap
--- Begin Message ---
And how is fork going
On Fri, Oct 15, 2010 at 12:29 AM, Tharaneedharan Vilwanathan
wrote:
> hi,
>
> i think we could stress on a specific architecture (and aim to provide
> basic and improved support) based on these criteria:
>
> - mainline architecture
> - cheap and affordable both for companies and individuals (also,
2010/10/15 :
> i wonder if making 9p work better over high latency connections is
> even the right answer to the problem.
The reason I care is that the link from a CPU node to a file server on
blue gene is high latency. It might as well be cross-country, it's so
bad.
> would it not be cool to h
And how is fork going to help when the forked processes need to
exchange the data over the same high-latency link?
2010/10/15 :
> fork!
>
> --
> cinap
>
>
> -- Forwarded message --
> From: Latchesar Ionkov
> To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net>
> Date: Fri,
fork!
--
cinap
--- Begin Message ---
What if the data your process needs is located on more than one
server? Play ping-pong?
Thanks,
Lucho
2010/10/15 :
> i wonder if making 9p work better over high latency connections is
> even the right answer to the problem. the real problem is that the
What if the data your process needs is located on more than one
server? Play ping-pong?
Thanks,
Lucho
2010/10/15 :
> i wonder if making 9p work better over high latency connections is
> even the right answer to the problem. the real problem is that the
> data your program wants to work on i
i wonder if making 9p work better over high latency connections is
even the right answer to the problem. the real problem is that the
data your program wants to work on in miles away from you and
transfering it all will suck. would it not be cool to have a way to
teleport/migrate your process to
i wonder if making 9p work better over high latency connections is
even the right answer to the problem. the real problem is that the
data your program wants to work on in miles away from you and
transfering it all will suck. would it not be cool to have a way to
teleport/migrate your process to
I already implemented that behavior in go9p on the plane back from
Seattle. I need to test it a bit before I check it in the repository.
The good thing about it is that it doesn't break any existing clients
or servers.
How is it going to be exposed to the clients is another issue. I am
still not s
It's not just that you can stream requests or not.
If you have caches in the path to the server, you'd like to batch together (or
stream or whatever you'd like to call that) requests so that if a client is
reading a file and a single rpc suffices, the cache, in the worst case, knows
that it has to
2010/10/15 Sape Mullender
> Are we talking about πP or 9P?
>
It's about both. I was just curious about how 9P was deficient in terms of
pipelining. It might not be optimal for all cases of pipelining, but the
protocol seems to support it in certain cases just fine.
ΠP deals with it in a super
2010/10/14 Latchesar Ionkov
> It can't be dealt with the current protocol. It doesn't guarantee that
> Topen will be executed once Twalk is done. So can get Rerrors even if
> Twalk succeeds.
>
>
It can be dealt with if the scheduling of the pipeline is done properly.
You just have to eliminate t
* Tharaneedharan Vilwanathan wrote:
> hi,
>
> about a year back, someone mentioned about a tool or utility for
> archiving/storage like venti. it has de-duplication and uses hashing
> mechanism. i think it runs on linux mainly. can someone give me some
> details on this if you remember?
I'm curr
On Thu, Oct 14, 2010 at 3:16 PM, Skip Tavakkolian
wrote:
> Has anyone attempted to get it running on Windows?
Andre Gunther had a look during GSoC a few years back.
It is a pain. Windows does not trigger the exception handler
if it thinks the segment registers are wrong, so 9vx cannot
handle its
A simpler way to add pipelining to 9P is to
define that multiple outstanding messages
with the same tag are allowed and that the
server must process and respond to messages
with a given tag in the order it receives them.
This only requires changes to servers that
are actually multithreaded. All th
> isn't tag field for this intended?
[...]
> so this means to me that a client can send some T-messages and then
> (or concurrently) wait the R-messages.
> in inferno from mount(1) and styxmon(8) i deduced that this case is
> also considered.
> it's true that most of the servers i seen until now
We pronouce it pie pee
> Is it Pi-Ro, or do you actually call it Pipi?
2010/10/15 Jacob Todd :
> Eh, what's Πp?
check http://iwp9.org/slides/osprey.pdf
Eh, what's Πp?
Is it Pi-Ro, or do you actually call it Pipi?
On Fri, Oct 15, 2010 at 7:35 AM, Tharaneedharan Vilwanathan
wrote:
> hi,
>
> about a year back, someone mentioned about a tool or utility for
> archiving/storage like venti. it has de-duplication and uses hashing
> mechanism. i think it runs on linux mainly. can someone give me some
> details on t
Are we talking about πP or 9P?
ΠP doesn't have Twalk. It has open, which combines clone, walk, and open from
9P. Before you start jumping up and down and telling me that you can't open
without revieing the qids from the walk (to check them for mount points), let
me tell you that we are also tack
44 matches
Mail list logo
