[00:25:51] --- reuteras has become available [00:43:31] --- dev-zero@jabber.org has left [01:21:24] --- haba has left [01:43:31] --- dev-zero@jabber.org has become available [02:57:13] --- Jeffrey Altman has left: Replaced by new connection [03:41:35] --- shadow@gmail.com/owl7BB801BA has left [05:21:58] --- shadow@gmail.com/owl56156058 has become available [05:44:57] --- haba has become available [05:54:45] --- mmeffie has become available [06:04:54] --- Jeffrey Altman has become available [06:29:43] --- matt has become available [06:56:41] --- deason has become available [08:20:04] Is there any feedback on !AFS_64BIT_CLIENT UKERNEL? Is that a param bug? [08:22:29] in src/config/param.linux26.h it looks like AFS_64BIT_ENV should be set when UKERNEL is set [08:22:48] and that's not the define you're talking about [08:22:51] huh [08:22:52] right [08:24:54] I don't think it's ever set for ukernel; I would assume it was added after people cared about ukernel that much, and didn't add it [08:25:06] shouldn't it compile whether or not 64BIT_CLIENT is on? [08:26:24] it should indeed, so that is a defect, but deferring discussion on that, why would it not be on for this subtarget? [08:27:14] my guess is, nobody's thought to try it [08:28:33] russ wanted to look at more of the patches in that set before discussing the compile problem. I think it probably will need a change, but for all I know, felix has fixed it by now. [08:30:49] so you'd vote for me switching 64BIT client in UKERNEL where we would in the kernel client? [08:32:59] I'd vote for not turning it on unless you can test it [08:35:48] well presumably I should test it. but isn't it wrong? [08:37:10] as regards testing, I recall you sent a change to mount a UKERNEL client with fuse. did that get committed? [08:38:34] no [08:38:49] ukernel has not been actively maintained. it doesn't compile in many environments. I spent a bit of time on it once and have a sandbox full of fixes to make it compile. I never finished. Andrew did more recent work which is sitting on tickets in RT. [08:38:54] I can give you a version with that in, but I haven't ported it to newer versions yet [08:39:03] that would be great. [08:39:31] (deason) [08:39:47] the 64BIT preprocessor symbols were created during a time period when ukernel was not actively maintained. As a result I would not expect it to know about them. [08:39:49] and the stuff sitting in tickets in RT shoudn't be bothered with; I have newer things, but I'm trying to get them in better shape before submitting [08:40:18] email? [08:40:52] one sec [08:41:24] jeffrey: understood [09:33:42] andrew: regarding zfs. it doesn't use a single allocation size for files. it has pools of different size blocks which are allocated based upon the expected size of the file and availability. zfs is also copy-on-write for everything and due to its replication and reliability properties will always use more disk space than the size of the data. For example, if the file block pools are 4k, 128k, 1M and there are only blocks available in the 1M pool, than a 1byte file will take up a minimum of 1M of space. If the zpool consists of three physical disks, there may be three copies of the block created. In which case the allocated space is 3M. Finally, due to copy-on-write, both the current version and the prior version of the affected block will be active on disk at the same time. Which means that block could require 6M [09:40:34] requires 6M, but it's only transient, right? [09:40:51] and for "based upon the expected size of the file", is there a way to force that? [09:41:49] don't know [09:41:52] if we could tell zfs "this file will never ever grow larger" it might be helpful, though we'd be lying to it [09:42:16] the problem in the trucation case is that the file already was larger [09:44:29] yes, it's certainly reasonable for it to assume in the general case that it will grow again; but it's an optimization, we shoukd be able to turn it off [09:45:04] its a property of the copy on write semantics of the file system. [09:46:30] it definitely is possible to reclaim that space, though; you create a new file and clobber the old one [09:46:47] sure. that is bypassing the copy-on-write behavior [09:52:31] --- kula has left [09:52:46] I don't think much can be done using the posix interface. take a look at libzfs and see what is that can be used. [10:09:04] --- kula has become available [10:35:52] --- haba has left [10:59:35] --- Russ has become available [11:04:30] --- dev-zero@jabber.org has left [11:09:01] --- reuteras has left [11:16:23] --- haba has become available [12:12:28] --- dev-zero@jabber.org has become available [14:18:45] --- Simon Wilkinson has become available [15:18:09] --- dev-zero@jabber.org has left [15:41:35] --- deason has left [15:44:43] --- deason has become available [19:12:54] --- matt has left [22:21:37] --- Jeffrey Altman has left [22:31:16] --- Jeffrey Altman has become available [23:29:06] --- deason has left [23:34:31] --- dev-zero@jabber.org has become available [23:34:36] --- dev-zero@jabber.org has left: offline