* [9fans] rio snarf @ 2004-10-27 11:16 Fco. J. Ballesteros 2004-10-27 17:10 ` Russ Cox 0 siblings, 1 reply; 5+ messages in thread From: Fco. J. Ballesteros @ 2004-10-27 11:16 UTC (permalink / raw) To: 9fans Any reason why it updates on close rather than truncating on open(OTRUNC)? ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [9fans] rio snarf 2004-10-27 11:16 [9fans] rio snarf Fco. J. Ballesteros @ 2004-10-27 17:10 ` Russ Cox 2004-10-27 17:31 ` Fco. J. Ballesteros 0 siblings, 1 reply; 5+ messages in thread From: Russ Cox @ 2004-10-27 17:10 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs > Any reason why it updates on close rather than truncating on open(OTRUNC)? Surely you have a different question. Russ ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [9fans] rio snarf 2004-10-27 17:10 ` Russ Cox @ 2004-10-27 17:31 ` Fco. J. Ballesteros 2004-10-27 17:51 ` Russ Cox 0 siblings, 1 reply; 5+ messages in thread From: Fco. J. Ballesteros @ 2004-10-27 17:31 UTC (permalink / raw) To: russcox, 9fans [-- Attachment #1: Type: text/plain, Size: 580 bytes --] Well. We just found that removing snarf from rio fsys makes things work great wrt sharing the snarf buffer across machines. At first, we thought that if was enough to call open(OTRUNC) while copying to the snarf buffer, then we noticed the deadlock with the open("/dev/snarf") in rio, then we tried removing snarf from rio, and, voila. Either I'm crazy because of the lots of coffee I have been drinking, or there is something I'm missing regarding why rio has snarf builtin instead of using a regular file for that. Hope my question was more clear now. cheers [-- Attachment #2: Type: message/rfc822, Size: 2984 bytes --] From: Russ Cox <russcox@gmail.com> To: Fans of the OS Plan 9 from Bell Labs <9fans@cse.psu.edu> Subject: Re: [9fans] rio snarf Date: Wed, 27 Oct 2004 13:10:45 -0400 Message-ID: <ee9e417a0410271010440c7d9b@mail.gmail.com> > Any reason why it updates on close rather than truncating on open(OTRUNC)? Surely you have a different question. Russ ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [9fans] rio snarf 2004-10-27 17:31 ` Fco. J. Ballesteros @ 2004-10-27 17:51 ` Russ Cox 2004-10-27 17:57 ` Fco. J. Ballesteros 0 siblings, 1 reply; 5+ messages in thread From: Russ Cox @ 2004-10-27 17:51 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs > Well. We just found that removing snarf from rio fsys makes things > work great wrt sharing the snarf buffer across machines. If that's all you want to do, just create a /dev/snarf before rio runs -- if it sees one already there, it won't provide one. > At first, we thought that if was enough to call open(OTRUNC) while > copying to the snarf buffer, then we noticed the deadlock with the > open("/dev/snarf") in rio, then we tried removing snarf from rio, and, > voila. This I still don't fully understand. The reason the snarf buffer doesn't change until close is probably lost to history, but one nice effect is that updating the snarf buffer is atomic -- you'll never see a partially written one. > Either I'm crazy because of the lots of coffee I have been drinking, or > there is something I'm missing regarding why rio has snarf builtin instead > of using a regular file for that. Rio used to provide a separate snarf buffer for each instance of rio. It's only recently that there has been this push toward having one snarf buffer for the whole system. Russ ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [9fans] rio snarf 2004-10-27 17:51 ` Russ Cox @ 2004-10-27 17:57 ` Fco. J. Ballesteros 0 siblings, 0 replies; 5+ messages in thread From: Fco. J. Ballesteros @ 2004-10-27 17:57 UTC (permalink / raw) To: russcox, 9fans [-- Attachment #1: Type: text/plain, Size: 451 bytes --] Well, having a /dev/snarf created by, say, binding /tmp/blah to /dev/snarf does not seem to work, because rio ends up leaving the biggest thing that was in there (because it does not truncate the file). I think it assumes that the behaviour of /dev/snarf is that of rio's, and not that of a regular file. Regarding the question, I think you answered it. I understand it provides a snarf if you have different per-rio snarf files. thanks [-- Attachment #2: Type: message/rfc822, Size: 4005 bytes --] From: Russ Cox <russcox@gmail.com> To: Fans of the OS Plan 9 from Bell Labs <9fans@cse.psu.edu> Subject: Re: [9fans] rio snarf Date: Wed, 27 Oct 2004 13:51:10 -0400 Message-ID: <ee9e417a04102710516945fe9e@mail.gmail.com> > Well. We just found that removing snarf from rio fsys makes things > work great wrt sharing the snarf buffer across machines. If that's all you want to do, just create a /dev/snarf before rio runs -- if it sees one already there, it won't provide one. > At first, we thought that if was enough to call open(OTRUNC) while > copying to the snarf buffer, then we noticed the deadlock with the > open("/dev/snarf") in rio, then we tried removing snarf from rio, and, > voila. This I still don't fully understand. The reason the snarf buffer doesn't change until close is probably lost to history, but one nice effect is that updating the snarf buffer is atomic -- you'll never see a partially written one. > Either I'm crazy because of the lots of coffee I have been drinking, or > there is something I'm missing regarding why rio has snarf builtin instead > of using a regular file for that. Rio used to provide a separate snarf buffer for each instance of rio. It's only recently that there has been this push toward having one snarf buffer for the whole system. Russ ^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2004-10-27 17:57 UTC | newest] Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2004-10-27 11:16 [9fans] rio snarf Fco. J. Ballesteros 2004-10-27 17:10 ` Russ Cox 2004-10-27 17:31 ` Fco. J. Ballesteros 2004-10-27 17:51 ` Russ Cox 2004-10-27 17:57 ` Fco. J. Ballesteros
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).