[00:51:21] --- reuteras has left [00:58:09] --- haba has become available [01:06:53] --- dev-zero@jabber.org has left [01:32:10] --- dev-zero@jabber.org has become available [01:47:12] --- dev-zero@jabber.org has left [01:47:24] --- dev-zero@jabber.org has become available [03:14:16] --- haba has left [04:57:08] --- haba has become available [04:57:10] --- Jeffrey Altman has become available [05:32:28] --- Derrick Brashear has become available [05:37:42] --- Jeffrey Altman has left [06:01:59] --- reuteras has become available [06:09:38] --- dev-zero@jabber.org has left [06:09:54] --- dev-zero@jabber.org has become available [06:32:55] --- reuteras has left [06:46:28] --- jaltman has left: Disconnected [07:00:06] --- abo has left [07:00:11] --- haba has left [07:01:31] --- deason has become available [07:20:02] --- mho has left [07:20:04] --- Rasmus Kaj has left [07:31:09] --- haba has become available [07:44:56] --- Simon Wilkinson has left [07:45:28] --- haba has left [07:45:32] --- haba has become available [08:04:32] --- mho has become available [08:30:26] can someone tell me what linux kernel versions would be problematic if they were the base for rhel6? [08:30:40] that is, how new is this IMA problem? [08:33:02] I think that depends on the kernel configuration. [08:33:11] Or rather, whether it's a problem at all does. [08:34:33] yes, but I'm assuming it didn't exist until at least sorta-somewhat recently [08:35:15] ah, I thought finding that would be harder; http://linux-ima.sourceforge.net/ says 2.6.30 [08:36:25] Yeah; I'm pretty sure it's not older than that. Certainly it wasn't a problem in August when we started deploying F10 with 2.6.28 kernels. [08:36:43] Of course, I build my own, so it wouldn't have been a problem anyway, but... [08:43:27] part of the problem is that it depends what patches they applied [08:43:44] like, obviously, if they applied the ima patch... [08:45:06] certainly as far as a base kernel ... i assume nothing before 2.6.29 would be affected since istr ima only even popped up during the 2.6.29 cycle. i should go look [08:46:38] yes, the linux-ima site says "new to linux 2.6.30" [08:46:48] whereas (google tells me) it was clearly "in" by .31 [08:47:32] well, i'd say if they used as a base .30, .31 or .32 and it's enabled, we're sad, unless they patch... but they *do* patch. [08:49:03] Of course they patch; they're redhat. Sometimes I think they have more patches than kernel. [08:49:19] The question is, do they patch it _out_ of .30+, or _into_ something older [08:50:36] and how big/invasive/controversial is that mentioned linux patch to fix this that may go in 2.6.33? [08:51:34] controversial is hard to judge [08:52:59] "controversial" to, say, red hat, not linux upstream, if that changes anything for you [08:53:10] I just mean, how hard will it be to advocate for if we need it [08:54:38] well, cynically, a customer who pays redhat decent money probably just needs to say "fix it" [08:55:03] and heeeeeey, looky, here's a patch tht just fell off the back of a truck that does the job! [08:56:01] If only we knew such a customer who cares. [08:56:38] Preferably one who would say "no, fixing it for just us is not good enough; fix it for everyone" [08:57:11] --- zuluchas has become available [08:57:26] --- zuluchas has left [08:57:50] --- clc31 has become available [09:09:09] --- haba has left [09:09:43] --- haba has become available [09:17:52] --- mho has left [09:20:24] --- haba has left [09:20:45] --- haba has become available [09:24:38] --- jaltman has become available [09:27:36] --- haba has left [09:28:17] --- haba has become available [09:33:54] --- haba has left [09:36:33] --- haba has become available [09:41:13] --- Simon Wilkinson has become available [09:42:09] There are two questions [09:42:22] a) Is IMA mature enough that RedHat will commit to it for Enterprise Linux? [09:42:32] b) Will they care about it enough to ensure that it's not broken. [09:43:00] Because the IMA that's in Linus's tree at the moment is broken, both for out-of-tree users of dentry_open, and for a number of in tree users. [09:43:12] Which include fscache, which RedHat definitely have customers using. [09:53:37] Simon, you might want to take a look at src/WINNT/afsd/cm_dir.[hc] [09:55:23] Actually, bits of that are scarily like the new dir API I've been playing with. [09:55:49] In particular, passing the caller the buffer that the entry is in, so we don't have to work backwards from an arbitrary pointer. [09:55:52] I suspect it can be converted fairly quickly to the Unix CM model. It uses a directory operation structure to pass in the vcache info and manage race conditions. Individual directory blocks are processed independently of the chuncksize [09:56:08] --- haba has left [09:56:22] I think you'd probably want to write something that sat under both this and the Unix version. [09:56:41] Remember that the Unix version has to be usable by both the CM and the fileserver, so the 'directory pointer' has to be opaque. [09:57:24] But, actually, much of that code looks like someone's taken the contents of dir/dir.[ch] and done a global search and replace on it. [09:57:25] Being used by both the file server and the cache manager exposes too many internals on the wire. [09:57:50] So, write a directory RPC API. [09:57:57] But at the moment, we don't have any choice. [09:58:13] The only way the cache manager gets to see the directory contents is by fetching them as a file. [09:58:24] Sure [09:58:40] but it doesn't have to be limited to chunksize operations [09:59:21] We're going to have to keep the old directory code around for years to come. We might as well make it work better. [09:59:38] When it comes to code for the new directory stuff then we can start from scratch. [10:01:40] The Windows code split off from the unix dir package because the Windows cache size was limited to 10mb at one point. It couldn't handle reading a full directory into the cache [10:02:07] Yeh, but I think the approach that the Unix code takes is correct. [10:02:16] You have an opaque pointer to a directory object [10:02:27] And a function that you call to read pages out of that object. [10:03:02] That function can then be replaced by something that does 'directory as a whole chunk', 'directory as multiple chunks', or 'directory as a file'. [10:03:21] --- haba has become available [10:03:54] cm_DirGetPage is directly equivalent to the dir package's DRead [10:04:00] (which is that function) [10:05:07] The Windows functions just have a slighly saner approach to buffer page handling. [10:05:26] --- haba has left [10:07:10] the reality is that at present the Windows client must read the entire directory object in order to build the B+Tree [10:08:06] I doubt that we'd actually get much performance gain from having the directory in multiple chunks. You'd always need chunk 0, for example. [10:08:20] The benefit would only really be for memcache, so it doesn't have to reallocate. [10:08:54] if you were using a single file cache, being able to break up the chunk into segments is desirable [10:09:00] I don't actually see there being much benefit in the 'treat the whole cache as a single file' approach. We get the same difficulties if we have to open one file on disk, as if we have to open thousands. [10:11:06] --- haba has become available [10:14:14] in the single file approach it is really hard to avoid fragmentation [10:14:16] the whole cache as one file approach would possibly make us more able to share cache manager code between unix and windows. that's about the only real benefit i can see [10:14:38] --- haba has left [10:14:40] --- haba has become available [10:14:41] --- Rasmus Kaj has become available [10:14:59] --- Derrick Brashear has left [10:15:04] The way I see it is that it's much better to use the existing local fileystems to manage our cache, than it is to try and write our own local filesystem. [10:15:18] We've got our hands full enough maintaining this network filesystem that we've got. [10:15:20] maybe it's just a pipe dream [10:15:44] --- Rasmus Kaj has left [10:15:49] sure, if i wanted to be a local filesystem, i'd look at episode [10:15:50] --- haba has left: Lost connection [10:16:07] I am interested, though, in Rainer's cache manager changes to use the cache chunks from read() and write() [10:16:27] --- haba has become available [10:16:44] --- Rasmus Kaj has become available [10:17:09] yes, i hope he digs that out [10:18:09] It scares me a little, because you're having to switch between two different modes of working (and you _really_ don't want to have a partially populated mapping whilst you're doing direct reads from the disk cache). But I'd like to take a look at the code, and dig around the kernel a bit. [10:20:00] if done wrong there's some real danger, yes [10:21:05] You also need to be really careful about other in-kernel callers that call directly into your read/write pages routines - and what you do if you get hit there, at the same time as you're handling a read() directly. [10:21:47] fraught with peril. i'd like to see his code. course, i'd also like to see where marc went with per-file acls [10:22:04] Yeh. I asked Marc about that a while back. [10:37:50] --- shadow has become available [10:37:53] --- shadow has left [10:38:20] --- shadow has become available [10:38:21] --- shadow has left [11:09:04] Would people prefer that a new DRead (and rest of dir) API looked something like: [11:09:43] int DRead(afs_dir_obj *dir, int pageno, void *obj, afs_dir_page *page); or [11:10:00] struct afs_dir_item{ void *data, afs_dir_page *page }; [11:10:21] int DRead(afs_dir_obj *dir, int pageno, afs_dir_item *item); [11:10:22] ? [11:14:30] --- haba has left [11:45:19] --- Russ has become available [12:51:28] --- clc31 has left [13:06:59] --- clc31 has become available [13:38:45] --- jaltman has left: Disconnected [13:55:38] --- dev-zero@jabber.org has left [15:11:51] --- dev-zero@jabber.org has become available [15:16:14] --- deason has left [15:21:58] --- jaltman has become available [15:24:37] --- jaltman has left: Replaced by new connection [15:24:39] --- jaltman has become available [15:30:13] --- deason has become available [16:07:20] --- dev-zero@jabber.org has left [17:22:28] --- dev-zero@jabber.org has become available [17:32:54] --- Russ has left: Disconnected [17:38:32] --- dev-zero@jabber.org has left [17:38:45] --- dev-zero@jabber.org has become available [17:48:56] --- Russ has become available [19:14:37] --- dev-zero@jabber.org has left [19:29:41] --- clc31 has left [23:22:46] --- dev-zero@jabber.org has become available [23:23:03] --- dev-zero@jabber.org has left [23:23:18] --- dev-zero@jabber.org has become available [23:38:40] --- kula has left [23:42:46] --- deason has left