On 16 November 2010 16:32, Charles Forsyth wrote:
>>unfortunately, there's just not enough bits to easily export
>>(an export)+.
>
> i think that works: it checks for clashes.
only when a file is actually walked to.
of course, that's fine in practise - the only thing
that actually cares about qi
>unfortunately, there's just not enough bits to easily export
>(an export)+.
i think that works: it checks for clashes.
> i'm sure that somewhere it was suggested that high order bits of Qid.path
> should be avoided by file servers to allow for their use to make qids unique
> but i haven't been able to find that.
unfortunately, there's just not enough bits to easily export
(an export)+.
i wonder if there's some wa
>i'd say it's a bug. fossil could easily reserve some number of bits
>of the qid (say 20 bits) to make the files in the dump unique
>while still allowing space for a sufficient number of live files.
that's possibly closest to the intent of the qid discussion in intro(5),
although
it's not clear t
On Mon, Nov 15, 2010 at 2:00 PM, Dan Adkins wrote:
> That brings up a question of interest to me. How do you effectively
> read ahead with the 9p protocol? Even if you issued many read
> requests in parallel, the server is allowed to return less data than
> was asked for. You'll end up with hol
On 16 November 2010 01:18, erik quanstrom wrote:
>> > i claim that a fs with this behavior would be broken. intro(5)
>> > seems to agree with this claim, unless i'm misreading.
>>
>> you're right - fossil is broken in this respect, as is exportfs
>> {cd /mnt/term/dev; ls -lq | sort} for a quick d
> > i claim that a fs with this behavior would be broken. intro(5)
> > seems to agree with this claim, unless i'm misreading.
>
> you're right - fossil is broken in this respect, as is exportfs
> {cd /mnt/term/dev; ls -lq | sort} for a quick demo.
so what's fossil's excuse?
- erik
> The option is to make servers obey R order for Ts with same tag - just
> as Russ (right?) proposed elsewhere on the list.
no. tags have no order and clients are specificly disallowed
from having multiple messages with the same tag outstanding.
again, see intro(5).
the option is to issue many T
> That brings up a question of interest to me. How do you effectively
> read ahead with the 9p protocol? Even if you issued many read
> requests in parallel, the server is allowed to return less data than
> was asked for. You'll end up with holes in your buffer that require
> at least another ro
On 15 November 2010 19:29, erik quanstrom wrote:
>> if you mount onto one, you'll see the mounted files
>> on the other.
>>
>> gorka was talking about identifying files from their qid.
>> the version number doesn't help in identifying the file -
>> someone could have modified the file 35 times bet
> if you mount onto one, you'll see the mounted files
> on the other.
>
> gorka was talking about identifying files from their qid.
> the version number doesn't help in identifying the file -
> someone could have modified the file 35 times between
> stats.
what definition of "file" are you using?
That brings up a question of interest to me. How do you effectively
read ahead with the 9p protocol? Even if you issued many read
requests in parallel, the server is allowed to return less data than
was asked for. You'll end up with holes in your buffer that require
at least another roundtrip to
You're way off about the merits of pipelining.
As far as parallel requests are concerned,
the 9P protocol beats HTTP hands down
(as does basically any other request
response protocol), because it has explicit
unique IDs on the requests and responses.
That allows a server to respond to two
requests
On 15 November 2010 16:48, erik quanstrom wrote:
>> > the qid values are actually different
>>
>> true, but qid.version doesn't help much.
>
> what!? i'd hate to see a file server that didn't
> much care which qid.version it had. those directories
> you listed are different.
if you mount onto o
> > the qid values are actually different
>
> true, but qid.version doesn't help much.
what!? i'd hate to see a file server that didn't
much care which qid.version it had. those directories
you listed are different.
- erik
2010/11/15 C H Forsyth :
>>% ls -lqd /n/dump/2006/0707/usr/rog
>>(0003d540 1122 80) d-rwxr-xr-x M 42850 rog rog 0 Jun 7 2005
>>/n/dump/2005/0707/usr/rog
>>% ls -lqd /n/dump/2006/0707/usr/rog
>>(0003d540 1157 80) d-rwxr-xr-x M 42850 rog rog 0 Jun 12 2006
>>/n/dump/2006/0707/usr/ro
>% ls -lqd /n/dump/2006/0707/usr/rog
>(0003d540 1122 80) d-rwxr-xr-x M 42850 rog rog 0 Jun 7 2005
>/n/dump/2005/0707/usr/rog
>% ls -lqd /n/dump/2006/0707/usr/rog
>(0003d540 1157 80) d-rwxr-xr-x M 42850 rog rog 0 Jun 12 2006
>/n/dump/2006/0707/usr/rog
>they have the same qid but t
On Mon, Nov 15, 2010 at 7:55 AM, Venkatesh Srinivas wrote:
> > Under certain situations, 9p can do some forms of pipelining. The tagged
> > requests don't have to be waited on in order, for the next outgoing
> request
> > to be sent, unless there's a dependency of one completing before the
> oth
> Under certain situations, 9p can do some forms of pipelining. The tagged
> requests don't have to be waited on in order, for the next outgoing request
> to be sent, unless there's a dependency of one completing before the other,
> or the evaluation of completion of a previous one on another.
On
On Sun, Nov 14, 2010 at 7:25 PM, Sam Watkins wrote:
> hi,
>
> I am wondering what you think about the capabilities of 9p compared to
> http/1.1. Perhaps this seems like an odd comparison, but I think 9p and
> http
> are broadly similar in purpose and functionality. While writing a simple
> webs
On 15 November 2010 14:15, Gorka Guardiola wrote:
> By namespaces I mean qid's , the notion that a file is the same if the
> name isn't.
mind you, that's problematic in 9p. the qid can be the same even if the
file is different:
% ls -lqd /n/dump/2006/0707/usr/rog
(0003d540 1122 80) d-rwx
On Mon, Nov 15, 2010 at 3:09 PM, Gorka Guardiola wrote:
> On Mon, Nov 15, 2010 at 6:16 AM, Sam Watkins wrote:
>> On Sun, Nov 14, 2010 at 11:20:00PM -0500, John Floren wrote:
>>> Please see lsub's Op and my Streaming talk at the most recent IWP9.
>>
>> Ok, thanks. I did not know that 9p has laten
On Mon, Nov 15, 2010 at 6:16 AM, Sam Watkins wrote:
> On Sun, Nov 14, 2010 at 11:20:00PM -0500, John Floren wrote:
>> Please see lsub's Op and my Streaming talk at the most recent IWP9.
>
> Ok, thanks. I did not know that 9p has latency problems even when reading a
> single file. I was talking a
On Mon, Nov 15, 2010 at 12:16 AM, Sam Watkins wrote:
> On Sun, Nov 14, 2010 at 11:20:00PM -0500, John Floren wrote:
>> Please see lsub's Op and my Streaming talk at the most recent IWP9.
>
> Ok, thanks. I did not know that 9p has latency problems even when reading a
> single file. I was talking
On Sun, Nov 14, 2010 at 11:20:00PM -0500, John Floren wrote:
> Please see lsub's Op and my Streaming talk at the most recent IWP9.
Ok, thanks. I did not know that 9p has latency problems even when reading a
single file. I was talking about pipelining, where you can ask the server to
send a dozen
i'm with john
On Mon, Nov 15, 2010 at 3:20 PM, John Floren wrote:
> Please see lsub's Op and my Streaming talk at the most recent IWP9.
>
> Also, regarding 'cat', the behavior of many basic tools is that,
> barring any file arguments, they take stdin as input and output to
> stdout, so cat's beha
Please see lsub's Op and my Streaming talk at the most recent IWP9.
Also, regarding 'cat', the behavior of many basic tools is that,
barring any file arguments, they take stdin as input and output to
stdout, so cat's behavior makes sense to me.
On Sun, Nov 14, 2010 at 10:25 PM, Sam Watkins wrote
hi,
I am wondering what you think about the capabilities of 9p compared to
http/1.1. Perhaps this seems like an odd comparison, but I think 9p and http
are broadly similar in purpose and functionality. While writing a simple
webserver, I got to thinking that http is really a very capable protoco
28 matches
Mail list logo
