And fcp?
On 6/1/22, Bakul Shah wrote:
> On May 31, 2022, at 9:14 AM, ron minnich wrote:
>>
>> On Mon, May 30, 2022 at 12:21 AM Bakul Shah wrote:
>>> 9p itself is low performance but that is a separate issue.
>>
>> Bakul, what are the units? It might be helpful to quantify this
>> statement. Are
On Tue, May 31, 2022 at 11:29 AM hiro <23h...@gmail.com> wrote:
>
> so virtiofs is not using 9p any more?
>
> and with 10 million parallel requests, why shouldn't 9p be able to
> deliver 10GB/s ?!
Everyone always says this. I used to say it too.
9p requires a certain degree of ordering -- as Andr
I don't think the reason nobody is doing this is that it's difficult per se.
Fcp also achieves parallelism without any changes to 9p.
And posix fs also share some of our statefulness.
A file system can have offsets, readahead can help.
Other synthetic FS need different tricks, but we can exchan
In case this is not immediately clear: theoretically preventable 1rtt
minimum delays are much less bad than the practically unbounded
maximum delays in congested networks.
Put in another way: making some few things fast is much more easy than
making sure that everything else doesn't get infinitely
hjfs is not exactly known for it's speed[0]. Running a cwfs
without a worm[1] is likely a more interesting comparison.
I also would recommend using kvik's clone[2] for copying
in parallel.
Would be curious how that stacks up.
Thanks,
moody
[0] http://fqa.9front.org/fqa4.html#4.3.6
[1] http://f
for performance testing why not copy from ramfs on one machine to ramfs on
another?
the suggestion from a 9con passim was to have fossil/cwfs/hjfs etc add a Qid
type flag to files indicating they are from backing store (QTSTABLE ?)and thus
may be copied in parallel. devices and synthetic would
On 6/1/22, Steve Simon wrote:
> for performance testing why not copy from ramfs on one machine to ramfs on
> another?
ramfs is single-process and thus quite slow.
> the suggestion from a 9con passim was to have fossil/cwfs/hjfs etc add a Qid
> type flag to files indicating they are from backing
Quoth ron minnich :
> This is why 9p starts to perform poorly in networks with high
> bandwidth*delay products -- if you watch the net traffic, you see each
> T op on fid blocked by the previous Reply (by devmnt).
>
> I never figured out a way to fix this without fixing devmnt -- by
> removing it
Quoth ron minnich :
> This is why 9p starts to perform poorly in networks with high
> bandwidth*delay products -- if you watch the net traffic, you see each
> T op on fid blocked by the previous Reply (by devmnt).
>
> I never figured out a way to fix this without fixing devmnt -- by
> removing it
