2008-08-08 00:00 <shapor> btw it was your bug... hg annotate says rev 15 ;)
2008-08-08 01:22 <flips> Fri Aug  8 01:21:43 2008: [11736] tuxopen: no inode 123
2008-08-08 01:22 <flips> Fri Aug  8 01:21:43 2008: [11736] tuxopen: new inode 123
2008-08-08 01:22 <flips> expand inum 291 at 0/0 by 16
2008-08-08 01:22 <flips> :-)
2008-08-08 01:22 <flips> yes it was my bug
2008-08-08 01:22 <flips> subtle indeed
2008-08-08 01:23 <flips> have to check two boundary conditions
2008-08-08 01:30 <shapor> it threw me for a loop at first because it happened right after a split
2008-08-08 01:30 <shapor> so i scrutinized the split code, which of course is flawless :P
2008-08-08 01:50 <shapor> Fri Aug  8 01:49:40 2008: [30550] leaf_insert: Failed assertion "tail >= 0"
2008-08-08 02:48 <flips> hmm
2008-08-08 07:50 -!- tim_dimm(~timothyhu@cpe-76-90-98-247.socal.res.rr.com) has joined #tux3
2008-08-08 09:09 <shapor> flips: i made a new test.. that errors was happening due to a corrupt tree
2008-08-08 09:09 <shapor> after split group with count 1 at 1
2008-08-08 09:10 <shapor> due to one single entry having grouplim entries
2008-08-08 09:10 <shapor> which would never happen if grouplim==255 and we limited snapshots to 255
2008-08-08 11:14 <flips> hi
2008-08-08 11:15 <flips> you mean the new assertion above or the one you just fixed?
2008-08-08 11:15 <shapor> g'mornin
2008-08-08 11:15 <shapor> new one
2008-08-08 11:15 <flips> that sounds good
2008-08-08 11:15 <shapor> the thing i fixed is right
2008-08-08 11:15 <flips> it looked right
2008-08-08 11:16 <shapor> last night i used the #define main trick
2008-08-08 11:16 <shapor> and gave it a few stress tests
2008-08-08 11:16 <shapor> that is the only way it fails
2008-08-08 11:16 <shapor> when a group has one entry which has grouplim entries in it
2008-08-08 11:17 <flips> in other words, more than grouplim different versions
2008-08-08 11:17 <shapor> well no
2008-08-08 11:18 <shapor> er
2008-08-08 11:18 <shapor> it fell out of cache now
2008-08-08 11:18 <shapor> heh
2008-08-08 11:18 <shapor> oh right
2008-08-08 11:18 <shapor> its exactly what i said earlier
2008-08-08 11:19 <shapor> i think
2008-08-08 11:19 <flips> 
ACTION looks for all the things shapor said earlier

2008-08-08 11:19 <shapor> the problem is splitting a group of count 1
2008-08-08 11:19 <flips> obviously useless
2008-08-08 11:20 <shapor> because it has grouplim entries
2008-08-08 11:20 <flips> yes, what I said I thought
2008-08-08 11:20 <shapor> oh, yes, you're right
2008-08-08 11:20 <shapor> we're both right just using different words
2008-08-08 11:20 <flips> good
2008-08-08 11:21 <shapor> sorry i confused yself
2008-08-08 11:21 <shapor> myself*
2008-08-08 11:21 <flips> one "fix" is worth 3 dozen "confuseds"
2008-08-08 11:21 <flips> you're checking in your test?
2008-08-08 11:23 <shapor> sure
2008-08-08 11:32 <flips> short n sweet
2008-08-08 11:33 <flips> fleaf.c because dleaf.c, data leaf
2008-08-08 11:34 <flips> reason is, I want fleaf for the free tree leaf
2008-08-08 11:34 <flips> so: ileaf (inode) dleaf (file data) fleaf (free blocks) aleaf (atimes)
2008-08-08 11:35 <flips> oh, and directory leaf :-/
2008-08-08 11:35 <flips> that is another dleaf
2008-08-08 11:35 -!- tim_dimm(~timothyhu@cpe-76-90-98-247.socal.res.rr.com) has joined #tux3
2008-08-08 11:35 <flips> ah, but that is hleaf
2008-08-08 11:36 <flips> dleaf could also be eleaf, extent leaf
2008-08-08 11:36 <flips> that is better I think
2008-08-08 11:37 -!- pgquiles(~pgquiles@d54C5B8AA.access.telenet.be) has joined #tux3
2008-08-08 11:37 <shapor> maybe use 3 letters instead
2008-08-08 11:37 <shapor> dirleaf
2008-08-08 11:37 <flips> that would fix it
2008-08-08 11:37 <shapor> filleaf
2008-08-08 11:37 <shapor> freleaf
2008-08-08 11:37 <shapor> less confusing
2008-08-08 11:38 <flips> tlaleaf
2008-08-08 11:38 <shapor> heh
2008-08-08 11:38 <shapor> tnaleaf
2008-08-08 11:40 <flips> ileaf (inode table leaf) eleaf (extent tree leaf) fleaf (free extents leaf) aleaf (atime table leaf) dleaf (directory dirent block)
2008-08-08 11:41 <flips> can change our mind a few more times
2008-08-08 11:41 -!- pgquiles_(~pgquiles@d54C5B8AA.access.telenet.be) has joined #tux3
2008-08-08 11:41 <flips> mercurial and git both lack metadata for tracking name changes
2008-08-08 11:41 <flips> suxors
2008-08-08 12:44 -!- pgquiles_(~pgquiles@d54C5B8AA.access.telenet.be) has joined #tux3
2008-08-08 18:25 <flips> "Results 1 - 10 of about 308,000 for tux3"
2008-08-08 18:37 -!- tim_dimm(~timothyhu@cpe-76-90-98-247.socal.res.rr.com) has joined #tux3
2008-08-08 19:06 -!- MaZe(~MaZe@c-24-6-86-168.hsd1.ca.comcast.net) has joined #tux3
2008-08-08 19:52 -!- tim_dimm(~timothyhu@cpe-76-90-98-247.socal.res.rr.com) has joined #tux3
2008-08-08 19:56 <tim_dimm> http://www.linkedin.com/pub/0/a57/305
2008-08-08 22:18 <flips> zfs design docs are really lame
2008-08-08 22:18 <flips> e.g.: http://opensolaris.org/os/community/zfs/structures/;jsessionid=9640F315CA43C6E0BED9C5DAEE2767D2
2008-08-08 22:49 <flips> 
ACTION gives up on finding any complete, coherent zfs design doc