2008-08-27 00:42 <flipz> shapor, once it mounts then people will pile on
2008-08-27 00:42 <flipz> people are already interested
2008-08-27 00:42 <flipz> but interested lazy people who do not want to help get it to the point of mounting are uninteresting
2008-08-27 00:49 <shapor> indeed
2008-08-27 00:49 <shapor> flipz, just read your post a couple times, looking at the ext2 along side
2008-08-27 00:50 <shapor> annoying on this 1024x768 laptop display
2008-08-27 00:50 <flipz> a phone?
2008-08-27 00:50 <flipz> inode.c is still pretty braindamaged
2008-08-27 00:51 <flipz> does not yet implement the code in the post
2008-08-27 00:51 <shapor> last checkin was 26 hours ago :(
2008-08-27 00:51 <flipz> oops
2008-08-27 00:51 <flipz> forgot to pull
2008-08-27 00:53 <shapor> also your post didnt get recogized as a response to the previous one
2008-08-27 00:53 <flipz> it wasn't
2008-08-27 00:53 <flipz> should have been
2008-08-27 00:54 <shapor> ah
2008-08-27 00:54 <shapor> saw that it started with "Re:"
2008-08-27 00:54 <shapor> why would you do that?
2008-08-27 00:55 <flipz> pulled
2008-08-27 00:55 <flipz> distracted
2008-08-27 00:55 <flipz> most probably I did reply
2008-08-27 00:55 <flipz> and something messed up
2008-08-27 00:56 <flipz> that's why good archivers have "probably in reply to"
2008-08-27 00:56 <shapor> no the in-reply to header wasn't there
2008-08-27 00:56 <flipz> you can make it all better by incorporing them into design.html ;-)
2008-08-27 00:57 <shapor> yes
2008-08-27 00:57 <flipz> got the subject line from somewhere
2008-08-27 00:57 <flipz> did not type it in by hand
2008-08-27 00:57 <flipz> therefore something screwed up
2008-08-27 00:57 <shapor> it is quite hard actually
2008-08-27 00:57 <shapor> much harder than coding
2008-08-27 00:57 <flipz> cutting and pasting?
2008-08-27 00:58 <shapor> in a cohesive fashion, yes
2008-08-27 00:58 <flipz> or thinking clearly when faced with a bunch of fuzzy rambling design notes?
2008-08-27 00:58 <shapor> :)
2008-08-27 00:58 <flipz> thinking hurts my head too
2008-08-27 00:58 <flipz> try to avoid it whenever possible
2008-08-27 00:59 <shapor> getting that all together would take a whole day of sitting down with it all really
2008-08-27 00:59 <shapor> dont have the time right now :(
2008-08-27 01:00 <flipz> don't get it all together then
2008-08-27 01:00 <flipz> just get one piece of it together
2008-08-27 01:00 <shapor> yeah
2008-08-27 01:00 <flipz> the koreans have a saying: starting is half
2008-08-27 01:00 <shapor> heh
2008-08-27 01:00 <flipz> since the koreans are the masters of lazy, it is important for them to have their motivators all lined up in a row
2008-08-27 01:11 <flipz> there, another commit
2008-08-27 01:11 <flipz> send html ;-)
2008-08-27 01:31 <shapor> heh
2008-08-27 01:37 <flipz> ah, I just realized why the inum allocation goal keeps changing
2008-08-27 01:37 <flipz> because I decided to make it the same as the block allocation goal
2008-08-27 01:37 <flipz> for now
2008-08-27 01:38 <flipz> probably not going to stay that way
2008-08-27 01:38 <flipz> but it is ok to start with
2008-08-27 01:38 <flipz> planned that carefullly then forgot I did it ;-)
2008-08-27 01:38 <flipz> needs a comment
2008-08-27 01:45 <flipz> 	/*
2008-08-27 01:45 <flipz> 	 * For now the inum allocation goal is the same as the block allocation
2008-08-27 01:45 <flipz> 	 * goal.  This gives us a maximum inum density of one per block and
2008-08-27 01:46 <flipz> 	 * should give pretty good spacial correlation between inode table blocks
2008-08-27 01:46 <flipz> 	 * and file data belonging to those inodes provided somebody sets the
2008-08-27 01:46 <flipz> 	 * block allocation goal based on the directory the file will be created.
2008-08-27 01:46 <flipz> 	 */
2008-08-27 01:46 <flipz> will be in I mean
2008-08-27 02:47 <shapor> flipz: http://shapor.com/tux3/shapor-tux3/doc/design.html
2008-08-27 02:47 <flipz> wee
2008-08-27 02:47 <shapor> i've started dropping the pieces in the original post
2008-08-27 02:47 <flipz> ooh, pretty
2008-08-27 02:48 <shapor> growing in to a real doc
2008-08-27 02:48 <flipz> should we check it into the repo yet?
2008-08-27 02:48 <shapor> no, needs a lot more work, an hour ago it was just the 2008-July.txt mailing list archive from your mailman
2008-08-27 02:49 -!- jennyf(~jennyf@ANantes-257-1-135-233.w90-32.abo.wanadoo.fr) has joined #tux3
2008-08-27 02:49 <shapor> although, it is the only copy
2008-08-27 02:49 <shapor> hi jennyf
2008-08-27 02:49 <flipz> there is this too: http://tux3.org/design.html
2008-08-27 02:49 <shapor> yeah i looked at that
2008-08-27 02:50 <flipz> mostly rubbish?
2008-08-27 02:50 <shapor> is it anything more than html-ized lkml post?
2008-08-27 02:50 <flipz> microscopically more
2008-08-27 02:50 <shapor> didn't look like it was
2008-08-27 02:50 <shapor> hm
2008-08-27 02:50 <flipz> there are a few bits
2008-08-27 02:51 <flipz> worth not killing
2008-08-27 02:51 <shapor> i've only done minor editing, removing list like "i forgot to mention this in my original post:"
2008-08-27 02:51 <flipz> the phtree part
2008-08-27 02:51 <shapor> ok
2008-08-27 02:51 <shapor> just keep posting to the list and i'll extract
2008-08-27 02:51 <shapor> ;)
2008-08-27 02:51 <flipz> "new user interfaces"
2008-08-27 02:52 <flipz> other things like inode attributes have been completely superceded I think
2008-08-27 02:52 <flipz> should not take too long to snarf the few bits that aren't treated better elsewhere
2008-08-27 02:53 <flipz> I think it's just the two I mentioned
2008-08-27 02:53 <shapor> ok
2008-08-27 02:54 <shapor> actually, maybe i will make a commit with that in it
2008-08-27 02:54 <shapor> simply because its my only copy
2008-08-27 02:54 <shapor> want to pull it in?
2008-08-27 02:54 <flipz> sure
2008-08-27 02:54 <flipz> just say when
2008-08-27 02:55 <flipz> one quick scan for things that jump out and rip out your eyeballs
2008-08-27 02:55 <shapor> committed
2008-08-27 02:55 <flipz> 
ACTION looks for the pull address

