[00:34:45] --- dev-zero@jabber.org has become available [04:45:50] --- abo has left [04:45:53] --- abo has become available [05:25:23] --- mvitale has become available [05:46:49] --- dev-zero@jabber.org has left [06:17:40] --- dev-zero@jabber.org has become available [06:18:27] --- dev-zero@jabber.org has left [06:18:33] --- dev-zero@jabber.org has become available [06:21:06] --- deason has become available [07:01:41] --- Roman Mitz has left [07:01:50] --- Roman Mitz has become available [07:06:30] --- dev-zero@jabber.org has left [08:22:32] --- haba has become available [08:24:47] Does the collective brain here have any idea why my vos syncvldb fishburger.stacken.kth.se /vicepa -dryrun -verbose does say ........... Total entries: 513, Failed to process 0, Would change 0 in spite of that I have volumes which are on server but not in vldb? Is that a bug? (vos is version 1.4.14) [08:26:06] --- jaltman has become available [08:26:22] --- jaltman has left: Disconnected [08:47:47] are dafs instances supposed to be created as dafs, rather than fs? [08:48:07] russ' debian doc says bos create fs fs -cmd /usr/lib/openafs/dafileserver ... [08:48:20] as opposed to http://docs.openafs.org/QuickStartUnix/apcs04.html [08:48:21] Oh, that's not right [08:49:21] It needs to be bnode type dafs, and if you want 'bos salvage' to work right, it also needs to be _named_ dafs [08:50:35] The bosserver cares only about the type, but the 'bos' command makes assumptions based on whether bnodes named 'fs' and/or 'dafs' exist. [08:50:42] ... without regard to their type [08:51:00] he may have updated this in a later doc. [08:51:12] so the docs linked above is correct then? [08:51:20] haba, what sort of volumes are on that server but not in the VLDB? Are they normal RW volumes or something else? [08:52:22] Yes, that doc looks right [08:54:16] great, thanks. [08:54:27] --- meffie has become available [08:55:19] where are the fileserver params stored (or can they be accessed via a command)? [08:55:42] stored in BosConfig, accessible by 'bos status -long' [08:56:03] hurrah, thanks. [09:12:50] Normal RW: haba@habanero:~$ vos listvol fishburger.stacken.kth.se /vicepa | grep ftp.free.amd64 ftp.free.amd64 536898091 RW 2353837 K On-line ftp.free.amd64.backup 536898093 BK 2353837 K On-line haba@habanero:~$ vos listvldb ftp.free.amd64 VLDB: no such entry [09:12:58] (and now here dinner) [09:14:06] --- Derrick Brashear has left [09:16:29] vos listvldb 536898091 [09:46:42] --- Derrick Brashear has become available [09:49:26] --- Derrick Brashear has left [09:51:46] --- Derrick Brashear has become available [09:57:40] --- dev-zero@jabber.org has become available [09:58:25] --- dev-zero@jabber.org has left [09:58:26] --- dev-zero@jabber.org has become available [10:00:00] (back from dinner) jhutz: Nope, 536898091 ist not in the VLDB [10:07:23] Yeah, I looked. For me, vos syncvl _with a volume name_ looked like it would create an entry for that volume. Of course, I don't have stacken bits, so I can't try it for real. [10:08:27] I tried with the volume name and it did not. Then I tried the -dryrun without the volume name and it did say "Would change 0". Hmmm [10:09:24] haba@habanero:~$ vos syncvldb fishburger.stacken.kth.se /vicepa ftp.free.amd64 -verbose Processing VLDB entry ftp.free.amd64 ... _______________________________ -- status before -- **does not exist** -- status after -- **no change** _______________________________ ...done entry VLDB volume ftp.free.amd64 synchronized with state of server fishburger.stacken.kth.se partition /vicepa haba@habanero:~$ vos listvldb -name ftp.free.amd64 VLDB: no such entry [10:13:39] Um, that's odd. [10:14:00] I think I can do vos dump ... | vos restore other-server and then vos zap original-server but that does not give an answer what's wrong with vos (because I guess the logic is in vos) [10:15:56] As I have done a lot of vos move today, I think my VLDB itself is not having any problems. [10:16:37] The logic is in vos. And in the code I'm reading, the output you showed is impossible. [10:18:00] This vos is from the Ubuntu package 1.4.14+dfsg-1+ubuntu1 and I can try another vos. Just a moment [10:19:22] The "does not exist" stuff is printed only if createentry is true. If createentry is true, then addvolume lways gets set. If addvolume is true, then modified always gets set. And the "no change" output is printed only if modified is zero. The only ways around this are if something fails partway through, in which case the code that prints "no change" never gets run, or possibly in the ROVOL path, which is a bit more complicated [10:20:39] The relevant code is src/volser/vsprocs.c:CheckVolume() [10:21:01] I suppose it's possible you have a buggy vos [10:21:19] Hm, wow. It does it for me, too. WTF. [10:21:57] I tried an older vos, same result. That was an 1.4.0-rc7 vos [10:22:42] Hm, let me look a moment longer... [10:24:10] --- Derrick Brashear has left [10:27:39] Oh, duh. You can't use a volume name there; that only works if the name is already in the VLDB. Volume names on servers are descriptive; you can't ask the server about a volume with a particular name. If you use a volume ID instead of a name, it should work correctly. [10:30:32] Eh ok, started command. It hang a while just before it printed the dashed line. So: $ vos syncvldb fishburger.stacken.kth.se /vicepa 536898091 -verbose Processing VLDB entry 536898091 ... _______________________________ -- status before -- **does not exist** -- status after -- ftp.free.amd64 RWrite: 536898091 Backup: 536898093 number of sites -> 1 server 101.234.237.130 partition /vicepa RW Site _______________________________ ...done entry VLDB volume 536898091 synchronized with state of server fishburger.stacken.kth.se partition /vicepa haba@habanero:~$ vos listvldb -name ftp.free.amd64 ftp.free.amd64 RWrite: 536898091 Backup: 536898093 number of sites -> 1 server fishburger.stacken.kth.se partition /vicepa RW Site [10:31:09] --- kaduk@mit.edu/barnowl has become available [10:31:10] Some cosmetic error of the server IP as well. [10:32:27] Oh, that's probably been fixed since. [10:33:20] So, to get a volume name from a volume number vos would have to ask for the list of all volumes and then work it out from that? [10:33:49] Eh, _the_other_way_around_ [10:34:02] To get a number from the name .... [10:34:17] To get a number from a name, yes; it would have to enumerate every volume on the server looking for a matching name. [10:34:30] ... and it doesn't do that [10:36:02] Looks like a wanted patch to the vos_syncvldb man page. [10:37:56] (Today I've been doing a lot of cleaning up in the stacken cell. It has been a bit rotten after folks doing vos moves without checking results etc) [10:39:53] --- Derrick Brashear has become available [10:42:17] The long delay is the failing lookup for IP 101.234.237.130 [11:39:11] --- Derrick Brashear has left [11:39:40] --- Derrick Brashear has become available [11:45:41] --- meffie has left [12:19:09] --- jaltman/FrogsLeap has left: Disconnected [12:19:28] --- Derrick Brashear has left [12:22:14] --- jaltman/FrogsLeap has become available [12:22:54] --- Derrick Brashear has become available [12:36:56] --- dev-zero@jabber.org has left [12:39:57] --- mmeffie has become available [12:43:24] --- mmeffie has left [12:43:24] --- mmeffie has become available [12:43:32] --- mmeffie has left [12:43:34] --- mmeffie has become available [12:51:03] --- Derrick Brashear has left [13:22:12] --- haba has left [13:24:59] --- mdionne has become available [13:41:41] --- Roman Mitz has left [14:51:30] --- deason has left [15:18:33] --- mvitale has left [17:02:35] --- dev-zero@jabber.org has become available [17:03:46] --- dev-zero@jabber.org has left [17:03:48] --- dev-zero@jabber.org has become available [17:19:15] --- dev-zero@jabber.org has left [18:12:37] --- mdionne has left [18:13:56] --- jaltman has become available [18:14:09] --- jaltman has left: Disconnected [18:15:28] --- jaltman/FrogsLeap has left: Disconnected [18:15:38] --- jaltman/FrogsLeap has become available [18:39:29] --- jaltman/FrogsLeap has left: Disconnected [18:47:55] --- jaltman/FrogsLeap has become available [18:55:23] --- jaltman/FrogsLeap has left: Disconnected [19:00:02] --- jaltman/FrogsLeap has become available [20:06:35] --- mmeffie has left