2008-08-09 00:26 flips: ping 2008-08-09 01:07 shapor, pong 2008-08-09 01:15 maze, hi over here 2008-08-09 01:15 sure, no problem, I've been very busy - what about you? 2008-08-09 01:16 me too 2008-08-09 01:16 I've seen there's a lot of new email in my inbox about tux3 2008-08-09 01:16 and I haven't finished reading all of the old emails... ;-( 2008-08-09 01:16 is there enough tux3 code up now to get out of the "lame no code" category? 2008-08-09 01:16 (I just got back from a 'conference' like 2 days) 2008-08-09 01:17 there are a lot of emails to read 2008-08-09 01:17 particularly the matt dillon series 2008-08-09 01:17 http://kerneltrap.org/Linux/Comparing_HAMMER_And_Tux3 2008-08-09 01:17 depends, ultimately I guess until you have something that works as a filesystem (even if only as a userspace library)... 2008-08-09 01:17 that isn't even all of them 2008-08-09 01:17 it's close to that 2008-08-09 01:17 can open/make an inode now, read/write a file 2008-08-09 01:18 now need to open _then_ read/write 2008-08-09 01:18 and have multiple files 2008-08-09 01:18 not far away 2008-08-09 01:18 then directories... bitmap allocation... 2008-08-09 01:18 deletion... 2008-08-09 01:18 versions... 2008-08-09 01:18 ;-) 2008-08-09 01:19 atomic commit... 2008-08-09 01:19 one of the things that seemed to consistently crop up about filesystems at the meeting I was just at, was that a small amount of flash, to either have the superblock, or all the metadata (possibly including 'small' files) in flash is something desirable 2008-08-09 01:21 for tux3, being able to write the beginning of forward log chains to nvram wouild be nice 2008-08-09 01:21 only a few bytes needed 2008-08-09 01:21 but the commit logging strategy is going to run near media speed I think 2008-08-09 01:22 will get to that in a week or two 2008-08-09 01:22 ..fragmentation... 2008-08-09 01:22 right, there is at least a plan 2008-08-09 01:23 using generating functions to do a quadractic hash-like bounce to successively further away allocation goals 2008-08-09 01:23 meaning that when data does get bounced away from home, different updates get bounced to the same place 2008-08-09 01:23 right 2008-08-09 01:24 also, the logging strategy likes a certain amount of fragmentation 2008-08-09 01:24 this leaves places to store commit blocks at convenient places all over the volume 2008-08-09 01:24 shapor did some killer bug hunting 2008-08-09 01:25 right, I'll really have to read the design docs to get a better feel for all this 2008-08-09 01:26 design doc is essentially the lkml post converted to html 2008-08-09 01:26 shapor talked about adding some of the mailing list posts to it 2008-08-09 01:27 if he doesn't get around to it, I will add some 2008-08-09 01:27 yes, that would be much appreciated 2008-08-09 01:27 the generic btree thing came true 2008-08-09 01:27 works like a charm 2008-08-09 01:27 I haven't been able to be as involved as I would like to be 2008-08-09 01:28 generic as in? 2008-08-09 01:28 both for inodes and file content? 2008-08-09 01:28 as in the same btree code works for the inode table and file indexes 2008-08-09 01:28 and soon will also implement the free map 2008-08-09 01:28 yes 2008-08-09 01:28 and atime table, and directory indexes 2008-08-09 01:28 and I think I will add yet another table, a table of volume roots 2008-08-09 01:29 it's basically trivial to have multiple filesystems share the same allocation space 2008-08-09 01:29 do multiple filesystems really differ from directories in one root? 2008-08-09 01:29 yes, they don't invade each other's directories 2008-08-09 01:42 -!- pgquiles(~pgquiles@d515302CB.access.telenet.be) has joined #tux3 2008-08-09 01:48 -!- pgquiles_(~pgquiles@d515302CB.access.telenet.be) has joined #tux3 2008-08-09 01:51 struct inode *inode = tuxopen(&sb, 0x123, 1); 2008-08-09 01:51 tuxwrite(inode, 6, "hello world", 11); 2008-08-09 01:51 if (tuxread(inode, 6, buf, 11)) 2008-08-09 01:51 return 1; 2008-08-09 01:51 hexdump(buf, 11); 2008-08-09 01:51 works 2008-08-09 01:51 "open by inum" 2008-08-09 01:51 need to make it open by name now 2008-08-09 01:52 6 is the blocknum to write it on... need to make that byte offset and update the size attribute properly 2008-08-09 02:00 -!- pgquiles__(~pgquiles@62.43.226.52.static.user.ono.com) has joined #tux3 2008-08-09 02:05 -!- pgquiles_(~pgquiles@d515302D0.access.telenet.be) has joined #tux3 2008-08-09 02:14 -!- MaZe(~MaZe@c-24-6-86-168.hsd1.ca.comcast.net) has joined #tux3 2008-08-09 02:27 -!- pgquiles__(~pgquiles@d515302D0.access.telenet.be) has joined #tux3 2008-08-09 02:35 -!- pgquiles_(~pgquiles@d515302D0.access.telenet.be) has joined #tux3 2008-08-09 03:42 my rip of ext2/dir.c compiles, I'll test it... later 2008-08-09 06:00 -!- pgquiles(~pgquiles@d515302CB.access.telenet.be) has joined #tux3 2008-08-09 06:04 -!- pgquiles_(~pgquiles@d515302CB.access.telenet.be) has joined #tux3 2008-08-09 06:13 -!- pgquiles__(~pgquiles@62.43.226.52.static.user.ono.com) has joined #tux3 2008-08-09 06:17 -!- pgquiles_(~pgquiles@d515302CB.access.telenet.be) has joined #tux3 2008-08-09 07:39 -!- pgquiles(~pgquiles@d515302CB.access.telenet.be) has joined #tux3 2008-08-09 07:45 -!- pgquiles_(~pgquiles@d515302CB.access.telenet.be) has joined #tux3 2008-08-09 07:54 -!- pgquiles__(~pgquiles@d515302CB.access.telenet.be) has joined #tux3 2008-08-09 07:55 -!- tim_dimm(~timothyhu@cpe-76-90-98-247.socal.res.rr.com) has joined #tux3 2008-08-09 12:07 -!- tim_dimm(~timothyhu@cpe-76-90-98-247.socal.res.rr.com) has joined #tux3 2008-08-09 12:56 -!- tim_dimm(~timothyhu@cpe-76-90-98-247.socal.res.rr.com) has joined #tux3 2008-08-09 14:00 -!- tim_dimm(~timothyhu@cpe-76-90-98-247.socal.res.rr.com) has joined #tux3 2008-08-09 14:36 -!- tim_dimm(~timothyhu@cpe-76-90-98-247.socal.res.rr.com) has joined #tux3 2008-08-09 15:11 -!- tim_dimm(~timothyhu@cpe-76-90-98-247.socal.res.rr.com) has joined #tux3 2008-08-09 16:29 -!- tim_dimm(~timothyhu@cpe-76-90-98-247.socal.res.rr.com) has joined #tux3 2008-08-09 18:21 -!- tim_dimm(~timothyhu@cpe-76-90-98-247.socal.res.rr.com) has joined #tux3