#go-nuts

/

      • spikebike
        Tv`: some distributed filesystem?
      • Tv`
        which means inode allocated depends on accessing order; where as with the go fuse lib it depends on the path name (but is not guaranteed unique)
      • spikebike: FUSE.. maybe this'll clarify: http://bazil.org/talks/2013-06-10-la-gophers/#1
      • ashemedai joined the channel
      • mannyt has quit
      • burlyscudd has quit
      • spikebike
        Tv`: ah, cool link, thanks.
      • Altonymous joined the channel
      • Tv`
        so the Go lib makes inode be hash-based, but chooses NodeID to be just "next available number"
      • sonofdirt has quit
      • but there's cases where e.g. Node.Lookup(), which looks up the named child of that dir, wants to say "yeah you already have it open, it's this Handle"
      • and the current go fuse lib api doesn't expose that power to the fs implementation
      • and gaah
      • yawniek has quit
      • yawniek joined the channel
      • cosql has quit
      • josh-k has quit
      • kwvarga has quit
      • demiurgo has quit
      • carif joined the channel
      • so I want to see that when Node.Lookup returns a Node, if that Node is already known to kernel, use the same NodeID
      • easiest way there would be to use inode as NodeID (just like the C library)
      • but that means current hash-based inode auto-numbering is not good enough (because it's not guaranteed unique)
      • and the problem with that is -- for a lazy fs that doesn't choose inodes itself, lookup()->A, lookup()->B, flush cache, lookup()->B -- now B's inode may have changed
      • SteveMcQwark has quit
      • PeterO joined the channel
      • so maybe i need to preserve the hashing, but add extra protection against collisions
      • SteveMcQ1ark joined the channel
      • keep hashing until i find a free inode number, or something
      • burlyscudd joined the channel
      • but now if the above A and B would collide, same happens again
      • (then again, with current implementation, they'll have the same inode)
      • PeterO has quit
      • cosql joined the channel
      • and a part of me wants to rip out the automatic inode numbering, because i'm not using it myself :(
      • mwhooker has quit
      • soylentbomb has quit
      • Vasari joined the channel
      • SteveMcQ1ark has quit
      • SteveMcQwark joined the channel
      • and that still doesn't help the actual fs figure out that the Lookup refers to a pre-existing Node, and it shouldn't instantiate a new one...
      • kickingvegas has quit
      • JodaZ
        Tv`, just do the same thing as the c lib ?
      • Tv`
        JodaZ: that'd be nice if the C lib was actually good; but it's hideous
      • every single design decision in it needs to be questioned
      • JodaZ
        works fine, i am actually using it (with its auto inodes)
      • SteveMcQwark has quit
      • kr joined the channel
      • hashing in such a case smells like a hack
      • Tv`
        i think it's originally intended for read-only filesystems
      • the lookup and caching thing is a really miserable problem
      • toshipon joined the channel
      • the C lib kludges that by having a flag that makes it never flush the cache
      • xilo joined the channel
      • that's not nice either
      • the design space has horrible things, and things that manage their own inodes; nothing else has yet shown up
      • el-chavo has quit
      • rafaelhbarros has quit
      • davecheney joined the channel
      • aviraldg joined the channel
      • SteveMcQ1ark joined the channel
      • burlyscudd has quit
      • jordanorelli has quit
      • {aviraldg} has quit
      • dsal
        I feel like someone asked this question before and I heckled, but is there a way to know when an http chunk has completed?
      • kr has quit
      • Because I wrote a proxy that works pretty well except when the response is streamed and the client times out waiting for data that the server has flushed, but the proxy hasn't.
      • JodaZ
        Tv`, the problem with caching is a real one tho, with fuse you can expose things that are not under full control of the kernel, so nothing can really be cached there as the underlying data might change at any time
      • xcbt has quit
      • davidboy has quit
      • luksow has quit
      • proppy has quit
      • tfm_
        doesn't fuse have a way to invalidate cached inodes?
      • supermike has quit
      • Tv`
        tfm_: yes
      • ultramur_ has quit
      • tfm_
        i seem to remember support for that being the reason i chose go-fuse over bazil/rsc's
      • Tv`
        yeah bazil.org/fuse doesn't have that yet
      • rest assured i need that myself ;)
      • ultramurph joined the channel
      • tfm_
        i'm a bit time crunched atm but i was planning to come back to implement that
      • feel free to beat me to it, though :)
      • metasansana joined the channel
      • rsc's api seemed nicer to me at first glance
      • acrocity joined the channel
      • ultramurph has quit
      • synacktic joined the channel
      • jerius joined the channel
      • paulsmith joined the channel
      • Spami has quit
      • jcoene joined the channel
      • daaku has quit
      • Tv`
        much much nicer
      • rafaelhbarros joined the channel
      • fallsemo joined the channel
      • EhevuTov has quit
      • quoin joined the channel
      • nu7hatch has quit
      • nu7hatch joined the channel
      • {aviraldg} joined the channel
      • codygman has quit
      • aviraldg has quit
      • quoin has quit
      • zombor has quit
      • nu7hatch has quit
      • astropirate_ joined the channel
      • appendonly joined the channel
      • nphase joined the channel
      • nphase has quit
      • nphase joined the channel
      • runningskull is now known as zz_runningskull
      • zz_runningskull is now known as runningskull
      • jcoene has quit
      • Cubixmeister has left the channel
      • aviraldg joined the channel
      • burlyscudd joined the channel
      • astropirate has quit
      • fallsemo has quit
      • {aviraldg} has quit
      • petejkim has quit
      • polyfractal joined the channel
      • paulsmith has quit
      • oweidner_ joined the channel
      • Cafe01 has quit
      • oweidner has quit
      • burlyscudd has quit
      • gmcquillan has quit
      • csakatoku joined the channel
      • smw_ joined the channel
      • iampims has quit
      • josephho_ joined the channel
      • josephholsten has quit
      • cosql has quit
      • axw joined the channel
      • toshipon has quit
      • synacktic has quit
      • DallaRosa joined the channel
      • crosbymichael is now known as zz_crosbymichael
      • toshipon joined the channel
      • rafaelhbarros has quit
      • mortdeus joined the channel
      • mortdeus_ joined the channel
      • csakatoku has quit
      • mortdeus_ has quit
      • jerius has quit
      • kellabyte
        what does this mean? "invalid operation: command <- c (send to non-chan type raft.Command)"
      • tvw has quit
      • dominikh
        that command isn't a channel and you're trying to send to it as if it were
      • twmb
        you're sending to a non-chan type raft.Command
      • csakatoku joined the channel