tag:old.nabble.com,2006:forum-990Nabble - Coda2009-11-29T03:42:45ZCoda is an advanced networked filesystem. Coda home is <a href="http://www.coda.cs.cmu.edu/" target="_top" rel="nofollow">here</a>.tag:old.nabble.com,2006:post-26561393codasrv dies with RVM_EIO2009-11-29T03:42:45Z2009-11-29T03:42:45ZBrett Lymn<br>I seem to have broken my coda install in an interesting way. The
<br>codasrv daemon is dying with a RVM_EIO error. I bit of debugging it
<br>appears that the function find_log() in the rvm library is returning a
<br>NULL (entry not found on the log_root list), the log_dev passed in
<br>looks to be the correct path but log_root appears to be a null list
<br>for some reason and I don't know why.
<br><br>The install was operating fine up until the evening when I mistyped my
<br>token password on a client with pending integrations (my laptop - I
<br>had done some hacking on the train home and wanted to integrate the
<br>changes to the server). Of course since the token did not match the
<br>integration was not going to happen - the problem was I could not
<br>manage to undo this error, I tried a cunlog and clog again but I still
<br>supposedly had a bad token, I tried restarting venus but that did not
<br>help. In desperation I stopped and started the coda server on my home
<br>server, at this point I believe things went bad and since this time I
<br>have not had a functioning coda server.
<br><br>I have tried re-running rvm-init to set up the RVM again but that has
<br>made no difference.
<br><br>I am running the coda server on netbsd-current on a amd64
<br>architecture, the client (for what it is worth) is netbsd-current
<br>running on the i386 architecture (32bit). The setup has been running
<br>fine for years before I fat-fingered it. Any suggestions on what I
<br>can do to fix this?
<br><br>--
<br>Brett Lymn
<br>"Warning:
<br>The information contained in this email and any attached files is
<br>confidential to BAE Systems Australia. If you are not the intended
<br>recipient, any use, disclosure or copying of this email or any
<br>attachments is expressly prohibited. If you have received this email
<br>in error, please notify us immediately. VIRUS: Every care has been
<br>taken to ensure this email and its attachments are virus free,
<br>however, any loss or damage incurred in using this email is not the
<br>sender's responsibility. It is your responsibility to ensure virus
<br>checks are completed before installing any data sent in this email to
<br>your computer."
<br><br><br><p>From forum: <a href="http://old.nabble.com/Coda---General-f993.html" embed="fixTarget[993]" target="_top" >Coda - General</a></p>tag:old.nabble.com,2006:post-26320557Scheduled outage for coda.cs.cmu.edu2009-11-12T07:21:01Z2009-11-12T07:21:01ZJan Harkes<br>Due to testing of the electrical and backup power systems in CMU's new
<br>computer science building, all Coda servers (web/ftp/coda fs) will be
<br>powered down and unavailable starting 2009-11-14 02:00:00 UTC until
<br>2009-11-14 14:00:00 UTC (friday 9pm EST to saturday 9am EST).
<br><br>Jan
<br><br><p>From forum: <a href="http://old.nabble.com/Coda---General-f993.html" embed="fixTarget[993]" target="_top" >Coda - General</a></p>tag:old.nabble.com,2006:post-25852831Re: Changing hostname2009-10-12T02:31:49Z2009-10-12T02:31:49ZFrederic PracaLe Sat, 10 Oct 2009 00:27:21 -0400,
<br>Jan Harkes <<a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=25852831&i=0" target="_top" rel="nofollow">jaharkes@...</a>> a écrit :
<br><br>> Frederic Praca wrote:
<br>> > Hello guys,
<br>> > I finally repaired my coda file system thanks to this mail
<br>> > (<a href="http://www.coda.cs.cmu.edu/maillists/codalist/codalist-2006/7900.html" target="_top" rel="nofollow">http://www.coda.cs.cmu.edu/maillists/codalist/codalist-2006/7900.html</a> ).
<br>> >
<br>> > Now, I'm looking for a safe way to change the hostname of the
<br>> > server the SCM is running on.
<br>> >
<br>> I guess this name change implies an ip-address change as well.
<br>No, in fact, it's only a problem with my sendmail configuration which
<br>forces me to change my hostname to a public FQDN.
<br><div class='shrinkable-quote'><br>> Changing the name isn't that hard, just edit the /vice/db/servers
<br>> file on the SCM and /vice/db/hostname on the server whose name is
<br>> changing. If the name of the SCM changes, you also need to
<br>> update /vice/srv/scm.
<br>>
<br>> After editing these files the changes should automatically propagate
<br>> to all servers, if that isn't happening, restart the update daemons.
<br>> Then restart the Coda servers, the name-to-address resolution only
<br>> happens at startup, so they won't pick up the new server address
<br>> until all of them have been restarted.
</div>That's what I've done last time I tried.
<br>
<br>> Finally (the most painful part) all clients need to be reinitialized,
<br>> otherwise even if they successfully pick up the new addresses they
<br>> will keep trying to reconnect to the old server address.
<br>Aha, forgot that last time, that could explain a lot of problems I got.
<br><br>Now it works, thanks for help
<br>
<br>> Jan
<br>Fred
<br><br><p>From forum: <a href="http://old.nabble.com/Coda---General-f993.html" embed="fixTarget[993]" target="_top" >Coda - General</a></p>tag:old.nabble.com,2006:post-25830976Re: Changing hostname2009-10-09T21:27:21Z2009-10-09T21:27:21ZJan HarkesFrederic Praca wrote:
<br>> Hello guys,
<br>> I finally repaired my coda file system thanks to this mail
<br>> (<a href="http://www.coda.cs.cmu.edu/maillists/codalist/codalist-2006/7900.html" target="_top" rel="nofollow">http://www.coda.cs.cmu.edu/maillists/codalist/codalist-2006/7900.html</a> ).
<br>>
<br>> Now, I'm looking for a safe way to change the hostname of the server the
<br>> SCM is running on.
<br>>
<br>I guess this name change implies an ip-address change as well. Changing
<br>the name isn't that hard, just edit the /vice/db/servers file on the SCM
<br>and /vice/db/hostname on the server whose name is changing. If the name
<br>of the SCM changes, you also need to update /vice/srv/scm.
<br><br>After editing these files the changes should automatically propagate to
<br>all servers, if that isn't happening, restart the update daemons. Then
<br>restart the Coda servers, the name-to-address resolution only happens at
<br>startup, so they won't pick up the new server address until all of them
<br>have been restarted.
<br><br>Finally (the most painful part) all clients need to be reinitialized,
<br>otherwise even if they successfully pick up the new addresses they will
<br>keep trying to reconnect to the old server address.
<br><br>Jan
<br><br><p>From forum: <a href="http://old.nabble.com/Coda---General-f993.html" embed="fixTarget[993]" target="_top" >Coda - General</a></p>tag:old.nabble.com,2006:post-25808664Changing hostname2009-10-08T10:48:32Z2009-10-08T10:48:32ZFrederic PracaHello guys,
<br>I finally repaired my coda file system thanks to this mail
<br>(<a href="http://www.coda.cs.cmu.edu/maillists/codalist/codalist-2006/7900.html" target="_top" rel="nofollow">http://www.coda.cs.cmu.edu/maillists/codalist/codalist-2006/7900.html</a> ).
<br><br>Now, I'm looking for a safe way to change the hostname of the server the
<br>SCM is running on.
<br>Is there a way to change it without re-installing
<br>the whole SCM ?
<br><br>I'm pretty sure it exists as Coda never betrayed me :-)
<br><br>Thanks for help
<br><br>Fred
<br>--
<br>"... Je me suis imposé la loi de ne procéder jamais que du connu
<br>à l'inconnu, de ne déduire aucune conséquence qui ne dérive
<br>immédiatement des expériences et des observations ..."
<br> -+- Antoine-Laurent Lavoisier, 1743-1794 -+-
<br><br><p>From forum: <a href="http://old.nabble.com/Coda---General-f993.html" embed="fixTarget[993]" target="_top" >Coda - General</a></p>tag:old.nabble.com,2006:post-25416187Problem with codasrv2009-09-12T09:27:15Z2009-09-12T09:27:15ZFrederic PracaHello,
<br>using FreeBSD 7.2, I have the following problem since few days :
<br>> tail /data/srv/SrvErr
<br>Assertion failed: 0, file "srv.cc", line 1711
<br>EXITING! Bye!
<br><br>> tail /data/srv/SrvLog
<br><br>09:41:21 RvmType is Rvm
<br>09:41:21 Main process doing a LWP_Init()
<br>09:41:21 Main thread just did a RVM_SET_THREAD_DATA
<br><br>09:41:21 Setting Rvm Truncate threshhold to 5.
<br><br>log_recover failed.
<br>do_rvm_options failed
<br>09:41:21 rvm_init failed RVM_EIO
<br><br>I don't know what to do. Do you have any idea ?
<br><br>Moreover, how can I change the hostname of my coda server without
<br>breaking it ?
<br><br>Thanks
<br>Fred
<br>--
<br>On doit appeler machine, dans le sens le plus étendu, toute idée sans
<br>penseur.
<br> -+- Émile Chartier, dit Alain (1868-1951), Propos sur la
<br>religion -+-
<br><br><p>From forum: <a href="http://old.nabble.com/Coda---General-f993.html" embed="fixTarget[993]" target="_top" >Coda - General</a></p>tag:old.nabble.com,2006:post-24579633[PATCH]: Fix overruns in codasrv main routine2009-07-20T16:47:14Z2009-07-20T16:47:14ZNeil Horman-2Hey, glibc just found this on fedora. A stack overrun of a few bytes in the
<br>sname variable in the coda server main routine. Its 20 bytes long, and at least
<br>one of the sprintfs writes at least 23 bytes to the buffer. The patch below
<br>fixes it. I suppose switching to snprintf would be better, but the code seems
<br>so unlikely to change further at this point, this just seemed a bit more
<br>straightforward
<br><br>Neil
<br><br><br>Signed-off-by: Neil Horman <<a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=24579633&i=0" target="_top" rel="nofollow">nhorman@...</a>>
<br><br><br> srv.cc | 2 +-
<br> 1 file changed, 1 insertion(+), 1 deletion(-)
<br><br>diff --git a/coda-src/vice/srv.cc b/coda-src/vice/srv.cc
<br>index e0c5144..d75cc52 100644
<br>--- a/coda-src/vice/srv.cc
<br>+++ b/coda-src/vice/srv.cc
<br>@@ -315,7 +315,7 @@ void zombie(int sig)
<br>
<br> int main(int argc, char *argv[])
<br> {
<br>- char sname[20];
<br>+ char sname[32];
<br> int i;
<br> struct stat buff;
<br> PROCESS serverPid, resPid, smonPid, resworkerPid;
<br><br><p>From forum: <a href="http://old.nabble.com/Coda---General-f993.html" embed="fixTarget[993]" target="_top" >Coda - General</a></p>tag:old.nabble.com,2006:post-24557563Re: Using Coda for server mirroring (in lieu of rsync)2009-07-19T06:38:11Z2009-07-19T06:38:11ZM. SatyanarayananWouldn't a much simpler design be two substantial Coda clients each running a web server?
<br>The web pages would then be a shared pool stored on N Coda servers ---- N being determined
<br>by capacity and load. You could experiment with singly-replicated Coda servers to decide if it
<br>works well -- server replication is needed only to provide additional resiliency to failures. Note
<br>that the Coda clients (i.e. web servers) can handle brief periods of disconnection (few minutes to
<br>tens of minutes, perhaps) without any server replication.
<br><br>The policy to direct web accesses to specific web servers is outside the above. You could
<br>just have any web server service any web request. Or, you could partition the Coda namespace
<br>statically and redirect requests to the other web server if needed. This would have the
<br>advantage of increasing the locality seen by the cache on each Coda client. Fancier load
<br>balancing schemes are easier to imagine, but simplicity usually wins the day.
<br><br>It is worth going back to the dawn of the Web and seeing how AFS was used very successfully at NCSA.
<br>(see Thomas Kwan, Robert McGrath, and Daniel Reed. NCSA's World Web Server: Design and Performance, IEEE Computer 1995(0018-9162):68-74, 1995 --- pdf attached))
<br>Replace "AFS" with "Coda" and you have a simple starting point to explore.
<br><br /> <div class="small"><br/><img src="http://old.nabble.com/images/icon_attachment.gif" > <strong>kwan95.pdf</strong> (798K) <a href="http://old.nabble.com/attachment/24557563/0/kwan95.pdf" target="_top">Download Attachment</a></div><p>From forum: <a href="http://old.nabble.com/Coda---General-f993.html" embed="fixTarget[993]" target="_top" >Coda - General</a></p>tag:old.nabble.com,2006:post-24552097Using Coda for server mirroring (in lieu of rsync)2009-07-18T14:29:21Z2009-07-18T14:29:21ZAndy Sy-2We have a web server setup which we want to
<br>mirror and load-balance. We basically want to
<br>be able to synchronize the contents of the
<br>htdocs/ directories on two or more different
<br>servers in [more or less] real time.
<br><br>The common approach would be to have rsync running
<br>on each server copying the most recent version of a
<br>file over to the server(s) that do not yet have it
<br>every few minutes (invoked via cron).
<br><br>I feel that rsync is really a rather clunky approach
<br>and I was wondering, is Coda a suitable and much better
<br>alternative in this scenario?
<br><br>Based on my surface reading of how Coda works (forgive
<br>me if I have any egregious misconceptions), in the simplest
<br>case of 2 servers "mirroring" each other, the setup would be
<br>a Vice file server process running on each of the 2 servers,
<br>as well as a Venus process on each providing the
<br>htdocs/ mount.
<br><br>Would the above be a reasonable, recommended setup?
<br><br><br>I am guessing the operation would work very roughly
<br>something like the below:
<br><br>Updating htdocs/* while connected to server A would naturally
<br>update server A's Vice copy of htdocs/ first which would then
<br>transparently get replicated over to server B's copy eventually.
<br><br>In a case where server B's Vice process happens to be down, but
<br>with everything else still up, server B's htdocs/ would get
<br>served from/by server A's Vice process transparently?
<br><br>In the case where server A and B's Vice processes are both
<br>up, accessing htdocs/ would be effectively be nearly as
<br>fast as access to to a, say, normal ext3 mount?
<br><br><br><br><br><br><br><p>From forum: <a href="http://old.nabble.com/Coda---General-f993.html" embed="fixTarget[993]" target="_top" >Coda - General</a></p>tag:old.nabble.com,2006:post-24278853Re: Restore failed.2009-06-30T13:15:34Z2009-06-30T13:15:34ZJan HarkesOn Tue, Jun 30, 2009 at 08:45:20PM +0200, Marc Schlinger wrote:
<br>> I'm still going futher in testing coda.
<br>> I'm having trouble on restoring a dump, whereas this morning i didn't
<br>> have any problems.
<br>...
<br>> Now i try to restore the dump.:
<br>> # volutil restore -f /tmp/test-F-19h07m20-300609 /vicepa
<br>> V_BindToServer: binding to host igor.alpha.agorabox.org
<br>> ReadDump: Error RPC2_SEFAIL2 (F) in CheckSideEffect
<br>>
<br>> # tail -n2 /vice/srv/SrvLog
<br>> 19:08:48 ReadStuff: ReadDump failed RPC2_SEFAIL3 (F).
<br>> 19:08:48 Error reading dump header; aborted
<br><br>I generally found that restoring backup volumes isn't as useful as it
<br>may seem. First of all, the restored volume is a non-replicated,
<br>read-only volume without resolution logs, identical to the backup
<br>snapshot that was taken by running volutil backup and there is no way to
<br>tweak the restored volume back to a full read-write replica so you end
<br>up having to copy all the data from the restored backup to a new volume.
<br><br>It also isn't possible to restore into an existing volume, which is
<br>probably why your restore is failing. When no volume name or id is
<br>specified it tries to use the original backup volume's name and id which
<br>in this case already exist.
<br><br>I've relied on server replication to handle single server hardware
<br>failures, and only have needed backups to restore occasional files that
<br>users accidentally deleted. For that case it is often much simpler to
<br>just convert the volume dump to a tar archive with codadump2tar and pull
<br>the file from there.
<br><br>Actually even for restoring a volume piping the dump through
<br>codadump2tar and extracting it into the new replicated volume tends to
<br>be easier than restoring the backup volume and then copying everything.
<br>In both cases the ACLs are the hard part, they are missing in the
<br>codadump2tar case, but most ways of doing the copy from the backup
<br>volume don't copy acls either.
<br><br>Jan
<br><br><p>From forum: <a href="http://old.nabble.com/Coda---General-f993.html" embed="fixTarget[993]" target="_top" >Coda - General</a></p>tag:old.nabble.com,2006:post-24277444Restore failed.2009-06-30T11:45:20Z2009-06-30T11:45:20ZMarc SCHLINGERHi,
<br><br>I'm still going futher in testing coda.
<br>I'm having trouble on restoring a dump, whereas this morning i didn't
<br>have any problems.
<br><br>First I wrote a script to create a dump, here is the output
<br>All the command are excecuted on the SCM.
<br><br># mybackup.sh -v test --verbose
<br>volutil lock 01000008
<br>volutil backup 01000008
<br>backup_id=0100000e
<br>volutil dump 0100000e /tmp/test-F-19h07m20-300609
<br><br>Volume_backup_id = 0100000e
<br>backup_path = /tmp/test-F-19h07m20-300609
<br><br>Now i try to restore the dump.:
<br># volutil restore -f /tmp/test-F-19h07m20-300609 /vicepa
<br>V_BindToServer: binding to host igor.alpha.agorabox.org
<br>ReadDump: Error RPC2_SEFAIL2 (F) in CheckSideEffect
<br><br># tail -n2 /vice/srv/SrvLog
<br>19:08:48 ReadStuff: ReadDump failed RPC2_SEFAIL3 (F).
<br>19:08:48 Error reading dump header; aborted
<br><br><br>I didn't manage to discover what i'm doing wrong?
<br>Have you got an idea?
<br><br>Regards,
<br>Marc.
<br><br>--
<br><br><p>From forum: <a href="http://old.nabble.com/Coda---General-f993.html" embed="fixTarget[993]" target="_top" >Coda - General</a></p>tag:old.nabble.com,2006:post-24188861Re: Problems with replication on two servers.2009-06-24T09:16:06Z2009-06-24T09:16:06Zu+codalist-wk5rHi Marc,
<br><br>On Wed, Jun 24, 2009 at 03:13:57PM +0200, Marc SCHLINGER wrote:
<br>> Given that we have two servers,
<br>> Can a client modify a volume, send the information to one server he can
<br>> join, and have the server keeps the differents replicas of this volume
<br>> up-to-date, whithout the client connecting to or warning the 2nd server?
<br><br>No, not without _some_ client having contact to _both_ servers
<br>and accessing the modified file.
<br><br>Then the client notices that the two copies of the file are not
<br>congruent (there are so called version vectors which make it possible
<br>to detect such a situation) and tells the servers to synchronise the file,
<br>which they do.
<br><br>Then and only then both file replicas become up-to-date.
<br><br>Hope this helps.
<br><br>Regards,
<br>Rune
<br><br><p>From forum: <a href="http://old.nabble.com/Coda---General-f993.html" embed="fixTarget[993]" target="_top" >Coda - General</a></p>tag:old.nabble.com,2006:post-24184936Re: Problems with replication on two servers.2009-06-24T06:13:57Z2009-06-24T06:13:57ZMarc SCHLINGERHello,
<br><br><a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=24184936&i=0" target="_top" rel="nofollow">u+codalist-wk5r@...</a> a écrit :
<div class='shrinkable-quote'><br>> Hello Marc,
<br>>
<br>> On Thu, Apr 23, 2009 at 10:59:51PM +0200, Marc SCHLINGER wrote:
<br>>
<br>>> Let's take the assumption, we work in multi-site environnement.
<br>>> For different reason we don't want any stream from our users to go by our
<br>>> vpn, (dedicated inter-site line 99% of avaibility).
<br>>> So each site handles his coda server (one handle the scm).
<br>>>
<br>>
<br>> This is apparently unsupported (it may work,
<br>> we are using geographically distant servers in a couple of realms,
<br>> but the network between the servers may not be flaky no matter what)
<br>>
<br>>
<br>>> Some users because they move a lot between each site use a laptop and have
<br>>> their volume replicated.
<br>>>
<br>>> Once their are in a site they can only join the server of this site.
<br>>>
<br>>
<br>> You are thinking in an "inappropriate" way. Clients interact with _realms_,
<br>> and internally pick servers to talk to. There is no user interface
<br>> to those internals and it is not supposed to be present.
<br>>
<br>>
<br>>> Can coda handle this scheme? Are the volumes the only things that can move
<br>>> around? Or can
<br>>> a client move from one server to another?
<br>>>
<br>>
<br>> A client will talk to some server(s) of the realm depending on what it thinks
<br>> of network bandwidth and of the servers' availability. That's it.
<br>> It will move "from server to server" when it feels for doing that,
<br>> it is totally Coda's internal business.
<br>>
<br>> This is not as bad as it may seem, most often the clients pick the "nearest"
<br>> server, but you do not have any guarantee that they do so each time,
<br>> they don't.
<br>>
<br>>
<br>>> Thanks a lot.
<br>>>
<br>>
<br>> Hope this helps to see what one may expect and what one shouldn't expect
<br>> from Coda.
<br>>
</div>Here I may have not fully understand what Rune told me.
<br>I've done a couple of test, and I 've found out different information in
<br>the documentation, but all seems to collide.
<br><br>Given that we have two servers,
<br>Can a client modify a volume, send the information to one server he can
<br>join, and have the server keeps the differents replicas of this volume
<br>up-to-date, whithout the client connecting to or warning the 2nd server?
<br><br>Sorry, if I'm insistent but I not fully at ease with english.
<br><br>Thanks.
<br>Marc
<br><br><br><p>From forum: <a href="http://old.nabble.com/Coda---General-f993.html" embed="fixTarget[993]" target="_top" >Coda - General</a></p>tag:old.nabble.com,2006:post-23451947Coda on OpenSolaris (not yet)2009-05-08T12:12:07Z2009-05-08T12:12:07Zu+codalist-wk5rHi,
<br><br>FWIIW.
<br><br>I have checked whether something useful can be done with the old
<br>solaris kernel module
<br><br>(<a href="http://www.coda.cs.cmu.edu/pub/coda/src/solaris-coda-0.03.tgz" target="_top" rel="nofollow">http://www.coda.cs.cmu.edu/pub/coda/src/solaris-coda-0.03.tgz</a>)
<br><br>Solaris kernel interfaces changed since then.
<br><br>I have made changes to the module according to the newer
<br>documentation, got it through compilation and was able to add_drv
<br>on NexentaOS_20081207 32-bit (on Intel).
<br><br>This does not mean it is functional:
<br><br>- untested whether it works at all (see about userland below)
<br><br>- this kernel module does not contain support for realms and as such
<br>is incompatible with the current userland (corresponds to Coda 5.x),
<br>this should be relatively straightforward to fix
<br><br>- uncertain how much cleanup would be necessary to support 64-bit kernel
<br><br>Userland:
<br><br>With some quick-and-dirty changes I was able to get lwp, rvm, rpc2 and coda
<br>client userland (6.9.4) through compilation.
<br><br>It is not functional:
<br><br>- the compiled Venus segfaults at handling a thread switch, I notice that
<br>sigaltstack() also gets EPERM which may indicate a problem
<br><br>- for a change, recompiling with lwp-on-pthreads needed a fix in Makefile.in
<br>for lwp_pt; the resulting venus segfaults anyway, even earlier than otherwise
<br><br>(the thread issues should not be very hard to resolve?)
<br><br>I can not contribute with more time and effort.
<br><br>Is there any interested party to take over the hacks and continue the work?
<br>The development stalled for about 9 years, so there seems to hardly be
<br>any interest, but who knows :)
<br><br>Regards,
<br>Rune
<br><br><p>From forum: <a href="http://old.nabble.com/Coda---General-f993.html" embed="fixTarget[993]" target="_top" >Coda - General</a></p>tag:old.nabble.com,2006:post-23213199Re: Problems with replication on two servers.2009-04-24T02:44:17Z2009-04-24T02:44:17Zu+codalist-wk5rHello Marc,
<br><br>On Thu, Apr 23, 2009 at 10:59:51PM +0200, Marc SCHLINGER wrote:
<br>> Let's take the assumption, we work in multi-site environnement.
<br>> For different reason we don't want any stream from our users to go by our
<br>> vpn, (dedicated inter-site line 99% of avaibility).
<br>> So each site handles his coda server (one handle the scm).
<br><br>This is apparently unsupported (it may work,
<br>we are using geographically distant servers in a couple of realms,
<br>but the network between the servers may not be flaky no matter what)
<br><br>> Some users because they move a lot between each site use a laptop and have
<br>> their volume replicated.
<br>>
<br>> Once their are in a site they can only join the server of this site.
<br><br>You are thinking in an "inappropriate" way. Clients interact with _realms_,
<br>and internally pick servers to talk to. There is no user interface
<br>to those internals and it is not supposed to be present.
<br><br>> Can coda handle this scheme? Are the volumes the only things that can move
<br>> around? Or can
<br>> a client move from one server to another?
<br><br>A client will talk to some server(s) of the realm depending on what it thinks
<br>of network bandwidth and of the servers' availability. That's it.
<br>It will move "from server to server" when it feels for doing that,
<br>it is totally Coda's internal business.
<br><br>This is not as bad as it may seem, most often the clients pick the "nearest"
<br>server, but you do not have any guarantee that they do so each time,
<br>they don't.
<br><br>> Thanks a lot.
<br><br>Hope this helps to see what one may expect and what one shouldn't expect
<br>from Coda.
<br><br>Best regards,
<br>Rune
<br><br><p>From forum: <a href="http://old.nabble.com/Coda---General-f993.html" embed="fixTarget[993]" target="_top" >Coda - General</a></p>tag:old.nabble.com,2006:post-23212957Re: Problems with replication on two servers.2009-04-24T02:26:53Z2009-04-24T02:26:53Zu+codalist-wk5rHello Jan,
<br><br>On Thu, Apr 23, 2009 at 04:52:48PM -0400, Jan Harkes wrote:
<br>> > 18:25:10 GetVolObj: Volume (1000002) already write locked
<br>> > 18:25:10 RS_LockAndFetch: Error 11 during GetVolObj for 1000002.1.1
<br>> > 18:25:46 LockQueue Manager: found entry for volume 0x1000002
<br>>
<br>> The volume xxx already write locked sounds very ominous, but it is
<br>> really just a debugging message added to help debug Rune's issues.
<br><br>> He is running a non-replicated server, so his testing never hit the
<br>> resolution case, and either way it doesn't seem to have solved his
<br>> issues, so I'll probably revert this change. Especially as now there is
<br>> no queueing on these locks so readers are in some cases not able to
<br>> obtain the lock.
<br><br>Trying to minimize confusion: I get this message in a replicated scenario
<br>quite regularly "forever", the only way to get rid of this situation
<br>is to restart the server with the runaway lock. It is not the same
<br>as the harmless messages on the single server.
<br><br>I did not complain loudly as I see this on servers where one of them
<br>has a slow connection which potentially can be flooded (say by sftp's
<br>unflexible resend policy) and become unreliable. You said it is an
<br>unsupported configuration :)
<br><br>My observed error on the clients is though
<br>"Resource temporarily unavailable", not a dangling link.
<br><br>I have a realm with a volume in this state right now.
<br>It is not going to recover on its own, nor could I use repair.
<br><br>[So this has nothing to do with our non-replicated server, which
<br>apparently does not deadlock - fully conforming to your expectations,
<br>but it still has the "unexpected delays" issue which may look
<br>as a deadlock.]
<br><br>Regards,
<br>Rune
<br><br><p>From forum: <a href="http://old.nabble.com/Coda---General-f993.html" embed="fixTarget[993]" target="_top" >Coda - General</a></p>tag:old.nabble.com,2006:post-23205450Re: Problems with replication on two servers.2009-04-23T13:59:51Z2009-04-23T13:59:51ZMarc SCHLINGERYou wrote :
<br> This problem stems quite certainly from one of the original assumptions
<br> of Coda design - the servers are treated as well-connected to each other,
<br> in contrast to the clients which may have unreliable connections.
<br><br>So, after other test, I ask you if coda is designed for mobility I mean:
<br><br>Let's take the assumption, we work in multi-site environnement.
<br>For different reason we don't want any stream from our users to go by our vpn, (dedicated inter-site line 99% of avaibility).
<br>So each site handles his coda server (one handle the scm).
<br>Some users because they move a lot between each site use a laptop and have their volume replicated.
<br><br>Once their are in a site they can only join the server of this site.
<br>I didn't manage to have a client working., this way.
<br><br>Can coda handle this scheme? Are the volumes the only things that can move around? Or can
<br>a client move from one server to another?
<br><br>You wrote:
<br> The developers' resources are limited, so your best bet would be to join
<br> the development. Unfortunately the "entry threshold" is quite high
<br> because of the code being complex and still reflecting the years of
<br> research-oriented programming.
<br><br>It would be an honor for me to join the dev-team but I don't think I meet the
<br>quality requierment.
<br><br><br>Thanks a lot.
<br>Marc
<br><br>--
<br><br><p>From forum: <a href="http://old.nabble.com/Coda---General-f993.html" embed="fixTarget[993]" target="_top" >Coda - General</a></p>tag:old.nabble.com,2006:post-23205298Re: Problems with replication on two servers.2009-04-23T13:52:48Z2009-04-23T13:52:48ZJan HarkesOn Thu, Apr 23, 2009 at 11:42:22AM +0200, Marc SCHLINGER wrote:
<br>> The root volume is created at the end of the scm installation so I guess
<br>> it's not replicated on the replica.
<br><br>Right, that is done to simplify the common case of a new user setting
<br>up just one server.
<br><br>You would have to remove the root volume and create a new replicated
<br>volume to replace it with, and then probably reinitialize the clients so
<br>that they actually forget about the old single replica root.
<br><br>> root@client# cfs mkmount /coda/myrealm.yeh/test test
<br>> root@client# ls /coda/myrealm.yeh/test
<br>>
<br>> Until this step it's okay. I can create files in volume test.
<br><br>That is a good start.
<br><br>> It becomes complicated when on the scm, I block all traffic using iptables.
<br>> I see the client starting sending messages to the replica(via tcpdump).
<br>> But when I unblock the traffic on the scm I always get the same error.
<br>> On the scm:
<br>> 18:25:10 GetVolObj: Volume (1000002) already write locked
<br>> 18:25:10 RS_LockAndFetch: Error 11 during GetVolObj for 1000002.1.1
<br>> 18:25:46 LockQueue Manager: found entry for volume 0x1000002
<br><br>The volume xxx already write locked sounds very ominous, but it is
<br>really just a debugging message added to help debug Rune's issues.
<br>It happens whenever we get a read operation for a volume that is write
<br>locked, at this point we used to start waiting for the write to complete
<br>which uses up a server thread. However Rune was describing some sort of
<br>a deadlock issue, so instead of silently sleeping we now loudly complain
<br>and return an error and leave it up to the client to retry the operation.
<br><br>He is running a non-replicated server, so his testing never hit the
<br>resolution case, and either way it doesn't seem to have solved his
<br>issues, so I'll probably revert this change. Especially as now there is
<br>no queueing on these locks so readers are in some cases not able to
<br>obtain the lock.
<br><br>> On the replica:
<br>> 18:34:36 Going to spool log entry for phase3
<br>> 18:34:38 CheckRetCodes: server 132.227.168.169 returned error 11
<br>> 18:34:38 ViceResolve: Couldnt lock volume 7f000001 at all accessible servers
<br><br>Ok, so it fails to lock on the SCM continues resolving with only the
<br>remaining servers (replica), which of course doesn't really help much.
<br>Looks like resolution doesn't really like to get bounced back because the
<br>lock happened to be taken.
<br><br>> On the client I got a dangling symlink for volume test.
<br><br>Right, resolution failed to get all replicas in sync, so the client is
<br>still seeing different copies on different sites and shows the dangling
<br>symlink to indicate that the user should 'repair' the problem.
<br><br>In this case repair would probably be something like,
<br><br> $ repair
<br> repair> beginrepair /coda/myrealm.yeh
<br> repair> comparedirs /tmp/fix
<br> repair> dorepair
<br> repair> end
<br><br>Of course it would have been nice if resolution had succeeded.
<br><br>Jan
<br><br><p>From forum: <a href="http://old.nabble.com/Coda---General-f993.html" embed="fixTarget[993]" target="_top" >Coda - General</a></p>tag:old.nabble.com,2006:post-23195037Re: Problems with replication on two servers.2009-04-23T04:12:09Z2009-04-23T04:12:09Zu+codalist-wk5rHi Marc,
<br><br>On Thu, Apr 23, 2009 at 11:42:22AM +0200, Marc SCHLINGER wrote:
<br>> It becomes complicated when on the scm, I block all traffic using iptables.
<br>> I see the client starting sending messages to the replica(via tcpdump).
<br>> But when I unblock the traffic on the scm I always get the same error.
<br>> On the scm:
<br>> 18:25:10 GetVolObj: Volume (1000002) already write locked
<br>> 18:25:10 RS_LockAndFetch: Error 11 during GetVolObj for 1000002.1.1
<br>> 18:25:46 LockQueue Manager: found entry for volume 0x1000002
<br><br>There are certainly some locking issues hiding there.
<br>I have been hit by "Volume (XXXXXXX) already write locked" as well.
<br><br>This problem stems quite certainly from one of the original assumptions
<br>of Coda design - the servers are treated as well-connected to each other,
<br>in contrast to the clients which may have unreliable connections.
<br><br>> On the client I got a dangling symlink for volume test.
<br>>
<br>> My question is: Isn't coda fail tolerant? Or do I miss something in my
<br>> installation/configuration ?
<br><br>No, I don't think you do.
<br><br>Coda is quite fault tolerant, it copes pretty well with
<br>- clients losing connection to the net
<br>- a server going down once in a while
<br><br>It does not cope well with servers intermittently losing contact
<br>with each other.
<br><br>I guess this would be relatively hard to fix, given the original
<br>assumption named above. AFAIK there are no current plans to.
<br><br>It is nice that you are consequently testing Coda, this might certainly
<br>help to discover some hiding bugs and possibly even convince the developers
<br>about the server-side fault tolerance.
<br><br>There are certainly many potential users which would appreciate
<br>weakly connected servers being supported, but this may present
<br>some fundamental problems besides the implementation ones.
<br><br>On the other side Coda is very useful as it is and there are also issues
<br>of more immediate interest to fix.
<br>The developers' resources are limited, so your best bet would be to join
<br>the development. Unfortunately the "entry threshold" is quite high
<br>because of the code being complex and still reflecting the years of
<br>research-oriented programming.
<br><br>Regards,
<br>Rune
<br><br><p>From forum: <a href="http://old.nabble.com/Coda---General-f993.html" embed="fixTarget[993]" target="_top" >Coda - General</a></p>tag:old.nabble.com,2006:post-23193981Problems with replication on two servers.2009-04-23T02:42:22Z2009-04-23T02:42:22ZMarc SCHLINGERHello,
<br><br>I'm trying to get coda working with one replication server.
<br>on the scm: coda-server-6.9.4-1.i386
<br>on the replica: coda-server-6.9.4-0.3.rc2.i386
<br><br>I'm installing both servers with vice-setup script.
<br>All goes well.
<br>At the end, of the installation, I gather the /vice/db/vicetab and
<br>/vice/db/servers, and restart all servers.
<br><br>The root volume is created at the end of the scm installation so I guess
<br>it's not replicated on the replica.
<br><br>Then I create a volume like this :
<br>root@scm# createvol_rep test scm.myrealm.yeh/vicepa
<br>replica.myrealm.yeh/vicepa
<br><br>On my client I've edited /etc/coda/realms:
<br>myrealm.yeh scm.myrealm.yeh replica.myrealm.yeh
<br><br>Then I've executed:
<br>root@client# veuns-setup myrealm.yeh 20000
<br>root@client# clog -coda admincoda
<br>root@client# cfs mkmount /coda/myrealm.yeh/test test
<br>root@client# ls /coda/myrealm.yeh/test
<br><br>Until this step it's okay. I can create files in volume test.
<br><br>It becomes complicated when on the scm, I block all traffic using iptables.
<br>I see the client starting sending messages to the replica(via tcpdump).
<br>But when I unblock the traffic on the scm I always get the same error.
<br>On the scm:
<br>18:25:10 GetVolObj: Volume (1000002) already write locked
<br>18:25:10 RS_LockAndFetch: Error 11 during GetVolObj for 1000002.1.1
<br>18:25:46 LockQueue Manager: found entry for volume 0x1000002
<br><br>On the replica:
<br>18:34:36 Going to spool log entry for phase3
<br><br>18:34:38 CheckRetCodes: server 132.227.168.169 returned error 11
<br>18:34:38 ViceResolve: Couldnt lock volume 7f000001 at all accessible servers
<br>18:34:38 Entering RecovDirResolve 7f000001.1.1
<br><br>18:34:38 ComputeCompOps: fid(0x7f000001.1.1)
<br><br>18:34:38 RS_ShipLogs - returning 0
<br><br>On the client I got a dangling symlink for volume test.
<br><br>My question is: Isn't coda fail tolerant? Or do I miss something in my
<br>installation/configuration ?
<br><br>Thanks for your great work, and your help.
<br><br>Marc.
<br>--
<br><br><p>From forum: <a href="http://old.nabble.com/Coda---General-f993.html" embed="fixTarget[993]" target="_top" >Coda - General</a></p>tag:old.nabble.com,2006:post-23035866"Strange" use2009-04-14T01:56:41Z2009-04-14T01:56:41ZDiego Zuccato-2Hello all.
<br><br>I'm starting to play w/ Coda for an "anomalous" use: I'm trying to have
<br>two/three replicated, r/w, NFS servers on two/three LAN segments.
<br><br>IIUC for my use it should be enough to have two/three servers (with
<br>their own storage) and evey server is a client of itself (to make
<br>filesystem available to NFS daemon).
<br><br>Am I right? Is there a simpler/more stable approach to follow?
<br><br>Tks.
<br><br>BYtE,
<br> Diego.
<br><br><p>From forum: <a href="http://old.nabble.com/Coda---General-f993.html" embed="fixTarget[993]" target="_top" >Coda - General</a></p>tag:old.nabble.com,2006:post-22641245subscribe2009-03-21T14:08:51Z2009-03-21T14:08:51Zbala mudiam<br>
<p>From forum: <a href="http://old.nabble.com/Coda---Dev-f992.html" embed="fixTarget[992]" target="_top" >Coda - Dev</a></p>tag:old.nabble.com,2006:post-22335017Re: Interesting use case for Coda and trying to build for Ubuntu lpia2009-03-04T09:14:48Z2009-03-04T09:14:48ZMark KomarinskiOn 03/03/2009 02:19 PM, Jan Harkes wrote:
<div class='shrinkable-quote'><br>> The version of LWP installed on your system is too old, you probably
<br>> need to build/install version 2.5. (and update to rpc2-2.8 and rvm-1.16)
<br>>
<br>> The source archives for these should be here,
<br>> <a href="http://www.coda.cs.cmu.edu/pub/coda/src/" target="_top" rel="nofollow">http://www.coda.cs.cmu.edu/pub/coda/src/</a><br>>
<br>> Jan
<br>>
<br>> As an aside, as of the -6.9.4 release, the easiest way to get a
<br>> consistent build is to actually move the lwp, rpc2 and rvm sources into
<br>> the Coda source tree under lib-src and build everything as one, i.e.
<br>> [...]
<br>>
</div>I'm using Ubuntu and *strongly* prefer to use packages where possible.
<br>In this case, I was able to get the coda-provided source packages for
<br>lwp (and rpc2 and rvm) and get those compiled. Everything worked with a
<br>few slight changes and I have it running in lpia now.
<br><br>To start going off-thread (already?) I noticed that metadata is really
<br>really slow, like two minutes to do an ls -la of a directory with 64
<br>files in it but instantly once it's done the first time. Is there any
<br>way to get that to have it load and remain cached on the local side?
<br>This makes it really difficult do to things like rsync since so much
<br>time is spent looking up files.
<br><br>-Mark
<br><br><p>From forum: <a href="http://old.nabble.com/Coda---General-f993.html" embed="fixTarget[993]" target="_top" >Coda - General</a></p>tag:old.nabble.com,2006:post-22315813Re: Interesting use case for Coda and trying to build for Ubuntu lpia2009-03-03T11:19:14Z2009-03-03T11:19:14ZJan HarkesOn Tue, Mar 03, 2009 at 12:20:02PM -0500, Mark Komarinski wrote:
<br>> vproc.cc: In function ???void VprocWait(const void*)???:
<br>> vproc.cc:179: error: invalid conversion from ???const void*??? to ???void*???
<br>> vproc.cc:179: error: initializing argument 1 of ???int LWP_WaitProcess(void*)???
<br><br>The version of LWP installed on your system is too old, you probably
<br>need to build/install version 2.5. (and update to rpc2-2.8 and rvm-1.16)
<br><br>The source archives for these should be here,
<br> <a href="http://www.coda.cs.cmu.edu/pub/coda/src/" target="_top" rel="nofollow">http://www.coda.cs.cmu.edu/pub/coda/src/</a><br><br>Jan
<br><br>As an aside, as of the -6.9.4 release, the easiest way to get a
<br>consistent build is to actually move the lwp, rpc2 and rvm sources into
<br>the Coda source tree under lib-src and build everything as one, i.e.
<br><br> tar -xzf coda-6.9.4.tar.gz
<br> tar -xzf lwp-2.5.tar.gz ; mv lwp-2.5 coda-6.9.4/lib-src/lwp
<br> tar -xzf rpc2-2.8.tar.gz ; mv rpc2-2.8 coda-6.9.4/lib-src/rpc2
<br> tar -xzf rvm-1.16.tar.gz ; mv rvm-1.16 coda-6.9.4/lib-src/rvm
<br><br>or if you are using git,
<br><br> git clone git://coda.cs.cmu.edu/project/coda/dev/coda.git
<br> cd coda
<br> git submodule init
<br> git submodule update
<br> autoreconf -f -i
<br><br>Then configure will find the lib-src/ versions of the libraries and we
<br>will build and link against them,
<br><br> ./configure --prefix=/usr
<br> make
<br><br><p>From forum: <a href="http://old.nabble.com/Coda---General-f993.html" embed="fixTarget[993]" target="_top" >Coda - General</a></p>tag:old.nabble.com,2006:post-22313678Interesting use case for Coda and trying to build for Ubuntu lpia2009-03-03T09:20:02Z2009-03-03T09:20:02ZMark KomarinskiHi all,
<br><br>With the rise of netbooks, low on-board storage, and the ubiquity of
<br>wifi and 3G, I've been thinking that having a filesystem like coda makes
<br>a lot of sense. Here's my use case that I didn't get time to try, but
<br>will at some point:
<br><br>I've got a Dell Mini with Ubuntu loaded on it. When on vacation, I'm
<br>sure to fill the memory on my camera and want to store it elsewhere to
<br>make space. The Mini has a small SSD, so I'd really rather have my
<br>server at home mounted and store the files there. But when you're on
<br>the beach, Internet access can be kinda spotty. So why not have a
<br>filesystem that you can load data on to, and then have it sync with the
<br>server as a network connection is available?
<br><br>This led me here to Coda. I have a test server and client (both i386)
<br>up and running without issue, but I wanted to compile the debian package
<br>for my Ubuntu 8.10 laptop which uses the lpia port. I ran into some
<br>issues getting it to build and I hope one of you knowledgeable folk can
<br>assist. I've attached the relevant part of the build, but can include
<br>the entire output if you need.
<br><br>-Mark
<br><br />... (things appear good until here)
<br><br>Making all in venus
<br>make[4]: Entering directory `/home/mkomarinski/coda-6.9.4/coda-src/venus'
<br>i686-linux-gnulp-g++ -Wall -fno-exceptions -fcheck-new -DHAVE_CONFIG_H -I. -I../.. -DVENUS -DTIMING -DVENUSDEBUG -I../../lib-src/base -I../../coda-src/kerndep -I../../coda-src/util -I../../coda-src/vicedep -I../../coda-src/vicedep -I../../coda-src/dir -I../../coda-src/al -I../../coda-src/auth2 -I../../coda-src/auth2 -I../../coda-src/vv -I../../coda-src/lka -I../../coda-src/vol -I../../coda-src/librepair -g -O2 -MT fso_cfscalls2.o -MD -MP -MF .deps/fso_cfscalls2.Tpo -c -o fso_cfscalls2.o fso_cfscalls2.cc
<br>mv -f .deps/fso_cfscalls2.Tpo .deps/fso_cfscalls2.Po
<br>i686-linux-gnulp-g++ -Wall -fno-exceptions -fcheck-new -DHAVE_CONFIG_H -I. -I../.. -DVENUS -DTIMING -DVENUSDEBUG -I../../lib-src/base -I../../coda-src/kerndep -I../../coda-src/util -I../../coda-src/vicedep -I../../coda-src/vicedep -I../../coda-src/dir -I../../coda-src/al -I../../coda-src/auth2 -I../../coda-src/auth2 -I../../coda-src/vv -I../../coda-src/lka -I../../coda-src/vol -I../../coda-src/librepair -g -O2 -MT vproc.o -MD -MP -MF .deps/vproc.Tpo -c -o vproc.o vproc.cc
<br>vproc.cc: In function âvoid VprocWait(const void*)â:
<br>vproc.cc:179: error: invalid conversion from âconst void*â to âvoid*â
<br>vproc.cc:179: error: initializing argument 1 of âint LWP_WaitProcess(void*)â
<br>vproc.cc: In function âvoid VprocMwait(int, const void**)â:
<br>vproc.cc:196: error: invalid conversion from âconst void**â to âchar**â
<br>vproc.cc:196: error: initializing argument 2 of âint LWP_MwaitProcess(int, char**)â
<br>vproc.cc: In function âvoid VprocSignal(const void*, int)â:
<br>vproc.cc:213: error: invalid conversion from âconst void*â to âvoid*â
<br>vproc.cc:213: error: initializing argument 1 of âint LWP_INTERNALSIGNAL(void*, int)â
<br>vproc.cc:213: error: invalid conversion from âconst void*â to âvoid*â
<br>vproc.cc:213: error: initializing argument 1 of âint LWP_INTERNALSIGNAL(void*, int)â
<br>make[4]: *** [vproc.o] Error 1
<br>make[4]: Leaving directory `/home/mkomarinski/coda-6.9.4/coda-src/venus'
<br>make[3]: *** [all-recursive] Error 1
<br>make[3]: Leaving directory `/home/mkomarinski/coda-6.9.4/coda-src'
<br>make[2]: *** [all-recursive] Error 1
<br>make[2]: Leaving directory `/home/mkomarinski/coda-6.9.4'
<br>make[1]: *** [all] Error 2
<br>make[1]: Leaving directory `/home/mkomarinski/coda-6.9.4'
<br>make: *** [build-stamp] Error 2
<br><p>From forum: <a href="http://old.nabble.com/Coda---General-f993.html" embed="fixTarget[993]" target="_top" >Coda - General</a></p>tag:old.nabble.com,2006:post-22109416coser on FreeBSD2009-02-19T12:49:02Z2009-02-19T12:49:02Zu+codalist-wk5rHi All,
<br><br>for the record, I have tested the coser-installer
<br> <a href="http://www.aetey.se/dl/coser-1.5-20090214-linux-ia32-0" target="_top" rel="nofollow">http://www.aetey.se/dl/coser-1.5-20090214-linux-ia32-0</a><br>on plain FreeBSD (ia32, 7.0, with linux.ko loaded, no Linux compatibility
<br>packages) and it worked out of the box, as expected.
<br><br>Just to let you know if someone is thinking about running servers
<br>on FreeBSD.
<br><br>Cheers,
<br>Rune
<br><br><p>From forum: <a href="http://old.nabble.com/Coda---General-f993.html" embed="fixTarget[993]" target="_top" >Coda - General</a></p>tag:old.nabble.com,2006:post-22052449Re: Usage problems.2009-02-17T00:06:03Z2009-02-17T00:06:03Zu+codalist-wk5rHi Grzegorz,
<br><br>On Mon, Feb 16, 2009 at 09:17:25PM +0100, Grzegorz Nowakowski wrote:
<br>> there is /home/$user volume, and only the latter is used for data
<br>> storage now.
<br><br>> 1. What is practical maximum volume size, in terms of used space and
<br>> number of files?
<br><br>It depends on the usage pattern. A volume is a unit of serialisation.
<br>Otherwise see <a href="http://coda.wikidev.net/Limitations" target="_top" rel="nofollow">http://coda.wikidev.net/Limitations</a><br><br>> 2. What is practical maximum file size to be pushed around?
<br><br>It depends on your network and your patience.
<br>(Otherwise see <a href="http://coda.wikidev.net/Limitations" target="_top" rel="nofollow">http://coda.wikidev.net/Limitations</a>)
<br><br>> Use case: I have already learned that Coda isn't good choice for filer
<br>> with size of hundred gigabytes. I have settled for my /home/$user. It's
<br><br>Note that the file size is limited to 2G.
<br><br>> about 1,5GB and has about 30k files. Yet even with this amount of data
<br>> venus tends to eat more than 80% CPU, clog the system and become totally
<br><br>I guess this is due to your use of hoarding. Hoarding does not scale well
<br>as it is implemented now. I am not using it so can not help you with this.
<br><br>> 4. Is it possible to verify cache contents? That is, to determine
<br>> whether given file/directory is viewed remotely or is taken from local
<br>> cache?
<br><br>Any file you are viewing from Coda is copied to the local cache at the time
<br>of open() system call.
<br><br>> Also, I haven't got success with opposite operation: purging cache (to
<br>> save some filesystem space).
<br><br>You should always have the space for your cache reserved on the disk.
<br>Do not overbook, you will regret.
<br><br>> 5. How can I instruct venus to forget realms?
<br><br>No way besides client reinit.
<br><br>> From here on there are no actual problems. More like random ideas.
<br><br>I guess you find some discussions of similar ideas if you look in the list
<br>archive.
<br><br>> 7. Is it possible to set per-volume quota? Like the hard limit on
<br>> volume size? AFAIK there is only per-user quota which sometimes is not
<br>> enough.
<br><br>The other way around: there is volume quota only, no user quota.
<br><br>> It's really good
<br>> piece of work which I'm sure I couldn't do better in reasonable time.
<br><br>:-) you may find an estimation of what "a reasonable time" for Coda is
<br>at <a href="http://coda.cs.cmu.edu/misc/sloccount.html" target="_top" rel="nofollow">http://coda.cs.cmu.edu/misc/sloccount.html</a><br><br>> Yet the problems are annoying and I can't even use alternative because
<br>> there doesn't exist any! I haven't found another remote filesystem with
<br>> persistent local cache, with the ability to work disconnected.
<br><br>There isn't any, just because it _is_ hard to do right.
<br><br>So if you can live with what Coda looks like now and want to make it better,
<br>join the development. This is not for the faint-hearted, improvements
<br>postulate deep understanding of the concepts and of the code, but may be
<br>you will find this challenge exciting.
<br><br>Best regards,
<br>Rune
<br><br><p>From forum: <a href="http://old.nabble.com/Coda---General-f993.html" embed="fixTarget[993]" target="_top" >Coda - General</a></p>tag:old.nabble.com,2006:post-22048856Re: Google Summer of Code 2009?2009-02-16T15:35:47Z2009-02-16T15:35:47ZBrett LymnOn Mon, Feb 16, 2009 at 11:20:32AM -0500, M. Satyanarayanan wrote:
<br>> That's an interesting suggestion! Would appreciate pointer to
<br>> site.
<br><br>someone provided that.
<br><br>> Also: has anyone on this mailing list had experience as a mentor
<br>> organization? Would appreciate hearing of pros and cons.
<br>>
<br><br>I have been a mentor for SoC for the NetBSD project, participating
<br>since the SoC started.
<br><br>Pros:
<br><br>1) You get people to write code for you, maybe code up that little
<br> project that you thought about but never found the time to do
<br> yourself
<br><br>2) Maybe get more people to help with the coding long term - the idea
<br> of the SoC is to encourage more participation in open source
<br> projects and the ideal outcome is if the paticipants continue on
<br> after the SoC has finished
<br><br>3) Google gives the project a bit of money for each student they
<br> mentor, I guess this really is not so important to Coda.
<br><br>4) Each mentor gets a t-shirt if they fill in the surveys.
<br><br>Cons:
<br><br>1) The students get money which means, unfortunately, there seem to be
<br> a lot of people who attempt to rip the system off by trying to get
<br> accepted for a project and then try to wangle the payments. It is
<br> up to the mentor to agree to the payments but sometimes it can be a
<br> tough call as to whether or not the claims from the student are
<br> genuine or not, especially when you cannot have a face to face
<br> meeting due to distance.
<br><br>2) There is a bit of work involved in making sure your student is on
<br> track and performing.
<br><br>3) You get students to implement your code so making sure it is up to
<br> the right standard sort of rolls into 2 above
<br><br>4) It is rather difficult to scope out a project that is technically
<br> challenging yet small enough to fit within the timeframe of the
<br> SoC. It is also very difficult wading through the proposals and
<br> picking out the one that is likely to succeed from the ones that
<br> have just thrown something in to try and get the cash (yes this
<br> happens)
<br><br>I guess that since most of the Coda developers work at CMU they know
<br>the habits of students so the cons may not be much of a concern -
<br>especially if they can get some of the local students onto a project.
<br><br>If you are seriously considering doing this I suggest you move
<br>quickly, the size of the largess from Google is not boundless so
<br>getting a project slot or two is a matter of making sure you have
<br>sound organisation, reasonable projects and willing mentors. Good
<br>luck.
<br><br>--
<br>Brett Lymn
<br>"Warning:
<br>The information contained in this email and any attached files is
<br>confidential to BAE Systems Australia. If you are not the intended
<br>recipient, any use, disclosure or copying of this email or any
<br>attachments is expressly prohibited. If you have received this email
<br>in error, please notify us immediately. VIRUS: Every care has been
<br>taken to ensure this email and its attachments are virus free,
<br>however, any loss or damage incurred in using this email is not the
<br>sender's responsibility. It is your responsibility to ensure virus
<br>checks are completed before installing any data sent in this email to
<br>your computer."
<br><br><br><p>From forum: <a href="http://old.nabble.com/Coda---General-f993.html" embed="fixTarget[993]" target="_top" >Coda - General</a></p>tag:old.nabble.com,2006:post-22045561Usage problems.2009-02-16T12:17:25Z2009-02-16T12:17:25ZGrzegorz NowakowskiHi Coda-ers ;)
<br><br>I'm new to Coda and to this mailing list so hi again. That said, I've
<br>looked at your project for long time, just couldn't find any to actually
<br>try and use it. Now I've recently deployed small installation in my
<br>home network and got some problems/questions I hope you can help me to
<br>solve.
<br><br>Mind you, I did RTFM (in fact, I did it long before I ever touched Coda
<br>itself). So If something is explained somewhere, just remind me where
<br>it is and I will find it.
<br><br>For reference, the server is based on Atom 1,6GHz with assigned 256MB of
<br>RAM, client is Athlon 2400+ with 1GB of RAM. There is root volume and
<br>there is /home/$user volume, and only the latter is used for data
<br>storage now.
<br><br>1. What is practical maximum volume size, in terms of used space and
<br>number of files?
<br><br>2. What is practical maximum file size to be pushed around?
<br><br>Use case: I have already learned that Coda isn't good choice for filer
<br>with size of hundred gigabytes. I have settled for my /home/$user. It's
<br>about 1,5GB and has about 30k files. Yet even with this amount of data
<br>venus tends to eat more than 80% CPU, clog the system and become totally
<br>unrensponsive. Restarting daemon helps for a while but the problem
<br>returns in few hours, even if Coda filesystem is not touched in the
<br>meanwhile (unless running vcodacon counts).
<br><br>3. Is it possible to manually force volume hoarding and synchronisation?
<br>Preferred is some blocking operation, so that there is known exact
<br>moment when work is finished. Observing vcodacon helps of course but I
<br>found it a bit unreliable.
<br><br>4. Is it possible to verify cache contents? That is, to determine
<br>whether given file/directory is viewed remotely or is taken from local
<br>cache?
<br><br>Use case: I mix laptop to the game. Despite issuing 'hoard add .
<br>100:d+' at the top level of home volume (and keeping it connected for
<br>few hours), after taking laptop somewhere else I have discovered that the
<br>replica was incomplete. A bit annoying, considering that missing were
<br>the very files I intended to work on. What I miss is manual control
<br>over local cache, so I could force and verify synchronisation.
<br><br>Also, I haven't got success with opposite operation: purging cache (to
<br>save some filesystem space).
<br><br>5. How can I instruct venus to forget realms?
<br><br>There are some leftovers from my earlier attempts. They are quite
<br>defunct now so there is no need to be reminded about them.
<br><br><br>From here on there are no actual problems. More like random ideas.
<br><br>6. Have you considered streaming?
<br><br>My current understanding is that if I want to access file it is wholly
<br>copied to the cache in the first place. Which is a bit troublesome when
<br>trying to access big files in this way. Movies for example. In which
<br>case it would be perfectly acceptable to start serving user partial
<br>file, before it's fully downloaded.
<br><br>7. Is it possible to set per-volume quota? Like the hard limit on
<br>volume size? AFAIK there is only per-user quota which sometimes is not
<br>enough.
<br><br>8. The user programs are confusing. Maybe it would be good idea
<br>to supply common frontend to them? Like VCS programs do.
<br><br><br>In general, I have mixed feelings. I really like Coda and despite
<br>problems I have, I'm very far from saying it sucks. It's really good
<br>piece of work which I'm sure I couldn't do better in reasonable time.
<br>Yet the problems are annoying and I can't even use alternative because
<br>there doesn't exist any! I haven't found another remote filesystem with
<br>persistent local cache, with the ability to work disconnected. So I
<br>just can't help quoting Duke Nuk'em: "this really pisses me off". :)
<br><br>Once again, please accept my appreciation of your good work and I hope
<br>it will get even better. Cheers,
<br>--
<br>Grzegorz Nowakowski
<br><br><p>From forum: <a href="http://old.nabble.com/Coda---General-f993.html" embed="fixTarget[993]" target="_top" >Coda - General</a></p>tag:old.nabble.com,2006:post-22040807Re: Google Summer of Code 2009?2009-02-16T08:42:12Z2009-02-16T08:42:12Zu+codalist-wk5rHello Satya,
<br><br>On Mon, Feb 16, 2009 at 11:20:32AM -0500, M. Satyanarayanan wrote:
<br>> That's an interesting suggestion! Would appreciate pointer to site.
<br><br><a href="http://code.google.com/opensource/gsoc/2009/faqs.html" target="_top" rel="nofollow">http://code.google.com/opensource/gsoc/2009/faqs.html</a><br><br>> Also: has anyone on this mailing list had experience as a mentor
<br>> organization? Would appreciate hearing of pros and cons.
<br><br>Unfortunately, not me.
<br><br>Regards,
<br>Rune
<br><br><p>From forum: <a href="http://old.nabble.com/Coda---General-f993.html" embed="fixTarget[993]" target="_top" >Coda - General</a></p>tag:old.nabble.com,2006:post-22041253Re: Google Summer of Code 2009?2009-02-16T08:27:50Z2009-02-16T08:27:50ZFredrik RoubertOn Mon 16 Feb 17:20 CET 2009, M. Satyanarayanan wrote:
<br><br>> Would appreciate pointer to site.
<br><br><a href="http://code.google.com/soc/" target="_top" rel="nofollow">http://code.google.com/soc/</a><br><br>Cheers // Fredrik Roubert
<br><br>--
<br>Teglbrennerveien 7b | +47 41266295
<br>NO-7013 Trondheim | <a href="http://www.df.lth.se/~roubert/" target="_top" rel="nofollow">http://www.df.lth.se/~roubert/</a><br><br><p>From forum: <a href="http://old.nabble.com/Coda---General-f993.html" embed="fixTarget[993]" target="_top" >Coda - General</a></p>tag:old.nabble.com,2006:post-22040223Re: Google Summer of Code 2009?2009-02-16T08:14:05Z2009-02-16T08:14:05ZM. SatyanarayananThat's an interesting suggestion! Would appreciate pointer to site.
<br>Also: has anyone on this mailing list had experience as a mentor
<br>organization? Would appreciate hearing of pros and cons.
<br> -- Satya
<br><br><p>From forum: <a href="http://old.nabble.com/Coda---General-f993.html" embed="fixTarget[993]" target="_top" >Coda - General</a></p>tag:old.nabble.com,2006:post-22034013bleeding edge Coda packages at Aetey2009-02-16T01:26:37Z2009-02-16T01:26:37Zu+codalist-wk5rHello All,
<br><br>for information, the Coda client and server installers at
<br><br> <a href="http://www.aetey.se" target="_top" rel="nofollow">http://www.aetey.se</a> -> Getting Started -> Coda File System HowTo
<br><br> (<a href="http://www.aetey.se/index.php?Static&pg=CodaInstHowto" target="_top" rel="nofollow">http://www.aetey.se/index.php?Static&pg=CodaInstHowto</a>)
<br><br>have been updated to the latest Coda version from git
<br>(on the Valentine's Day :) incorporating some nice bugfixes.
<br><br>For those of you feeling cautious there are also packages corresponding
<br>to the release 6.9.4.
<br><br>To download the 6.9.4 version you have to manually choose the corresponding
<br>binary name, there are no explicit links.
<br>You would need to replace the substring 20090214 in the name with 6.9.4.
<br><br>Enjoy Coda and the installers!
<br><br>Regards,
<br>Rune for Aetey
<br><br><p>From forum: <a href="http://old.nabble.com/Coda---General-f993.html" embed="fixTarget[993]" target="_top" >Coda - General</a></p>tag:old.nabble.com,2006:post-22013585Google Summer of Code 2009?2009-02-14T07:11:40Z2009-02-14T07:11:40Zu+codalist-wk5rHello,
<br><br>I am curious whether the Coda project considered applying for
<br>the Google Summer of Code as a mentor organisation?
<br><br>The deadline this year is in less than a month (on March 13th).
<br><br>Oh and by the way, happy Valentine's Day! :)
<br><br>Cheers,
<br>Rune
<br><br><p>From forum: <a href="http://old.nabble.com/Coda---General-f993.html" embed="fixTarget[993]" target="_top" >Coda - General</a></p>tag:old.nabble.com,2006:post-21873599Re: endianness issues on volume dumps2009-02-06T06:34:39Z2009-02-06T06:34:39Zu+codalist-wk5rHi Greg,
<br><br>On Fri, Feb 06, 2009 at 08:29:02AM -0500, Greg Troxel wrote:
<br>> i386, just for cleanliness. The PDP-11 coda port is going to run into
<br>> trouble on this point, since after all int is 16 bits there. Of course
<br><br>Do you mean the port to 2.11BSD which you worked on back in 2004?
<br>I guess it is tricky to compile Coda on such ancient systems
<br>and hence even harder to keep it up to date? What is its status today?
<br>It's amazing to be able to access Coda even on 16-bit systems.
<br><br>Regards,
<br>Rune
<br><br><p>From forum: <a href="http://old.nabble.com/Coda---General-f993.html" embed="fixTarget[993]" target="_top" >Coda - General</a></p>