2008-09-03 00:43 konrad, remember I suggested shapor review your code for dleaf ;-) 2008-09-03 00:43 I'm afraid I haven't been as good as reviewer as I could 2008-09-03 00:43 hm? 2008-09-03 00:43 I'm just looking at all the bits of your code I didn't really read ;-) 2008-09-03 00:44 ah that patch was sort of huge glob of stuff 2008-09-03 00:45 int dleaf_ordered(BTREE, struct dleaf *leaf) 2008-09-03 00:45 { 2008-09-03 00:45 struct group *gdict = (void *)leaf + btree->sb->blocksize; 2008-09-03 00:45 struct entry *edict = (void *)(gdict - leaf->groups); 2008-09-03 00:45 tuxkey_t key = 0; 2008-09-03 00:45 --gdict; 2008-09-03 00:45 --edict; 2008-09-03 00:45 for (int group = 0; group < -leaf->groups; group--) { 2008-09-03 00:45 tuxkey_t basekey = (tuxkey_t)gdict[group].loghi << 24; 2008-09-03 00:46 for (int entry = 0; entry < -gdict[group].count; entry--) { 2008-09-03 00:46 tuxkey_t newkey = basekey | edict[entry].loglo; 2008-09-03 00:46 if (key > newkey) 2008-09-03 00:46 return 0; 2008-09-03 00:46 key = newkey; 2008-09-03 00:46 } 2008-09-03 00:46 } 2008-09-03 00:46 return 1; 2008-09-03 00:46 } 2008-09-03 00:46 notice my cavalier attitude towards channel spam ;-) 2008-09-03 00:46 it does less than yours in more lines 2008-09-03 00:46 but it seems to work better 2008-09-03 00:47 looks clear 2008-09-03 00:50 probably complete broken 2008-09-03 00:50 looks ok except you're looking up dict[n] instead of dict[n - 1] 2008-09-03 00:51 which won't work on n = 0 2008-09-03 00:52 the loop inequalities are backwards 2008-09-03 00:52 it sucks ;-) 2008-09-03 00:53 heh 2008-09-03 00:53 these things are a little different than ileafs 2008-09-03 00:53 could just forward loop 2008-09-03 00:53 well 2008-09-03 00:53 to generate the keys it's straightforward 2008-09-03 00:53 generating the offsets is a little trickier 2008-09-03 00:58 ah, a flaw in both of our code 2008-09-03 00:58 you have to keep resetting edict 2008-09-03 00:59 oh? 2008-09-03 00:59 oh, for the current group? 2008-09-03 00:59 I did that 2008-09-03 01:00 I don't see where 2008-09-03 01:00 hm, what are you looking at? 2008-09-03 01:00 http://pastie.org/264980 2008-09-03 01:01 didn't there, right 2008-09-03 01:02 works now 2008-09-03 01:04 cool 2008-09-03 01:04 ok, calculating the offset to make sure that ascends is trickier, we get back into those special zero cases 2008-09-03 01:05 and we have the key generation using just straightforward indexing (though backwards) and the offset generation using demented-off-by-one 2008-09-03 01:05 so there is no pretty way to write it 2008-09-03 01:06 probably the best to is have the dicts one above like before 2008-09-03 01:06 and make the adjustment by one for key lookup, because that is easy 2008-09-03 01:07 and use the same method as for ileaf for the offset generation 2008-09-03 01:07 well 2008-09-03 01:07 hmm 2008-09-03 01:07 dunno 2008-09-03 01:07 like I said, no pretty way 2008-09-03 01:08 it's only the entry->offset that is off by one 2008-09-03 01:08 group->count is directly indexed 2008-09-03 01:08 so mumble 2008-09-03 01:14 ok, this works 2008-09-03 01:14 unsigned members = edict[entry].limit - (entry ? edict[entry + 1].limit : 0); 2008-09-03 01:14 could write "size" instead of members 2008-09-03 01:15 then members is the amount by which we increment base offset 2008-09-03 01:15 by definition positive 2008-09-03 01:15 so it can't go backwards, only too high 2008-09-03 01:15 well, the limits can go backwards 2008-09-03 01:15 I think you checked for that 2008-09-03 01:16 so offset can go backwards too 2008-09-03 01:17 I can write this better 2008-09-03 01:29 struct group *gdict = (void *)leaf + btree->sb->blocksize; 2008-09-03 01:29 struct entry *edict = (void *)(--gdict - leaf->groups); 2008-09-03 01:29 better 2008-09-03 01:30 have the dicts sitting on the zeroth entry for dleaf 2008-09-03 01:32 it's how I wrote it originally 2008-09-03 01:32 yay for convergent evolution 2008-09-03 01:34 :D 2008-09-03 01:34 I'll post mine to the list 2008-09-03 01:34 you can slice and dice as you like 2008-09-03 01:34 it's ever so slightly more readable than the original dump 2008-09-03 01:34 sounds good to me 2008-09-03 01:39 I needed to get that skeleton written anyway, as part of the delte 2008-09-03 01:39 delete 2008-09-03 01:41 I'm probably heading to sleep soon 2008-09-03 01:41 gnight 2008-09-03 01:41 I should likewise 2008-09-03 01:41 night 2008-09-03 01:41 bye 2008-09-03 01:41 heh, is it 2am already? 2008-09-03 01:41 bye 2008-09-03 01:41 yup 2008-09-03 09:51 -!- tim_dimm(~timothyhu@cpe-76-90-98-247.socal.res.rr.com) has joined #tux3 2008-09-03 12:21 hey 2008-09-03 13:18 -!- tim_dimm(~timothyhu@cpe-76-90-98-247.socal.res.rr.com) has joined #tux3 2008-09-03 14:07 bh hi 2008-09-03 14:08 well there is some leaf truncate code 2008-09-03 14:08 icky code 2008-09-03 14:08 but... now onto the btree part of the truncate 2008-09-03 14:09 soon we will be able to delete files and be much more like a filesystem 2008-09-03 14:14 flips: there's a linkedIn group for file system engineers 2008-09-03 14:15 pointer? 2008-09-03 14:15 http://www.linkedin.com/groups?about=&gid=64287 2008-09-03 14:15 is there a group for rollerskating filesystem engineers? 2008-09-03 14:15 did that work? 2008-09-03 14:15 who rollerskates around here? 2008-09-03 14:15 ;-) 2008-09-03 14:24 linkedin customer service sucks 2008-09-03 14:43 yup 2008-09-03 14:46 what's your beef with LinkedIn? 2008-09-03 14:47 bugs 2008-09-03 14:47 tell you about it later 2008-09-03 14:47 k 2008-09-03 14:57 -!- pgquiles(~pgquiles@75.Red-81-44-176.dynamicIP.rima-tde.net) has joined #tux3 2008-09-03 14:59 -!- MaZe(~MaZe@216-239-45-4.google.com) has joined #tux3 2008-09-03 15:03 http://techvideoblog.com/ifa/98-linux-laptop-the-hivision-mininote/ 2008-09-03 15:03 <- $98 linux laptop 2008-09-03 15:03 apparently costs $120 at the moment 2008-09-03 15:03 600 MHz ARM 2008-09-03 15:03 does it blend? 2008-09-03 15:03 right in 2008-09-03 15:03 nice 2008-09-03 15:04 kay, I just have to hook up the good old ddsnap btree deletion to tux3 and we have file delete 2008-09-03 15:46 -!- MaZe(~MaZe@216-239-45-4.google.com) has joined #tux3 2008-09-03 15:52 -!- pgquiles(~pgquiles@75.Red-81-44-176.dynamicIP.rima-tde.net) has joined #tux3 2008-09-03 16:27 -!- tim_dimm(~timothyhu@cpe-76-90-98-247.socal.res.rr.com) has joined #tux3 2008-09-03 17:04 http://www-01.ibm.com/support/docview.wss?uid=swg21230196 2008-09-03 17:05 that must be ancient 2008-09-03 17:05 found that on the LinkedIn File Systems developers group list 2008-09-03 17:05 look like '02 2008-09-03 17:05 Modified date: 2008-09-03 17:05 2007-02-15 2008-09-03 17:05 my bad 2008-09-03 17:05 it's a network filesystem 2008-09-03 17:17 anyone heard of storspeed before? 2008-09-03 17:21 nope, looks like a stealth storage startup in austin 2008-09-03 17:21 flips: the second looks really clear to me 2008-09-03 17:22 the flattened one? 2008-09-03 17:22 yeah 2008-09-03 17:23 glad you like it 2008-09-03 17:23 your interest helped me get going on the delete 2008-09-03 17:25 from what I can gather, storspeed is developing a nfs cache solution 2008-09-03 17:35 ack, just spent a couple hours struggling with btree delete where I did a minor typo in the port from ddsnap 2008-09-03 17:36 well, at least this code can be worked on now 2008-09-03 17:36 unlike ddsnap, where it is buried in a huge system with no unit tests 2008-09-03 17:36 scary 2008-09-03 17:36 good thing it never had a bug 2008-09-03 17:38 heh 2008-09-03 17:38 sk8 oclock 2008-09-03 17:41 getting near the end of the just plain filesystem mechanism stuff 2008-09-03 17:41 some interesting bits coming soon 2008-09-03 17:44 wheel swap before skate 2008-09-03 17:47 that means you're planning to skate? 2008-09-03 17:50 hey 2008-09-03 17:50 should be