2008-10-01 00:00 I'd think just has easy to redirect each sys_* call to a different inode 2008-10-01 00:00 well I haven't tried it 2008-10-01 00:00 have not looked nearly deep enough to know 2008-10-01 00:01 one day when there's nothing else to do 2008-10-01 00:01 the arrangement does look a little less than elegant 2008-10-01 00:02 kay, time to explain why extents just go so much work 2008-10-01 00:25 flips: is the 16 terabyte limitation for a file a problem ? 2008-10-01 00:25 I can image some situation where a DB might need a file that size or larger 2008-10-01 00:26 yes, it's uncomfortably small at a time where 1TB disks are $100 and it doubles every 18 months 2008-10-01 00:26 let alone storage arrays 2008-10-01 00:27 in six years, $100 will get you 16TB 2008-10-01 00:31 -!- Kirantpatil(~kiran@122.167.192.43) has joined #tux3 2008-10-01 00:32 http://lwn.net/Articles/194869/ <- the original patch for extents in ext4 2008-10-01 00:34 -!- bobby(~bobby@nat-inn.mentorg.com) has joined #tux3 2008-10-01 00:35 hello 2008-10-01 00:35 anyone here? 2008-10-01 00:35 flips: how's tux3 going overall ? well IYO ? 2008-10-01 00:35 hi pranith 2008-10-01 00:35 hello flips 2008-10-01 00:35 it's getting more like a filesystem every day 2008-10-01 00:35 seems like extents were a bitch to pull together, bug fixing and all 2008-10-01 00:36 indeed 2008-10-01 00:36 pranith, I will probably put the fuse ls fix in tomorrow or the next day 2008-10-01 00:36 flips, the groups table and second level entry table are stored in reverse. any reason for that? 2008-10-01 00:36 flips, you found the problem? 2008-10-01 00:37 pranith, no but I will 2008-10-01 00:37 :) 2008-10-01 00:37 ok 2008-10-01 00:37 flips: that implementation looked pretty big and complicated 2008-10-01 00:37 pranith, the groups and entries grow down towards the extent table, therefore it is more efficient to store them in reverse 2008-10-01 00:38 that way, appending a new entry at the end does not require moving all the other entries 2008-10-01 00:38 and the computer doesn't care which way they are stored, only the poor unfortunately programmers who have to try to understand that code 2008-10-01 00:39 i dont understand what u mean by reverse here... 2008-10-01 00:39 the entries are growing from top to bottom 2008-10-01 00:39 yes, I call that reverse 2008-10-01 00:39 hmm 2008-10-01 00:40 isn't that the usual way to do it? 2008-10-01 00:40 top to bottom 2008-10-01 00:40 flips: in general, it's a good thing that all of these file systems are getting development 2008-10-01 00:40 btrfs, ext3 and tux3 2008-10-01 00:40 pranith, I don't know about usual, but btrfs does something similar 2008-10-01 00:40 flips, ohk 2008-10-01 00:40 maybe one of then can get us out of the Linux file system dark ages 2008-10-01 00:40 then=them 2008-10-01 00:40 bh, I am awed by the epic nature of the ext4 extents implementation 2008-10-01 00:41 I am sure there are good reasons for everything 2008-10-01 00:41 flips: it's huge, do you think it needs to be that way ? 2008-10-01 00:41 struct dleaf { u16 magic, free, used, groups;struct extent table[];} 2008-10-01 00:41 well, mine is about 400 lines, maybe has a 100 lines more to go 2008-10-01 00:41 so no 2008-10-01 00:41 maybe they're working around legacy issues or something with that allocator, don't know unless I look at the patch more carefully 2008-10-01 00:42 flips, magic? 2008-10-01 00:42 the magic number is to do an in-memory check that you really have got a dleaf when you think you have 2008-10-01 00:42 ACTION takes a longer look at the patch 2008-10-01 00:42 where are the entries in the dleaf struct? 2008-10-01 00:43 I think the magic number is 0x1eaf 2008-10-01 00:43 i mean u dint use struct group and struct entry there 2008-10-01 00:43 pranith, extents at the bottom of the leaf are indexed by dictionary entries at the top of the leaf 2008-10-01 00:44 ACTION looking at the code 2008-10-01 00:44 a picture would be most helpful 2008-10-01 00:45 anybody good with graphics? 2008-10-01 00:45 flips, ohk, these dict entries are formed in dwalk_probe 2008-10-01 00:45 dwalk_probe does a lookup 2008-10-01 00:46 they are created by dwalk_pack 2008-10-01 00:46 that's for the extent code 2008-10-01 00:46 ok, looking at that 2008-10-01 00:46 the existing pointer code uses dleaf_lookup to find an entry and dleaf_resize to create space for a new one 2008-10-01 00:47 ok 2008-10-01 00:51 oh look, ext4 has an extent walk too: ext4_ext_walk_space 2008-10-01 00:53 and uses the word "gap" 2008-10-01 00:54 bh, I think the reason the ext4 extent code is so long is, it actually includes all the ext4 btree indexing code too 2008-10-01 00:55 I'm looking over the patch right now 2008-10-01 00:55 A good chunk of the complexity is with tree manipulation which you largely have already in your b-tree implementation I believe 2008-10-01 00:56 flips, leaf_free function is a bit confusing.. shouldn't that just return to_dleaf(leaf)->free?? 2008-10-01 00:56 there's an extent merge operation which I don't know yet where it's used and how 2008-10-01 00:56 pranith, no, I used some confusing field names there 2008-10-01 00:57 flips: I didn't see the b-tree stuff in there, but I saw a bunch of stuff that looked like generic tree manipulation, no b-tree 2008-10-01 00:57 flips, whats free for? and whats used for? 2008-10-01 00:57 I'm about 2/5th through so far, nearing the halfway point 2008-10-01 00:57 dleaf->free is the offset within the dleaf of the top of the extents table, dleaf->used is offset of the bottom of the entries list 2008-10-01 00:57 bh, truee 2008-10-01 00:57 the "extent tree" does not appear to be a btree 2008-10-01 00:58 pranith, it's used to know when there is space to add a new extent to the leaf, or if the leaf has to be split 2008-10-01 00:58 hmm 2008-10-01 01:01 leaf->groups contains the number of groups currently in the leaf? 2008-10-01 01:01 yes 2008-10-01 01:02 flips: they have more operations for modifying the extents, but that's about it. It doesn't look that bad regarding complexity 2008-10-01 01:02 -!- _ajonat(~ajonat@190.48.125.115) has joined #tux3 2008-10-01 01:02 does tux3 have similar operations yet ? 2008-10-01 01:02 something like that 2008-10-01 01:02 something more powerful imho 2008-10-01 01:02 flips: I think it's just about general manipulation of file system data structures, nothing more than that 2008-10-01 01:03 looks like 2008-10-01 01:03 it's a lot of code 2008-10-01 01:03 hard to understand the structure in one reading 2008-10-01 01:03 no comments... 2008-10-01 01:03 I think it's just because of it's legacy roots with ext3 which is what this patch is aimed at work around 2008-10-01 01:03 flips: it wasn't hard, you'd be able to get through it in a concentrated day 2008-10-01 01:03 there's only one really large core routine 2008-10-01 01:04 but I got the general idea of what was going on 2008-10-01 01:05 if tux3 uses the b-tree for this already then you don't have to go through the process of "fitting" extents to the disk, etc... 2008-10-01 01:05 and other optimizations with allocation 2008-10-01 01:06 I wonder how they get away with 32 bits for the logical block number of the extent 2008-10-01 01:06 the only worry about tux3 that I have is the lack of kernel support since there's logic manipulation buffer states, ec... 2008-10-01 01:07 the tux3 buffer cache emulation is quite close to the real thing 2008-10-01 01:08 maybe they don't want to have large an extent ? 2008-10-01 01:09 bh, I think they do have a btree in there 2008-10-01 01:09 I saw generic extent manipulation stuff in there 2008-10-01 01:09 no b-tree that I immediately saw 2008-10-01 01:09 there is this notion of an extent cache, I wonder what that is about 2008-10-01 01:10 generally, where you see "path" variables there is a btree 2008-10-01 01:11 and not another on-disk structure ? 2008-10-01 01:13 there are lead manipulation routines but it didnt look like they were manipulating a b-tree 2008-10-01 01:14 +err = ext4_ext_insert_extent(handle, inode, path, &newex); 2008-10-01 01:14 the "inode" parameter makes me think it's against an inode tree instead of a b-tree 2008-10-01 01:17 bh, see ext4_ext_show_path, it's walk a structure that looks much like a btree 2008-10-01 01:17 probing I mean 2008-10-01 01:18 showing 2008-10-01 01:19 it's a very generic routine 2008-10-01 01:19 well look at /* walk through the tree */ 2008-10-01 01:19 it's probing a btree 2008-10-01 01:20 ext4_ext_path 2008-10-01 01:20 What's backing that struct ? 2008-10-01 01:21 blocks 2008-10-01 01:21 It's a path 2008-10-01 01:21 they're written out via mark_buffer_dirty_inode 2008-10-01 01:21 right ? 2008-10-01 01:22 question is what is a path in this code ? 2008-10-01 01:22 that's an in-memory structure 2008-10-01 01:22 just for keeping track of position in the btree 2008-10-01 01:23 no question it's a btree 2008-10-01 01:23 funny that word doesn't appear in the code 2008-10-01 01:23 don't know, I have to stop looking at the path 2008-10-01 01:23 flips: correct 2008-10-01 01:24 ...patch 2008-10-01 01:24 me too 2008-10-01 01:24 that put me in a bad mood ;) 2008-10-01 01:24 too much code 2008-10-01 01:24 it's as big as all of tux3 at the moment 2008-10-01 01:26 http://www.phoronix.com/forums/showthread.php?t=1765 <- fs benchmarks from 2006 2008-10-01 01:26 reiser4 wins apparently 2008-10-01 01:28 actually, if you read it, ext2 wins, and ext4 not far behind 2008-10-01 01:28 marginally beats reiser4 at tar -c and -x 2008-10-01 01:29 kills reiser on delete 2008-10-01 01:29 so to speak 2008-10-01 01:34 hes already dead ;) 2008-10-01 02:07 -!- Kirantpatil(~kiran@122.167.192.43) has left #tux3 2008-10-01 02:25 flips: as long as tux3 has the same kind of stuff you're set 2008-10-01 02:25 or different stuff that works as well or better 2008-10-01 02:26 the goot thing about a b-tree being the center of the universe is that implementations like that can be done in terms of it 2008-10-01 02:26 good 2008-10-01 02:27 which is what you've done 2008-10-01 02:27 it's better to be efficient than to use a brute force method to building a system if possible 2008-10-01 02:28 pretty much need to have a btree in order to have extents 2008-10-01 02:28 ACTION still needs to look at dleaf.c more 2008-10-01 02:29 well, good luck with it 2008-10-01 02:37 ACTION is just about to hit the bed 2008-10-01 02:37 getting late and it's rally hot today/tonight 2008-10-01 02:55 -!- tim_dimm(~timothyhu@cpe-76-90-98-247.socal.res.rr.com) has joined #tux3 2008-10-01 02:55 hey daddy 2008-10-01 02:59 -!- kbingham(~kbingham@193.132.141.186) has joined #tux3 2008-10-01 03:45 -!- pgquiles(~pgquiles@62.43.226.52.static.user.ono.com) has joined #tux3 2008-10-01 04:35 Fire! 2008-10-01 04:35 there goes another tux3 report off into the wild blue yonder 2008-10-01 04:41 flips: from where do you have the numbers? 2008-10-01 04:42 for the comparisons? 2008-10-01 04:42 which ones? 2008-10-01 04:42 ext3 vs tux3 with regard to deletion e.g. 2008-10-01 04:42 simple arithmetic 2008-10-01 04:43 average seek time: 6 ms 2008-10-01 04:43 transfer speed: 64 MB/sec 2008-10-01 04:43 ok, so you calculated it. did you account for the overhead of more complex computations for extents? Or are they nothing to worry about (probably not, regarding how slow disks are) 2008-10-01 04:43 1K pointers/4K block for ext2 comes from the 4 byte pointer size 2008-10-01 04:44 no, I did not add in the cpu overhead 2008-10-01 04:44 but cpu overhead is actually less 2008-10-01 04:44 well, less cases to look at 2008-10-01 04:44 because many simple operations are replaced by one complex operation 2008-10-01 04:45 will you do another post about the extent design? 2008-10-01 04:45 yes 2008-10-01 04:45 maybe tomorrow, maybe later 2008-10-01 04:46 I guess I will get it working the rest of the way first 2008-10-01 04:46 there are still a couple of biggish things to do 2008-10-01 04:46 have to put in the leaf splitting 2008-10-01 04:47 and the actual IO 2008-10-01 04:47 and the extent reading 2008-10-01 04:48 sounds like the better plan. have something to show :) 2008-10-01 04:48 agreed 2008-10-01 04:48 and even better plan: me get some sleep 2008-10-01 04:49 i was just wondering if you were still awake or already 2008-10-01 04:49 still 2008-10-01 04:49 not for very much longer 2008-10-01 04:50 ok. i'll get going too 2008-10-01 04:50 see you 2008-10-01 04:50 bye. 2008-10-01 04:51 -!- bobby(~bobby@nat-inn.mentorg.com) has joined #tux3 2008-10-01 05:33 -!- Kirantpatil(~kiran@122.167.192.43) has joined #tux3 2008-10-01 05:33 -!- Kirantpatil(~kiran@122.167.192.43) has left #tux3 2008-10-01 06:05 flips, congrats on completing(partially even) extents 2008-10-01 06:24 -!- Bobby(~Bobby@nat-inn.mentorg.com) has joined #tux3 2008-10-01 06:25 hello all 2008-10-01 06:57 -!- Kirantpatil(~kiran@122.167.192.43) has joined #tux3 2008-10-01 06:57 -!- Kirantpatil(~kiran@122.167.192.43) has left #tux3 2008-10-01 08:37 -!- RazvanM(~RazvanM@dazzler.isi.jhu.edu) has joined #tux3 2008-10-01 09:38 -!- tim_dimm(~timothyhu@cpe-76-90-98-247.socal.res.rr.com) has joined #tux3 2008-10-01 11:19 -!- tim_dimm(~timothyhu@cpe-76-90-98-247.socal.res.rr.com) has joined #tux3 2008-10-01 11:55 flips: ping 2008-10-01 12:02 -!- pgquiles(~pgquiles@62.43.226.52.static.user.ono.com) has joined #tux3 2008-10-01 12:15 tim_dimm, pong 2008-10-01 12:21 dang- now she's eating again 2008-10-01 12:21 20 minutes 2008-10-01 12:21 life in the daddy zone 2008-10-01 12:24 -!- Bobby(~Bobby@122.162.68.20) has joined #tux3 2008-10-01 12:24 hey all 2008-10-01 12:25 hi pranith 2008-10-01 12:25 hello flips 2008-10-01 12:25 was reading the ext2 chapter 2008-10-01 12:26 from utlk 2008-10-01 12:26 good thing to do 2008-10-01 12:26 its got some great info 2008-10-01 12:26 utlk is pretty good 2008-10-01 12:26 yup, but pretty outdated i guess 2008-10-01 12:26 he says that ext3 still in dev.. 2008-10-01 12:26 :D 2008-10-01 12:27 :) 2008-10-01 12:27 things actually change pretty slowly in kernel 2008-10-01 12:27 I wonder if he covers reverse mapping 2008-10-01 12:27 and rcu 2008-10-01 12:27 don't think either 2008-10-01 12:28 hmm 2008-10-01 12:28 rcu? 2008-10-01 12:28 weird new locking method 2008-10-01 12:28 :( 2008-10-01 12:28 ohk 2008-10-01 12:28 read/copy/update 2008-10-01 12:29 ohk, found this http://lwn.net/Articles/174641/ 2008-10-01 12:30 ACTION is going to miss this place for the next few days 2008-10-01 12:30 :( out on a trip 2008-10-01 12:30 that's a use of rcu 2008-10-01 12:30 by the way 2008-10-01 12:30 hmm 2008-10-01 12:30 next tuesday I will be away 2008-10-01 12:31 oh 2008-10-01 12:31 maybe maze can do it 2008-10-01 12:31 hmm 2008-10-01 12:31 ok 2008-10-01 12:31 should give him some warning 2008-10-01 12:31 time to study up on something ;) 2008-10-01 12:31 okies 2008-10-01 12:31 flips, one thing 2008-10-01 12:31 you've any idea of aio in the current linux system? 2008-10-01 12:32 i tried it today.. 2008-10-01 12:32 yes 2008-10-01 12:32 din't seem to work... 2008-10-01 12:32 is it _properly_ supported now? 2008-10-01 12:32 yes 2008-10-01 12:32 I have a simple demo somewhere 2008-10-01 12:32 glibc uses the kernel implementation?? 2008-10-01 12:33 yes 2008-10-01 12:33 well 2008-10-01 12:33 it's confusing 2008-10-01 12:33 hmm 2008-10-01 12:33 two different interfaces 2008-10-01 12:33 I can never remember which is which 2008-10-01 12:33 and both complex 2008-10-01 12:33 :) 2008-10-01 12:33 ok 2008-10-01 12:33 irritating to use 2008-10-01 12:33 aio is in general irritating 2008-10-01 12:34 hmm 2008-10-01 12:34 what do u suggest if we had to write say 200mb of data 2008-10-01 12:34 and got some processing to do later 2008-10-01 12:34 i think aio would be perfect for this 2008-10-01 12:34 just dump it and continue with your work 2008-10-01 12:35 and finally check the status and wait till it is completed 2008-10-01 12:35 flips: done 2008-10-01 12:35 instead of waiting forever for the data to be written 2008-10-01 12:35 hey tim_dimm 2008-10-01 12:35 done with what? :) 2008-10-01 12:35 pranith, http://groups.google.com/group/zumastor/browse_thread/thread/7b0f5350a99c0d7d/c0bd2f4d698b3ad6?fwc=1 2008-10-01 12:35 hey pranith 2008-10-01 12:36 thnx flips 2008-10-01 12:36 done with feeding my very fussy 3 week old daughter 2008-10-01 12:36 pranith, basically just copied from the aio man page and cleaned up a little 2008-10-01 12:36 okies 2008-10-01 12:39 ok guys, c u on sunday 2008-10-01 12:39 tata 2008-10-01 12:58 Hello :D !!! 2008-10-01 13:09 -!- RazvanM(~RazvanM@dazzler.isi.jhu.edu) has joined #tux3 2008-10-01 13:14 -!- pgquiles(~pgquiles@62.43.226.52.static.user.ono.com) has joined #tux3 2008-10-01 13:43 -!- flips(~phillips@phunq.net) has joined #tux3 2008-10-01 14:18 -!- ajonat(~ajonat@190.48.125.115) has joined #tux3 2008-10-01 14:18 -!- pgquiles(~pgquiles@62.43.226.52.static.user.ono.com) has joined #tux3 2008-10-01 14:20 folks 2008-10-01 14:21 flips: where the anouncement btw ? 2008-10-01 14:21 you might lke to put the update in the topic 2008-10-01 14:25 -!- ChanServ changed mode/#tux3 -> +o flips 2008-10-01 14:25 -!- flips changed topic to "http://tux3.org ~ Tux3 U, right here Tuesdays and Thursdays at 8 p.m. Pacific Time ~ Next session: friends of grab_cache_page" 2008-10-01 14:25 -!- ChanServ changed mode/#tux3 -> -o flips 2008-10-01 14:35 -!- kbingham(~kbingham@92.19.37.221) has joined #tux3 2008-10-01 14:41 flips: tux3 email posting I mean 2008-10-01 14:41 which one? 2008-10-01 14:41 the most recent tux3 update 2008-10-01 14:42 you were up last last nigh 2008-10-01 14:42 night 2008-10-01 14:49 http://tux3.org/tux3 2008-10-01 16:05 -!- pgquiles(~pgquiles@62.43.226.52.static.user.ono.com) has joined #tux3 2008-10-01 16:10 flips : ever decided to put some CMS/CSS :P ? 2008-10-01 16:10 orgthingy, sure, shapor was going to 2008-10-01 16:11 css? 2008-10-01 16:11 if cms, then i really advice to use b2evolution 2008-10-01 16:11 had experience with it in my old bluecirclet.com site 2008-10-01 16:11 we newed DB at bluecirclet.com :( 2008-10-01 16:11 well, it was my partner's fault.. 2008-10-01 16:11 :P 2008-10-01 16:12 check out shapor's site, linked from tux3.org 2008-10-01 16:12 k 2008-10-01 16:12 http://www.totalnetsolutions.net/2007/08/13/how-to-increase-battery-life-in-ubuntu-or-debian-linux/ 2008-10-01 16:12 interesting 2008-10-01 16:13 why is b2evolution better than other php blogging packages? 2008-10-01 16:13 flips : because it was my fav.. i tried many 2008-10-01 16:13 it was probably (one of) best i tried 2008-10-01 16:14 but some like WordPress are fine as well 2008-10-01 16:14 couple of reasons for it being your fav? 2008-10-01 16:19 -!- pgquiles(~pgquiles@62.43.226.52.static.user.ono.com) has joined #tux3 2008-10-01 16:19 ACTION thinks plain text files are the best :P 2008-10-01 16:19 spot the bug, it has been in since forever: 2008-10-01 16:19 int ileaf_check(BTREE, struct ileaf *leaf) 2008-10-01 16:19 { 2008-10-01 16:19 char *why; 2008-10-01 16:19 why = "not an inode table leaf"; 2008-10-01 16:19 if (leaf->magic != 0x90de) 2008-10-01 16:19 goto eek; 2008-10-01 16:19 why = "dict out of order"; 2008-10-01 16:20 if (!isinorder(btree, leaf)) 2008-10-01 16:20 goto eek; 2008-10-01 16:20 return 0; 2008-10-01 16:20 eek: 2008-10-01 16:20 printf("%s!\n", why); 2008-10-01 16:20 return -1; 2008-10-01 16:20 } 2008-10-01 16:20 well 2008-10-01 16:20 I gave it away 2008-10-01 16:20 that's the fixed version 2008-10-01 16:20 if (leaf->magic != 0x90de); 2008-10-01 16:20 goto eek; 2008-10-01 16:20 if (leaf->magic != 0x90de); 2008-10-01 16:20 goto eek; 2008-10-01 16:20 ; ?!? 2008-10-01 16:21 :D 2008-10-01 16:21 nobody noticed, and nobody noticed the error that has been printed out every time make tests is run 2008-10-01 16:22 21 days till I have time for FS again :| 2008-10-01 16:23 what happens then? 2008-10-01 16:23 out of jail? 2008-10-01 16:26 it's pretty 2008-10-01 16:26 I might run it just for laughs 2008-10-01 16:27 better that the crap on tux3.org now 2008-10-01 16:27 thats the best part about bash blogger 2008-10-01 16:27 it just pre renders static html/css 2008-10-01 16:28 so no added security issues either 2008-10-01 16:28 and faster 2008-10-01 16:28 the way it ought to be 2008-10-01 16:29 I noted that 2008-10-01 16:29 plus it has attitude 2008-10-01 16:33 i've been meaning to set it up for the ugly page which is shapor.com 2008-10-01 16:41 shapor : hello 2008-10-01 16:42 has attitude? 2008-10-01 16:42 lol 2008-10-01 16:43 on 22 is the IPSN deadline 2008-10-01 16:44 till then it will be worse and worse :P 2008-10-01 16:44 timewise speaking 2008-10-01 16:45 how come all of you guys are C programmers and know about FS :( 2008-10-01 16:45 no good place to learn C/FS in Middle east 2008-10-01 16:45 no C books in middle east 2008-10-01 16:45 :( 2008-10-01 16:46 I come from Romania ;-) 2008-10-01 16:47 with so much code around a C book it not so useful at it was before 2008-10-01 17:00 flips 2008-10-01 17:00 i was wondering 2008-10-01 17:00 since ext3cow is just FS you wanted 2008-10-01 17:00 but has missing features 2008-10-01 17:00 why dont you just simply make tux3 based on ext3cow ? 2008-10-01 17:01 ipsn? 2008-10-01 17:02 orgthingy, because by the time I finished changing it, it would not resemble ext3 any more at all, and that would be more work than just starting from the beginning 2008-10-01 17:02 for one thing, tux3 does not use a journal 2008-10-01 17:03 i see 2008-10-01 17:03 and the ext3 file index format cannot be adapted for extents, it has to be thrown away and rewritten 2008-10-01 17:03 but little people over here.. do people know what tux3 is 2008-10-01 17:03 ? 2008-10-01 17:03 the list goes on 2008-10-01 17:03 i knew tux3 from stumble-upon 2008-10-01 17:03 basically very little survives 2008-10-01 17:03 i see 2008-10-01 17:04 at least tux3 uses the ext2 directory code 2008-10-01 17:04 for now 2008-10-01 17:05 -!- inverse(~none@h80-net10.simres.netcampus.ca) has joined #tux3 2008-10-01 17:06 flips : how did you get involved in all this opensource project? 2008-10-01 17:06 opensource world* 2008-10-01 17:06 tux2 2008-10-01 17:07 so, tux2 was very first project you were ever involved in? 2008-10-01 17:07 anyway, ext3cow is not the fs I want, I said it is a good project, not that I want to use it myself 2008-10-01 17:07 same goes for btrfs and ext4 2008-10-01 17:08 oh common, ext4 sounds exciting 2008-10-01 17:08 not to me 2008-10-01 17:08 aha ^_^ 2008-10-01 17:10 sk8 oclock 2008-10-01 17:17 http://ipsn.acm.org/2009/ 2008-10-01 17:17 I love the sk8 oclock thing :D 2008-10-01 17:29 flipsout: nice 2008-10-01 17:34 flipsout: have you heard of dmapi ? 2008-10-01 17:34 http://en.wikipedia.org/wiki/XFS#DMAPI 2008-10-01 17:56 shapor, I have 2008-10-01 17:56 permabanned from linux for some unknown reason 2008-10-01 17:56 hrm 2008-10-01 17:57 some people do use it apparently 2008-10-01 17:57 let me take a closer look 2008-10-01 17:58 wow. i've just written the worst code since my first hello world... static allocation of 10000 slots for the free list for the toy os we are coding at university :) 2008-10-01 17:58 but shared mem is supported :) 2008-10-01 17:59 razvanm, good look with your paper then, it's a paper, right? 2008-10-01 17:59 flips: yup 2008-10-01 17:59 ACTION has yet to write his worst code 2008-10-01 17:59 true, the worse code is always ahead ;-) 2008-10-01 17:59 ok, worst code yet :) 2008-10-01 20:04 -!- ajonat(~ajonat@190.48.123.108) has joined #tux3 2008-10-01 20:11 -!- Kirantpatil(~kiran@122.167.213.15) has joined #tux3 2008-10-01 20:11 -!- Kirantpatil(~kiran@122.167.213.15) has left #tux3 2008-10-01 20:18 Question: does Tux3 support file creation dates? I started playing with it today and noticed that everything was set to "1969-12-31 19:00" 2008-10-01 20:24 inverse: yeah, they're just not used by fuse iirc 2008-10-01 20:24 by the tux3fuse program that is 2008-10-01 20:25 ah, that makes sense. I was confused because I saw an email on the list that referred to them being correct :) 2008-10-01 20:30 hmm, there are 2 different fuse implemenations 2008-10-01 20:30 maybe its in one not the other 2008-10-01 20:30 there is tux3fs and tux3fuse 2008-10-01 20:35 yes, now I have it working :) 2008-10-01 20:35