2008-08-27 02:57 <flipz> hg view is a godsend for this process
2008-08-27 02:57 <flipz> I wish it didn't use such an ugly widget set though
2008-08-27 03:01 <shapor> still haven't seen it
2008-08-27 03:01 <shapor> oh btw
2008-08-27 03:01 <shapor> i had the first hg fail today
2008-08-27 03:01 <shapor> my inbox got spammed with cron failures, trying to pull from you was failing
2008-08-27 03:01 <shapor> for 12 hours or so
2008-08-27 03:02 <shapor> when i ran hg pull on the command line, it complained that it needed a lock
2008-08-27 03:02 <flipz> hmm
2008-08-27 03:02 <shapor> there was some stuck hg pull process
2008-08-27 03:02 <flipz> why was the pull failing?
2008-08-27 03:02 <flipz> your side?
2008-08-27 03:02 <shapor> stupidly i killed it
2008-08-27 03:02 <flipz> or mine?
2008-08-27 03:02 <shapor> yeah on my side
2008-08-27 03:02 <shapor> i should have tried to figure out why it was hung before i killed it
2008-08-27 03:03 <flipz> hopefully it will happen again
2008-08-27 03:03 <shapor> yeah, we'll see
2008-08-27 03:04 <flipz> well there it is
2008-08-27 03:05 <flipz> well I wonder if I am going to get my 1 exabyte file in 8 k volume demo for tomorrow
2008-08-27 03:05 <flipz> maybe not
2008-08-27 03:05 <flipz> I'll relax a little on that
2008-08-27 03:06 <flipz> other important stuff is getting done too
2008-08-27 03:06 <shapor> yeah, as long as progress marches on
2008-08-27 03:07 <flipz> I think I will add the logic to round down the inode table split boundaries to multiples of some binary number like 64
2008-08-27 03:07 <flipz> at that point I might have to play the shapor card
2008-08-27 03:07 <flipz> to expunge the bugs
2008-08-27 03:07 <flipz> cuz its a little hairy already
2008-08-27 03:07 <flipz> not a great deal of code, but logic is subtle
2008-08-27 03:08 <shapor> whyd you change your nick
2008-08-27 03:08 <shapor> z mean something special?
2008-08-27 03:08 <flips> huh?
2008-08-27 03:08 <flips> what nick?
2008-08-27 03:08 <shapor> hah
2008-08-27 03:08 <flips> it means the other one was in use
2008-08-27 03:08 <flips> because I went oom and crashed
2008-08-27 03:08 <flips> linux is ugly that way
2008-08-27 03:08 <shapor> eek
2008-08-27 03:09 <flips> without ulimits
2008-08-27 03:09 <flips> happens regularly
2008-08-27 03:09 <flips> sucks
2008-08-27 03:09 <shapor> set ulimits ;)
2008-08-27 03:09 <flips> I don't, because I want to feel that pain
2008-08-27 03:09 <flips> and fix it one day
2008-08-27 03:09 <flips> speaking of feeling pain
2008-08-27 03:09 <flips> watched gladiator all the way through
2008-08-27 03:09 <shapor> buy more ram isn't a solution really
2008-08-27 03:09 <flips> you need to see it
2008-08-27 03:09 <flips> no
2008-08-27 03:09 <shapor> since ff will just eat it up
2008-08-27 03:10 <flips> crap on my system expands to fill all space
2008-08-27 03:10 <flips> crap being mainly firefox
2008-08-27 03:10 <shapor> with all those porn tabs open
2008-08-27 03:10 <flips> yes
2008-08-27 03:10 <flips> pitiful
2008-08-27 03:10 <flips> russion porn tabs, the worst
2008-08-27 03:10 <shapor> so, is windows better for something then... porn?
2008-08-27 03:10 <flips> windows is way worse
2008-08-27 03:10 <shapor> oh wait, russian? than it is worse
2008-08-27 03:11 <flips> I think
2008-08-27 03:11 <shapor> spyware
2008-08-27 03:11 <flips> based on my knowledge of its kernel structure
2008-08-27 03:11 <shapor> hrm true, joelle does have to reboot a lot
2008-08-27 03:12 <flips> the last round of windows kernel development was mainly copying linux 2.6 features
2008-08-27 03:12 <flips> we suck at oom, so they suck worse
2008-08-27 03:12 <flips> funny really
2008-08-27 03:19 <flips> there we go
2008-08-27 03:19 <flips> nice meaty post
2008-08-27 03:19 <flips> on allocation strategy
2008-08-27 03:19 <flips> barely scratched the surface though
2008-08-27 03:20 <shapor> that ones been cooking a while
2008-08-27 03:21 <flips> that post?
2008-08-27 03:21 <flips> wrote it starting a couple hours ago
2008-08-27 03:21 <flips> but yes
2008-08-27 03:21 <flips> been blathering about it a while
2008-08-27 03:53 <flips> valgrind errors in ileaf
2008-08-27 03:53 <flips> must have been there a while
2008-08-27 05:55 -!- pgquiles(~pgquiles@189.Red-81-44-176.dynamicIP.rima-tde.net) has joined #tux3
2008-08-27 07:18 <tim_dimm> you guys had a late night
2008-08-27 07:18 <tim_dimm> talking about russian porn and all
2008-08-27 07:18 <tim_dimm> http://lxr.linux.no/linux+v2.6.26.3/CREDITS
2008-08-27 07:18 <tim_dimm> might be a source of tux3 developers
2008-08-27 07:19 <tim_dimm> flips: when you get a chance, troll that list and mark who's been naughty or nice.  I'll fire off emails to the nice ones
2008-08-27 08:04 <tim_dimm> and another request- I could use a more condensed general description of Tux3 illustrating the main features/benefits. 
2008-08-27 10:16 <flips> tim_dimm, I'll pen something
2008-08-27 10:16 <tim_dimm> question for u
2008-08-27 10:16 <tim_dimm> how would map reduce fit in along with tux3?
2008-08-27 10:16 <tim_dimm> or visa versa
2008-08-27 10:17 <flips> no idea
2008-08-27 10:17 <tim_dimm> lot of discussion about hadoop / map reduce on the cloud computing list
2008-08-27 10:17 <tim_dimm> Maybe shapor knows something about it
2008-08-27 11:45 <shapor> tim_dimm: i don't think hadoop stuff really asks much of the filesystem
2008-08-27 14:46 <flips> So... exabyte file written
2008-08-27 14:46 <flips> with Tux3, an exabyte means an exabyte
2008-08-27 14:47 <flips> not an exabyte less one
2008-08-27 14:51 <flips> [12818] tuxseek: seek to 0xffffffffffffff4
2008-08-27 14:51 <flips> [12818] tuxread: read ffffffffffffff4/c
2008-08-27 14:51 <flips> 0xbfd504a4:  68 65 6c 6c 6f 20 77 6f 72 6c 64 21               "hello world!"
2008-08-27 14:53 <flips> [12843] tuxread: file pos 1000000000000000/c
2008-08-27 14:53 <flips> whoops
2008-08-27 14:54 <pgquiles> flips: have you taken a decision about time resolution?
2008-08-27 14:54 <flips> [12861] tuxread: file pos 1000000000000000
2008-08-27 14:54 <flips> pgquiles, general idea is to go with 48 bits unless somebody jumps up with a use case that has to have more
2008-08-27 14:55 <flips> pgquiles, and 32 bits for atime, using the measures we discussed on the list to avoid breakage
2008-08-27 14:55 <flips> but not set in stone
2008-08-27 14:55 <pgquiles> ext3's 1 second resolution is annoying for some uses
2008-08-27 14:55 <flips> that is too crude, yes
2008-08-27 14:56 <flips> millisecond resolution ought to be good enough for a file
2008-08-27 14:56 <pgquiles> agreed
2008-08-27 14:56 <pgquiles> 0.1 seconds is good enough, IMHO
2008-08-27 14:56 <flips> probably
2008-08-27 14:56 <flips> 1 second not quite
2008-08-27 14:57 <pgquiles> 100ms is NTFS' time resolution and my users are happy with that
2008-08-27 14:57 <pgquiles> we should merge #zumastor and #tux3 in #daniel's :-P
2008-08-27 14:59 <flips> they're pretty separate
2008-08-27 14:59 <flips> for now
2008-08-27 14:59 <flips> at least until tux3 is ready to replicate
2008-08-27 15:29 <flips> ok, now tuxread and tuxwrite return EIO for access about 1 EB
2008-08-27 15:29 <flips> above
2008-08-27 15:43 <flips> mmm potstickers
2008-08-27 20:27 <shapor> flips: minor (L) cleanups and Makefile committed to my repo
2008-08-27 20:32 <flips> I'll pull
2008-08-27 20:48 <shapor> sefault boo
2008-08-27 20:48 <shapor> inode->btree = new_btree(sb, &dtree_ops); // error???
2008-08-27 20:48 <shapor> needs to be handled
2008-08-27 20:49 <shapor> segfault*
2008-08-27 20:54 <shapor> ah this is the real culprit:
2008-08-27 20:54 <shapor> 486         struct buffer *rootbuf = new_node(&btree);
2008-08-27 20:55 <shapor> hmm lots of missing error checking
2008-08-27 21:14 <flips> yup
2008-08-27 21:14 <flips> need to start using ERR_PTR
2008-08-27 21:15 <flips> which allows an errno to be overloaded on a pointer return
2008-08-27 21:15 <flips> used extensively in kernel
2008-08-27 21:16 <shapor> hmm
2008-08-27 21:17 <flips> http://lxr.linux.no/linux+v2.6.26.3/include/linux/err.h#L22
2008-08-27 21:17 <flips> the getblk interface is classic evil
2008-08-27 21:18 <flips> returns NULL if anything goes wrong
2008-08-27 21:18 <flips> so everybody makes up some different random error to report higher
2008-08-27 21:20 <shapor> whats the point of ERR_PTR?
2008-08-27 21:20 <flips> to return an error without adding a new parameter
2008-08-27 21:21 <flips> instead of checking for NULL return you check for IS_ERR
2008-08-27 21:21 <shapor> just changes a type though
2008-08-27 21:21 <shapor> looks quite pointless?
2008-08-27 21:21 <flips> it's how you use it
2008-08-27 21:22 <flips> if (IS_ERR(result = some_function()) return result;
2008-08-27 21:23 <flips> and some_function returns ERR_PTR(ENOMEM) etc
2008-08-27 21:24 <flips> I can never remember if it is supposed to be ERR_PTR(ENOMEM) or ERR_PTR(-ENOMEM)
2008-08-27 21:24 <flips> one of those will cause oopses
2008-08-27 21:24 <shapor> ah i see
2008-08-27 21:24 <shapor> hah
2008-08-27 21:24 <flips> crappy interface actually
2008-08-27 21:24 <flips> but
2008-08-27 21:24 <flips> everything in C is crappy
2008-08-27 21:25 <flips> so it fits
2008-08-27 21:25 <shapor> exceptions yeah
2008-08-27 21:25 <shapor> lack thereof
2008-08-27 21:25 <flips> errno!
2008-08-27 21:25 <shapor> well we should adopt that interface
2008-08-27 21:25 <shapor> if its what we need to kernel port anyway
2008-08-27 21:25 <flips> will make the port easier
2008-08-27 21:25 <flips> yes
2008-08-27 21:25 <flips> you'll see various shouts to myself about that
2008-08-27 21:32 <flips> ERR_PTR is in
2008-08-27 21:38 <shapor> why is DATA_BTREE_ATTR called "root" ?
2008-08-27 21:47 <flips> hmm
2008-08-27 21:47 <flips> because it's the root of a btre
2008-08-27 21:47 <flips> btree
2008-08-27 21:47 <flips> gives the on-disk block that's the root
2008-08-27 21:48 <shapor> wouldn't "data" make more sense though
2008-08-27 21:48 <shapor> in the context of the other attributes
2008-08-27 21:49 <flips> it's a kind of data attribute
2008-08-27 21:49 <flips> one of four kinds
2008-08-27 21:49 <flips> it's btree data
2008-08-27 21:49 <flips> could call it btree, but that's already taken
2008-08-27 21:49 <flips> that is the in-memory version
2008-08-27 21:50 <flips> that has a bunch of extra fields and no endian requirment
2008-08-27 21:51 <shapor> 
ACTION reads the inode attributes post

2008-08-27 21:51 <shapor> which does?
2008-08-27 21:51 <flips> struct btree
2008-08-27 21:51 <flips> like struct inode, it's the cached version
2008-08-27 21:51 <flips> of a btree root
2008-08-27 21:54 <shapor> ah
2008-08-27 22:11 <flips> zzz time