Re: [9fans] 9p over high-latency - Plan9

This is a discussion on Re: [9fans] 9p over high-latency - Plan9 ; On Fri, Sep 12, 2008 at 7:47 PM, erik quanstrom wrote: > as an aside: i don't think 9p itself limits plan 9 performance > over high-latency links. the limitations have more to do with > the number of outstanding ...

+ Reply to Thread
Results 1 to 4 of 4

Thread: Re: [9fans] 9p over high-latency

  1. Re: [9fans] 9p over high-latency

    On Fri, Sep 12, 2008 at 7:47 PM, erik quanstrom wrote:
    > as an aside: i don't think 9p itself limits plan 9 performance
    > over high-latency links. the limitations have more to do with
    > the number of outstanding messages, which is 1 in the mnt
    > driver.


    Hm, but what's the alternative here? Readahead seems somewhat
    attractive, if difficult (I worry about blocking reads and timing
    sensitive file systems). But there's one problem I can't resolve - how
    do you know what offset to Tread without consulting the previous
    Rread's count?
    Actually, I understand there has been discussion about grouping tags
    to allow for things like Twalk/Topen batching without waiting for
    Rwalk (which sounds like a great idea), maybe that would work here
    also...
    -sqweek


  2. Re: [9fans] 9p over high-latency

    * sqweek [080918 12:02]:
    > On Fri, Sep 12, 2008 at 7:47 PM, erik quanstrom wrote:
    > > as an aside: i don't think 9p itself limits plan 9 performance
    > > over high-latency links. the limitations have more to do with
    > > the number of outstanding messages, which is 1 in the mnt
    > > driver.

    >
    > Hm, but what's the alternative here? Readahead seems somewhat
    > attractive, if difficult (I worry about blocking reads and timing
    > sensitive file systems). But there's one problem I can't resolve - how
    > do you know what offset to Tread without consulting the previous
    > Rread's count?
    > Actually, I understand there has been discussion about grouping tags
    > to allow for things like Twalk/Topen batching without waiting for
    > Rwalk (which sounds like a great idea), maybe that would work here
    > also...


    There are some interesting approaches which have been discussed at the lastiwp9, including op from nemo's team.
    http://plan9.bell-labs.com/iwp9/pape...p.esoriano.pdf

    Maybe that is worth looking at for your issue?

    Kind regards,

    Christian

    --
    You may use my gpg key for replies:
    pub 1024D/47F79788 2005/02/02 Christian Kellermann (C-Keen)

    -----BEGIN PGP SIGNATURE-----
    Version: GnuPG v1.4.8 (OpenBSD)

    iEYEARECAAYFAkjSLy8ACgkQXYob3Uf3l4gwhACeNRHc0kIrXU xHL2cGGF9+BpDJ
    7XUAnjqphWj6QpGKd8sJ3Qm15i8uFJiP
    =S6aT
    -----END PGP SIGNATURE-----


  3. Re: [9fans] 9p over high-latency

    Actually, this whole subject was thoroughly discussed at the *first*
    iwp9; but apparently nobody is bothered by this enough to implement
    any of the then suggested solutions.

    Op is not one the solutions discussed at the time, and saying 'just
    use another protocol' is not a way to resolve the shortcomings 9P
    clearly has.

    Moreover most of the solutions discussed back then seemed quite clear
    and would be (mostly) backwards compatible, so I still don't
    understand why Op was created rather than implement one of those
    solutions, although my understanding is that nemo and co. considered
    it easier (ie., didn't involve changing other people's code?).

    Also worth noting is that Op has some serious shortcomings, if I
    recall correctly it fails to translate some important 9P semantics
    like walks, which means that while Op can transparently proxy 9P
    connections, certain file servers wont work properly (I might be
    mistaken, and certainly don't remember the details).

    This is not to say that there is no use for a protocol like Op (it
    shares much in common with http, which clearly has found lots of use
    in the 'real world').

    Peace

    uriel

    On Thu, Sep 18, 2008 at 12:36 PM, Christian Kellermann
    wrote:
    > * sqweek [080918 12:02]:
    >> On Fri, Sep 12, 2008 at 7:47 PM, erik quanstrom wrote:
    >> > as an aside: i don't think 9p itself limits plan 9 performance
    >> > over high-latency links. the limitations have more to do with
    >> > the number of outstanding messages, which is 1 in the mnt
    >> > driver.

    >>
    >> Hm, but what's the alternative here? Readahead seems somewhat
    >> attractive, if difficult (I worry about blocking reads and timing
    >> sensitive file systems). But there's one problem I can't resolve - how
    >> do you know what offset to Tread without consulting the previous
    >> Rread's count?
    >> Actually, I understand there has been discussion about grouping tags
    >> to allow for things like Twalk/Topen batching without waiting for
    >> Rwalk (which sounds like a great idea), maybe that would work here
    >> also...

    >
    > There are some interesting approaches which have been discussed at the last iwp9, including op from nemo's team.
    > http://plan9.bell-labs.com/iwp9/pape...p.esoriano.pdf
    >
    > Maybe that is worth looking at for your issue?
    >
    > Kind regards,
    >
    > Christian
    >
    > --
    > You may use my gpg key for replies:
    > pub 1024D/47F79788 2005/02/02 Christian Kellermann (C-Keen)
    >



  4. Re: [9fans] 9p over high-latency

    On Thu, Sep 18, 2008 at 05:57:21PM +0800, sqweek wrote:
    > On Fri, Sep 12, 2008 at 7:47 PM, erik quanstrom wrote:
    > > as an aside: i don't think 9p itself limits plan 9 performance
    > > over high-latency links. the limitations have more to do with
    > > the number of outstanding messages, which is 1 in the mnt
    > > driver.

    >
    > Hm, but what's the alternative here? Readahead seems somewhat
    > attractive, if difficult (I worry about blocking reads and timing
    > sensitive file systems). But there's one problem I can't resolve - how
    > do you know what offset to Tread without consulting the previous
    > Rread's count?
    > Actually, I understand there has been discussion about grouping tags
    > to allow for things like Twalk/Topen batching without waiting for
    > Rwalk (which sounds like a great idea), maybe that would work here
    > also...
    > -sqweek
    >


    This seems an appropriate time -- well, appropriate thread, if a few days
    lagged -- to bring up Dave's/my cache journaling scheme for review... I
    presented this at IWP9 last year and recieved mostly positive feedback, as I
    remember, but sadly have not had a chance to work on it since. (That said,
    it remains on my todo list should nobody beat me to it.)

    The protocol design is documented on my server at
    https://wiki.ietfng.org/pub/Plan9/JournalCallbacks. Sadly, it remains the
    case that I don't have an implementation to offer.

    The basic idea is to shim a client-side cache and a server-side cache
    controller in front of a filesystem, like fossil or exportfs, and have the
    cache controller snoop on all connections to the server, informing caches
    when the contents of their caches have become invalid. There are a few
    known deficiencies ([in]coherency and authentication being the two big
    ones), but I hope the idea remains sound.

    Thoughts and criticisms welcome.
    --nwf;

    -----BEGIN PGP SIGNATURE-----
    Version: GnuPG v1.4.9 (GNU/Linux)

    iEYEARECAAYFAkjdiZ4ACgkQTeQabvr9Tc83GQCdFM1P2SdcKw 6Gy5qUCkAd6CX3
    3FgAn1dCOCYi/gn5Pk2A2LBU1BQdHFhk
    =YaEf
    -----END PGP SIGNATURE-----


+ Reply to Thread