[00:07:49] --- Simon Wilkinson has left [00:20:51] --- cclausen has left [01:20:14] --- dev-zero@jabber.org has become available [01:20:19] --- dev-zero@jabber.org has left: offline [01:23:06] --- summatusmentis has left [02:08:05] --- dev-zero@jabber.org has become available [02:08:13] --- dev-zero@jabber.org has left: offline [06:24:58] --- Simon Wilkinson has become available [06:43:56] --- cclausen has become available [06:55:35] --- deason has become available [07:10:45] --- Russ has become available [07:15:47] --- summatusmentis has become available [07:35:36] --- Simon Wilkinson has left [07:49:10] --- summatusmentis has left [07:51:23] --- Derrick Brashear has left [08:04:09] --- Russ has left: Disconnected [08:14:12] --- Derrick Brashear has become available [08:28:00] --- Russ has become available [08:49:29] --- summatusmentis has become available [08:56:33] --- Simon Wilkinson has become available [08:58:45] --- dev-zero@jabber.org has become available [08:58:45] --- dev-zero@jabber.org has left: offline [09:00:48] --- mmeffie has become available [09:11:31] --- matt has become available [09:27:06] --- summatusmentis has left [09:33:14] --- summatusmentis has become available [10:40:48] --- mmeffie has left [10:57:40] --- edgester has become available [10:58:25] would someone please point me at the patch for 1.4.10 that fixes volumes going offline? [11:00:24] One sec. [11:00:48] STABLE14-background-fsync-consistency-issues-20090522 [11:01:35] Is that in RT or should I pull from CVS? [11:01:41] I need the patch file [11:01:53] wdelta will do that. [11:01:56] Let's see. [11:02:15] I'm not familiar with wdelta [11:03:17] http://www.openafs.org/cgi-bin/wdelta/openafs-stable-1_4_x/STABLE14-background-fsync-consistency-issues-20090522 [11:03:36] Sweet, thanks, Russ! [11:04:15] --- Simon Wilkinson has left [11:04:15] --- Simon Wilkinson has become available [11:05:15] Do I need to run "sh regen.sh" after patching? [11:05:21] No. [11:06:34] --- dev-zero@jabber.org has become available [11:06:44] --- dev-zero@jabber.org has left: offline [11:13:51] > for CForeign we would need to implement AFS_Lookup in the fileserver it's currently a stub that just returns EINVAL he's not here so i should mail him, but, jhutz wrote some of the code you need, see hostafs [11:19:52] my school tends ot use exclusively java, what's the java experience needed? [11:19:58] needed for* [11:20:11] when he comes back he can confirm what's meant, but [11:20:21] 1) we have a java afs port that needs love [11:20:30] 2) he probably means gerrit [11:20:41] Actually, not really. I mean hostafs implements that RPC, but what it does is nothing like what the OpenAFS fileserver would need to do, because mostly it's about actually doing a lookup in the specified directory, and the mechanics of that are different. [11:21:10] sure. but it gives a meaningful answer so you can see how it's expected to nteract with a client [11:21:21] Perhaps the one commonality is that you need to treat lookups in directory vnode 0 specially; that's the client asking for the FID of the volume root, so you just return 1.1 [11:38:44] --- edgester has left [11:47:49] if someone has access to hpux 11 and wants to figure out why the post-dafs-era bozo/fsbnodeops.c SEGVs the compiler, please do. i suggest removing portions of the source file until you can isolate the failure [11:53:20] --- Mike Garrison has become available [12:00:51] summatusmentis: What I was meaning is gerrit. We'd like to make some changes, but my Java-fu is weak. [12:08:42] I'd be willing to at least look, I'm not sure how much time I'll have [12:09:07] I do also know people who may have open time this summer who know java, and I might be able to twist their arm to help out [12:23:41] my oldest daughter has some java fu.. [12:24:46] Basically, what we need is a combination of Java Fu, and experience with the Google Web Toolkit. [12:25:36] There are some changes to gerrit that it would be really great to make. Shawn is interested in making 99% of them, but has a huge workload. If we could do the stuff that's important to us, and send it upstream, then that would be good. [12:28:03] I don't know anything about Google Web Toolkit [12:29:10] Yeh. But if you know Java, then that's 50% of the problem solved :) [12:29:53] granted [12:58:17] --- Mike Garrison has left [13:04:24] --- matt has left [13:05:36] --- reuteras has left [13:07:37] --- Derrick Brashear has left [13:14:03] --- Simon Wilkinson has left [13:16:25] --- Russ has left: Disconnected [15:10:12] --- Russ has become available [15:20:40] --- cclausen has left [16:24:17] --- Simon Wilkinson has become available [16:27:25] --- Derrick Brashear has become available [17:16:50] --- Mike Garrison has become available [17:20:02] --- Mike Garrison has left [17:21:32] --- Mike Garrison has become available [17:24:17] --- Mike Garrison has left [17:30:45] --- Derrick Brashear has left [17:38:28] --- Simon Wilkinson has left [17:47:30] --- Russ has left: Disconnected [18:15:34] --- cclausen has become available [18:35:37] --- mdionne has become available [19:09:23] the hostafsd code was helpful - I managed to get a working AFS_Lookup. Now I also need SRXAFS_DFSSymlink if we want symlinks... [19:13:56] the good news is that except for symlinks, a vanilla client (recent 1.5.x) works fine with per-file ACLs on a volume flagged with CForeign [19:14:08] That's actually pretty easy. RXAFS_DFSSymlink does _exactly_ what RXAFS_Symlink does, except that it returns a callback on the newly-created symlink, because apparently a symlink in DFS can change. Since symlinks in AFS are still immutable no matter what interface you use to create them, the openafs fileserver's SRXAFS_DFSSymlink() can simply return a "fake" callback with a very large timeout; you don't even need to record it in the fileserver. [19:15:48] Of course, per-file ACL's bring up interesting questions, like what is the default ACL on a new file. [19:16:05] Ok thanks, that shouldn't be too hard to do [19:16:26] Plus, a dump containing ACL's for non-directory vnodes won't be backward-compatible. I wonder whatever happened to the volume dump format spec. [19:16:41] i assume now that you get a copy of your parent dir ACL [19:17:26] one of the germans wrote up a spec, with a lot of input from me, when they were working on compressed dumps. [19:17:40] I wonder whatever happened to that work [19:17:42] yes, dump/restore is an issue, and what happens when you move from a per-file ACL fileserver to an old one, etc. [19:18:48] Getting a copy of the parent ACL is close enough to right to be pretty reasonable for a prototype. But I think in production you may want something slightly more complex, like some kind of inheritance. [19:19:23] that's a topic for afs3-standardization (which can and should leave some of the details up to the server implementation) and then openafs-devel [19:19:40] so that changing the parent ACL would also change the files' ACL? [19:19:48] I assume you're storing file ACL's by just making the small vnode index have the same format as the large one? [19:19:52] Yeah. [19:20:24] no, I used a separate file that just has the ACLs [19:21:01] Oh, hm. So you can downgrade, if you don't mind losing the per-file ACL metadata. Not a bad idea. [19:21:25] yes. the only change to existing files is an added handle to the per-file ACL data in the volume header [19:21:46] I keep thinking we need to replace the vnode indices with sqlite databases or something, but we worked through some of the practical implications during the OLF hackathon last year, and it's harder than it sounds. [19:21:53] ... which I think an old fileserver will just ignore [19:22:16] Yeah, an older server will just ignore extra stuff at the end of the volume header. [19:24:05] my current format allocates a full ACL per file - this gets large for volumes with lots of files [19:30:37] For a next phase, I'd recommend something where each file has an ACL number in its vnode index entry, and maybe the ACL index entries have ref counts. Plus a special value of the file ACL field that means to use the parent directory ACL. Then you can start using the parent ACL, and COW if either the parent ACL or one of the file ACL's changes. [19:32:47] The case that makes me wonder is if the parent ACL changes and you have a lot of files in that dir, you might need to COW a lot of them [19:33:58] I was also thinking of storing only unique ACLs with ref counts, and some type of hash table to see if an ACL already exists [19:34:04] Oh, no. You copy the parent ACL to a new ACL index entry and change the ACL pointers on all the files in that directory to point to the new entry instead of use-parent. [19:35:01] I'm not sure if I'd spend effort on collapsing ACL's that happen to be the same; the common cases should already result in few entries. [19:35:21] --- edgester has become available [19:37:59] Yes you're probably right, assuming the COW as you described. I'll look at doing something along those lines as a next step. [19:38:28] I wouldn't go much further than that without deciding what the inheritance semantics should ultimately be. [19:43:12] .. and the disk format needs to be well thought out - once it's out there it'll be harder to change [19:43:58] Yeah, that's an issue, because as soon as you propose any change to the on-disk format you risk opening a large can of worms. [19:57:04] well time for me to check out - thanks for the feedback. I think there will many more issues to iron out before this thing is done :) [19:58:57] --- deason has left [19:59:02] --- mdionne has left [19:59:31] --- deason has become available [20:00:21] good luck [20:12:10] --- edgester has left [20:41:47] --- Simon Wilkinson has become available [21:47:33] the spec for the dumps should be in RT. [21:47:42] efenyak@ probably [22:28:44] --- deason has left [22:28:44] --- deason has become available [22:28:59] --- stevenjenkins has left [22:28:59] --- stevenjenkins has become available [23:00:34] --- deason has left [23:15:14] --- Simon Wilkinson has left [23:56:12] --- dev-zero@jabber.org has become available [23:56:13] --- dev-zero@jabber.org has left: offline