[02:40:13] --- haba has become available [06:01:37] --- matt has become available [06:01:54] hi [06:21:31] --- cg2v has become available [07:19:17] --- Russ has become available [07:43:50] --- shadow@gmail.com/owlB6691CF0 has become available [07:47:31] --- mmeffie has become available [08:00:47] --- Derrick Brashear has become available [08:01:16] good morning (or afternoon if you're haba) [08:01:38] good morning [08:02:28] an agenda to bash first [08:02:33] 1) action items from last week [08:02:40] 2) other things which were discovered [08:02:43] 3) what's left [08:03:35] 1) i said we'd deal with aix krb5. i did that, except that like for all other platforms, configure does not yet hardcode defaults for krb5 if you --with-krb5 and don't help it. i'd expect it won't for 1.4.9, simply because testing will be hard [08:03:55] string format for volser and vos is fixed in 1.4 [08:04:15] (data types and string format were fixed in 1.5; the less invasive change is present in 1.4) [08:04:38] dynamic vcache went in, istr after the chat ended [08:05:11] 2) 2 errors at shutdown with freeing memory. all people who reported problems are happy, to my knowledge, but most needed both deltas. [08:05:28] (getting the names, hang on) [08:05:32] --- Simon Wilkinson has become available [08:05:44] cbr-free-what-you-alloc-20090325 [08:05:48] STABLE14-shutdown-vcache-avoid-null-deref-20090324 [08:05:49] shutdown-vcache-avoid-null-deref-20090324 [08:05:59] Ah well. You're as fast. :) [08:06:42] the CopyOnWrite patch from rainer was completely removed. in spite of review and testing it had a problem that was missed. it will not be in this stable (and probably should never have been) [08:06:53] it will ship in 1.5.58 [08:07:26] Cool [08:07:29] we are known to work with the current linux kernel. alas we will miss the start of the next kernel [08:07:55] things which are left [08:08:51] i should confirm that uss is like the other things which can complain about "weird kvnos". garry zacheiss pointed out backup didn't match other things. mike meffie has a patch pending which should fix uss. basically it changes 255 to 256 in ~one file. [08:08:55] this is a negligible change [08:09:28] That seems farily safe. [08:09:31] there's also a pending patch from matt benjamin for *BSD. to the extent it won't touch anything else, we can include that without worry. he's told me that's true [08:09:49] (like, as long as everything is inside ifdef, or in src/*/?BSD) [08:10:46] Yeh. I looked over that. Did we work on *BSD before? [08:10:49] the only other thing i know of is a possible linux hang issue simon is looking at. it's not new. if he comes up with something, we should determine whether it can be fixed, especially if it's simple. otherwise, as far as i can tell, at this point we're just waiting for reports. [08:11:05] 1.4.8 included *BSD support for the first time. [08:11:09] (client) [08:11:32] OpenBSD hadn't worked for a while, I guess the older support 3.6 - 4.1 or so, maybe, was unofficial. [08:11:48] On the Linux hang front, I don't think we should wait for that fix. Nobody's reporting the problem, and any fix is going to have some level of risk. [08:13:05] i agree. but if you happen to find one, and it's simple and obvious, i'd like to take it [08:13:06] On the *BSD front, I've got no problem with shipping the patch if we didn't work there before. If it's changing something that used to work, I'd be nervous taking it at this late stage. [08:13:38] calling our *BSD support previously "robust" would be a stretch. [08:14:20] Open had not been buildable. If it can't break anything else, there's nothing to break in Open itself. Yet. [08:14:45] And it doesn't touch any code used by Free or Net ? [08:15:08] Ne's client doesn't work [08:15:49] No. It adds conditional compilation in iirc rx_knet.c and afs_osi.c and picks up osi_machdep.h in in xdr_arrayn, but other than that, just osi_* stuff. [08:16:10] if you have a path or url we can look at it now [08:16:35] Is it whats in 124541? [08:16:46] [grand.central.org #124541] [08:17:08] ok [08:17:25] I can't recall if my last netbsd patch was orthogonal or not, but there's no point in applying it until I get just a _bit_ further. [08:17:36] Once again I wish RT had a decent diff viewer. [08:18:37] the obsd patch's changes outside OBSD files appear to be to add sysname numbers, and to add ifdefs for or against OBSD code. seems pretty obviously safe [08:19:10] Yes. I'd agree. [08:19:58] Hmm. some old business. Last week I said that VM_FlushPages shouldn't use vmtruncate. That is true. What might not be true is that invalidate_remote_inode is good enough. invalidate_remote_inode is an invalidate_inode_pages replacement, not a truncate_inode_pages replacement. I don't know why FlushPages used truncate_inode_pages, and unless someone does, the change may not be safe [08:23:14] Apparently, for non-disk backed inodes, the difference between truncate_inode_pages and invalidate_inode_pages is that truncate() waits on locked pages, invalidate() doesn't. [08:24:13] linux calls osi_FlushPages in afs_linux_read and afs_linux_mmap; all platforms in afs_open; BOZONLOCK platforms in afs_getattr [08:28:11] (trying to verify what other possibility there migth be for us to call) [08:28:49] I think it depends completely on what we want to do about locked pages when we're flushing. [08:31:02] i think for consistency with other platforms we discard them, but i'm trying to verify that [08:31:38] ugh. invalidate_mapping_pages (as called by invalidate_remote_inode) won't even invalidate unlocked clean pages if they are mapped (in a pagetable). Clearly not what we do elsewhere. [08:32:44] I don't see any interesting locking in vmtruncate. Why do we need to stop calling truncate_inode_pages? [08:33:05] Because of the isize_write updates. [08:33:16] We didn't update that correctly, we raced with pdflush, we lost. [08:33:54] For real truncates or for flushpages? in FlushPages we want the pages gone but the size to stay the same. [08:34:05] That was for real truncates. [08:35:01] for FlushPages (only) we should be able to use truncate_inode_pages. i think. [08:35:22] That sounds reasonable to me, based on what I've just read. [08:37:04] Is the race that pdflush writes stuff back after we've done the truncate on the server, or something more serious? [08:37:21] (should probably take this offline) [08:37:58] discussing it here is fine [08:38:09] is there anything else we need to discuss about release? [08:38:51] I think that's it. I think all of the outstanding RPM packaging bugs that I can fix (ie not the wierd vendor kernel one), are now fixed, so Fedora wise we're good to go. [08:39:12] We have the same problem with GPL-only locks in the Fedora 11 prerelease kernel. I'm hoping they'll turn of LOCK_DEBUG before they ship. [08:39:13] if not, action items are obsd patch, any kvno warning in uss, and linux's osi_VM_FlushPages [08:39:28] and we can then discuss the vmtruncate issue [08:39:32] Hmm. gotta go. [08:39:33] unless someone has something else [08:39:36] have fun [08:39:56] testing? [08:40:14] testing: i am. you should too. [08:40:17] I'd like to request that as people run src/tests they report that [08:40:41] if they need help running it, yell. I'll be happy to fix any bugs in there that are keeping something from running 'out of the box' [08:40:46] can you give me some text i can include in the next candidate announcement? [08:44:18] sure. [08:44:35] I'm on a call atm, but will email to the list. [08:44:38] ie, the release list [08:44:41] thank you [08:45:57] anything else we have to discuss? [08:47:47] hearing none... [08:48:37] hm [08:49:07] i will take the obsd patch (uss patch committed), and after i get text from steven, tag pre3, tell people "only functional change in linux and obsd clients; otherwise it's pre2; test whichever is most convenient for you) [08:49:36] Don't think so. I need to talk to you about toby's Mac OS X stuff (he'd given me build sys integration that I'd failed to pass on), but I don't think that's for 1.4.9 [08:50:08] This is something that can be added to the Linux packaging: How do we prevent folks from putting cache or /vicepX on unsuitable file systems? [08:50:20] We check, don't we? [08:50:42] Yeah, afsd checks. [08:50:48] And blows up if they use a bad file system. [08:50:52] afsd checks [08:51:01] i am unaware which filesystems are unsafe for vicepX [08:51:14] And I'm pretty sure the fileserver does some checking too, that's why stuff had to change for ZFS. [08:51:22] Anything that can't open by inode, right? [08:51:30] Actually, no. That's because ZFS didn't look like a mountpoint. [08:51:32] linux? [08:51:37] open by inode? [08:51:37] Oh, no, that would be the inode file server, not namei. [08:51:40] Sorry. [08:51:40] fileserver? [08:51:42] yeah [08:51:43] ok [08:51:50] i wondered what i missed [08:51:53] Nothing. :) [08:51:57] good! [08:52:00] vicepX: Solaris ufs with logging does not work with inode for sure [08:52:13] jfs om Linux? [08:52:14] We have patches that should let us use anything as a Linux cache partition. But there are some locking issues. [08:52:23] we default away from inode [08:52:38] i am not, at this point, going to integrate code changes for stable release this close to do anything else [08:52:43] so it's not an issue for this release [08:52:55] jfs on linux for fileserver? why not? [08:53:18] No, I don't think any of this is a release issue. We can't fix it in the packaging, anyway - configuration is seperate from packaging, at least on Fedora/RHEL. [08:53:43] --- cg2v has left [08:53:44] jfs on linux for cache might have issues [08:54:02] afsd already does enforcement on linux, so unless you have an active issue, "don't care" [08:54:06] And I'm not mentioning Reiser which has issues everywhere *grin* [08:54:07] afsd rejects everything except ext2 and ext3 on Linux. [08:54:17] I suppose we should add ext4 at some point. [08:54:17] --- stevenjenkins has left [08:54:30] --- cg2v has become available [08:54:53] Although actually the current check may allow ext4. [08:54:57] I'm not sure if the f_type changed. [08:56:21] Today again, time was running away from under me, I might habe some time building stuff on Sunday (for you Saturday night). What archs are not covered yet? [08:56:48] probably hpux things [08:57:08] sorry, no HPUX available [08:57:13] --- stevenjenkins has become available [08:59:10] How is IRIX, I still got _1_ such box running. [09:00:35] i have one. it's slow. [09:00:45] i gotta go [09:01:11] I see, take care. [09:01:37] ciao [09:01:59] (btw: my boss OK:ed this years conference) [09:02:23] --- mmeffie has left [09:03:24] > We have patches that should let us use anything as a Linux cache > partition sounds like a new feature and potentially destabilizing [09:03:39] haba: Excellent! [09:03:45] Well, I wasn't think of them for anywhere other than 1.5.x [09:03:47] and wasn't being talked about for this release [09:03:52] so, boring [09:04:19] anyway,gotta shower, will be back briefly, and then gotta flee [09:04:33] They're not done yet anyway. We deadlock in the kernel with some filesystems. [09:05:35] I think the "anything Linux cache stuff" sounds interresting and I'd like to test it but I can't go to 1.5.x for that, so it would have to be a number of patches for 1.4.X. [09:05:43] and, fwiw, I think Linux does have filesystems that a namei vice partition wouldn't work on, but they're things you wouldn't want to put one on anyway. For example, I'm not sure tmpfs has enough of the mode bits to keep namei happy. [09:06:02] --- mmeffie has become available [09:07:30] To say it the other way round, linux namei works on ext2 (even if you don't _want_ ext2), ext3 and xfs IMHO. [09:10:26] > We deadlock in the kernel with some filesystems I'm mostly interrested in tmpfs [09:18:01] --- mmeffie has left [09:18:50] --- Derrick Brashear has left [09:19:44] --- Russ has left [09:46:35] --- haba has left [10:24:09] --- Simon Wilkinson has left [10:43:22] --- cg2v has left [11:31:18] --- Derrick Brashear has become available [11:31:55] --- Derrick Brashear has left [11:32:30] --- Derrick Brashear has become available [11:33:10] --- Derrick Brashear has left [11:33:18] --- Derrick Brashear has become available [11:33:33] --- Derrick Brashear has left [11:34:53] --- Derrick Brashear has become available [11:38:52] --- Derrick Brashear has left [13:43:24] --- matt has left [15:59:55] --- Simon Wilkinson has become available [22:56:39] --- SecureEndpoints has become available