[00:29:31] --- dev-zero@jabber.org has become available [01:44:45] --- stevenjenkins has left [01:44:45] --- mcohan has left [01:44:46] --- stevenjenkins has become available [01:46:00] --- mcohan has become available [02:28:15] --- Russ has left: Disconnected [02:48:56] --- dev-zero@jabber.org has left [03:42:35] --- SecureEndpoints has left: Replaced by new connection [03:48:21] --- dev-zero@jabber.org has become available [03:54:02] --- dev-zero@jabber.org has left: Replaced by new connection [03:54:03] --- dev-zero@jabber.org has become available [06:29:20] --- dev-zero@jabber.org has left [06:31:53] --- SecureEndpoints has become available [07:21:34] Here's an interesting bug. If you open a file, then extend it by lseek() and write()ing into a later chunk, any attempts to write to the earlier chunks require them to be fetched from the fileserver. [07:23:44] that's not shocking actually [07:23:58] It's ruined my day ... [07:24:11] (I don't have a fileserver I can ask for them :-) [07:25:26] I guess whilst disconnected, I need to catch the extend, and handle it in the same way as when ftruncate() extends a file. [07:26:58] the door lock which self-destructed in the back door yesterday in a way which precludes the door from opening will ruin my day today if irc doesn't [07:27:52] I'm not reading IRC at the moment, am I missing out on some fun? [07:28:17] And broken locks do, indeed, suck. Can you drill it out? [07:28:30] oh, the tumbler is already removed. [07:28:55] the bolt somehow destroyed itself in the door [07:29:13] Ah. That's very very unhelpful. [07:29:37] i am 3/4 of the way hacksawed through the bolt [07:30:15] That sounds far too much like hard work! [07:30:28] well, i needed to leave before i could finish [07:30:49] so i left it. i couldn't kick the door in with the hingepins removed, so i wasn't worried about someone breaking in [07:31:11] That's quite some bolt, then. [07:31:24] kwalitee. [07:33:51] Oh well, at least I've now got symlinks going. I should go and do something productive with the rest of the day. [07:35:04] cool. in rt? [07:35:36] Not yet. Muddled in with loads of debugging from trying to find the lseek() bug. [07:35:44] WIll be there shortly. [07:35:57] ok [08:54:28] --- matt has become available [08:54:35] --- matt has left [09:36:52] --- dev-zero@jabber.org has become available [11:09:20] --- summatusmentis has left [11:25:17] --- Russ has become available [11:27:37] --- matt has become available [13:33:56] --- summatusmentis has become available [13:41:20] --- dev-zero@jabber.org has left [14:23:42] --- dev-zero@jabber.org has become available [14:57:02] Gah. I'm really not sure if we should be bothering to lock files on the server before trying to replay disconnected information into them. It just means we have a really bad time if things go wrong. [14:59:46] how so? [15:01:07] You start replaying, you lock the file, you send some data, that connection times out, you unlock that file, but ooops - the server's marked down, so you can't. [15:04:15] hm. well, with current model, it only matters for 5m [15:06:08] Yeh. Still anonying though. [15:06:23] I'm just going to disable the locking until I've had a chance to think about how I can make it better. [15:09:13] (It's not just broken in the releasing locks case, it also doesn't handle the case when it asks for a lock, and doesn't get it) [15:10:04] People are going to love mandatory locking. [15:14:55] For some definition of love :) [15:17:16] Tough love, perhaps [15:37:09] --- matt has left [15:48:28] --- dev-zero@jabber.org has left [17:41:38] I don't think you can usefully make locking work in disconnected mode. Because you're deferring updates done on the disconnected client, you can't actually ensure that no one updates the file between when an application on the disconnected client reads it and when it does an update. The best you can do is detect when someone might have done so. Further, even if, on reconnecting, you determine that no one has touched the file since you disconnected, you still can't guarantee that the replay will be atomic with respect to other users of the file, because you don't know what the locking model is. [17:42:53] In fact, it's actually worse than that -- locking is entirely advisory, and there's nothing that says that a lock has to be tied specifically to updates on that one file. I'm pretty sure our coherency model does allow one to safely use a lock on one file to protect atomic updates on an entire group of files. [18:17:34] matt: I will be sending a long set of comments on the byte range locking draft to the list. I do not think afs should give up the use of lock timeouts. even when it comes to mandatory locking. [19:46:39] --- tkeiser@sinenomine.net/owl has left [20:39:35] --- stevenjenkins has left