2008-09-04 02:07 -!- pgquiles(~pgquiles@75.Red-81-44-176.dynamicIP.rima-tde.net) has joined #tux3 2008-09-04 03:14 flips: ? 2008-09-04 03:33 bh, hi 2008-09-04 04:49 -!- pgquiles_(~pgquiles@156.Red-83-33-70.dynamicIP.rima-tde.net) has joined #tux3 2008-09-04 04:50 -!- MaZe(~MaZe@c-24-6-86-168.hsd1.ca.comcast.net) has joined #tux3 2008-09-04 05:10 tux3 just learned how to delete 2008-09-04 06:04 -!- MaZe(~MaZe@c-24-6-86-168.hsd1.ca.comcast.net) has joined #tux3 2008-09-04 06:42 whoo! 2008-09-04 10:05 flips: http://kerneltrap.org/Linux/Tux3_Acting_Like_A_Filesystem 2008-09-04 11:07 -!- MaZe(~MaZe@c-24-6-86-168.hsd1.ca.comcast.net) has joined #tux3 2008-09-04 11:38 -!- pgquiles__(~pgquiles@209.Red-81-32-36.dynamicIP.rima-tde.net) has joined #tux3 2008-09-04 12:15 konrad@hopeless test $ echo "Hello tux3 world" > tmp/tux3 2008-09-04 12:15 konrad@hopeless test $ cat tmp/tux3 2008-09-04 12:15 Hello tux3 world 2008-09-04 12:15 FUSE + tux3 2008-09-04 12:19 just for fun :) 2008-09-04 12:20 -!- MaZe(~MaZe@216-239-45-4.google.com) has joined #tux3 2008-09-04 12:20 -!- MaZe(~MaZe@216-239-45-4.google.com) has joined #tux3 2008-09-04 12:20 flips: for when you wake up, ping 2008-09-04 13:01 konrad: oh? 2008-09-04 13:01 i was wondering when someone was going to do that ;) 2008-09-04 13:02 :D 2008-09-04 13:08 it's very much ugly, incorrect, and a hack 2008-09-04 13:14 konrad, pong 2008-09-04 13:15 fuse-tux3, reads/writes sort of 2008-09-04 13:15 :-D 2008-09-04 13:15 using routines basically copied from tux3.c 2008-09-04 13:16 that's what they're for 2008-09-04 13:16 konrad, you are hereby offically annoited the maintainer for the fuse fork 2008-09-04 13:17 ouch 2008-09-04 13:17 :D 2008-09-04 13:18 ok what you probably need most right now is control over the tracing output 2008-09-04 13:18 I was going to turn all the trace(printf( into just trace( 2008-09-04 13:19 and have trace be a real function instead of a macro 2008-09-04 13:20 I wasn't totally serious about fuse-tux3 2008-09-04 13:20 fsck, my typo is now splatted all over the web 2008-09-04 13:20 I wasn't totally serious about tux3 2008-09-04 13:20 heh 2008-09-04 13:21 see my post to the btrfs list 2008-09-04 13:21 "considering the wisdom" 2008-09-04 13:21 so now I know it was a stupidly big job ;-) 2008-09-04 13:21 is that a list worth subscribing to? 2008-09-04 13:21 http://kerneltrap.org/Linux/Tux3_Acting_Like_A_Filesystem 2008-09-04 13:22 mildly interesting 2008-09-04 13:22 mostly meat and potatoes debugging 2008-09-04 13:22 saw that 2008-09-04 13:22 zfs list is more interesting 2008-09-04 13:22 because more bugs ;-) 2008-09-04 13:22 heh 2008-09-04 13:22 I know someone who switched his /home over to fuse-zfs recently 2008-09-04 13:23 but he was on reiser4 before that 2008-09-04 13:23 hardcore 2008-09-04 13:23 perfect crash test dummy for tux3 2008-09-04 13:23 heh, yes 2008-09-04 13:24 get ready to post your fuse hack to lkml I would say 2008-09-04 13:24 pick the 3 worst things about it, fix, then post 2008-09-04 13:25 ehhh 2008-09-04 13:25 1. It exists. 2008-09-04 13:26 that's both a bug and a feature 2008-09-04 13:26 2. It brings tux3 up even with zfs on linux :D 2008-09-04 13:26 sort of 2008-09-04 13:26 haha 2008-09-04 13:27 only basic reads/ writes work 2008-09-04 13:27 just kidding 2008-09-04 13:27 morally even 2008-09-04 13:31 have to say fuse is pretty easy to work with 2008-09-04 13:40 I am ashamed to say I never tried 2008-09-04 13:43 ah, kerneltrap posted my repost without the typo 2008-09-04 13:51 flips: did you see the lvm snapshot merging patch? 2008-09-04 13:52 folks 2008-09-04 13:53 hey bh 2008-09-04 13:53 hey 2008-09-04 13:53 when arey ou oflks going to rock the LInux file systems world ? 2008-09-04 13:53 bah 2008-09-04 13:53 when are you folks going to rock the LInux file systems world ? 2008-09-04 13:53 better :) 2008-09-04 13:53 man my typing if f-ed right now 2008-09-04 13:53 depends on how much sleep flips gets 2008-09-04 13:54 yeah, the sooner the better 2008-09-04 13:54 the more he misses, the closer it comes to linux fs world rocking 2008-09-04 13:54 :-) 2008-09-04 13:54 show folks out of some barbaric crap 2008-09-04 13:54 tim_dimm, that's for the heads up 2008-09-04 13:54 yeah, I was talking to him late last night, he should be up by now 2008-09-04 13:55 thanks I mean 2008-09-04 13:55 my pleasure dude 2008-09-04 13:55 it was convenient I actually check in the patch I was talking about in the post kerneltrap linked 2008-09-04 13:55 when its done, you can sleep ;-) 2008-09-04 13:55 before sleeping 2008-09-04 13:58 -!- eli(~elicriffi@66.249.86.209) has joined #tux3 2008-09-04 13:59 about time to improve the tux3 front page, no? 2008-09-04 13:59 I think the geek chic may be wearing a little thin 2008-09-04 14:00 shapor's site looks pretty good 2008-09-04 14:00 just port that over 2008-09-04 14:00 flips: yeah, reading that online checking post more, lots of details in it 2008-09-04 14:00 shapor? 2008-09-04 14:01 bh, the main point is there 2008-09-04 14:01 that one can accelerate online checking with a small amount of additional metadata, rarely accessed 2008-09-04 14:03 shapor already put up today's press link :-) 2008-09-04 14:03 have you mapped out the cases yet for checking ? 2008-09-04 14:03 other than the basic inode tree integrity stuff ? 2008-09-04 14:05 I thought I did that in the post 2008-09-04 14:05 you mean more detail? 2008-09-04 14:05 yeah, well, in your mind regardless of the docs 2008-09-04 14:05 yes 2008-09-04 14:05 good :) 2008-09-04 14:05 there is the inode level and the directory level 2008-09-04 14:06 because I'm sick of how lame Linux file systems are 2008-09-04 14:06 you have to have a "good" bit on a compartment of the inode level before checking the directory level 2008-09-04 14:06 what about the directory link count ? solved by groups again ? 2008-09-04 14:10 ACTION is still reading the post 2008-09-04 14:11 hi eli 2008-09-04 14:11 shapor, you want to meet eli 2008-09-04 14:12 googler, ex cluster admin 2008-09-04 14:12 maze too 2008-09-04 14:12 ? 2008-09-04 14:13 maze, do you know eli? 2008-09-04 14:13 nope 2008-09-04 14:13 came to the zumastor talk, we hung out after 2008-09-04 14:13 googler alert, aisle 5 2008-09-04 14:13 has got hands on with some interesting stuff, like lustre and redhat gfs 2008-09-04 14:13 hmm, that's not his login name then is it? 2008-09-04 14:14 prolly not 2008-09-04 14:15 hmm, that guy we sat at the whiteboard with? 2008-09-04 14:15 hmm, and where's aisle 5? 2008-09-04 14:16 heh 2008-09-04 14:16 :-) 2008-09-04 14:16 just me being the smartass that I am 2008-09-04 14:16 MaZe, haven't met you yet either 2008-09-04 14:16 you need to 2008-09-04 14:16 two awesome dudes 2008-09-04 14:17 hi 2008-09-04 14:17 in fact now that I think about it, everybody on the channel is awesome ;-) 2008-09-04 14:17 even the bot 2008-09-04 14:17 eli, hi 2008-09-04 14:17 elicriffield@google 2008-09-04 14:17 hey, eli ;-) 2008-09-04 14:17 ah 2008-09-04 14:17 by our mere presence, we are awesome 2008-09-04 14:17 flips: yeah, I was about to suggest using some kind of centralize reverse map metadata file of some sort 2008-09-04 14:18 the bot is obviously the most awesome, by virtue of being here the longest 2008-09-04 14:18 focusing on early mounting is the end goal here 2008-09-04 14:18 the sooner it can be done the better 2008-09-04 14:19 Maze: :-) 2008-09-04 14:19 so maybe using delayed freeing or something like for deletion until enough of the disk has been verified so that you know it's safe to do so without crushing something would be good 2008-09-04 14:19 basically the normal stuff 2008-09-04 14:20 hi eli 2008-09-04 14:20 hey 2008-09-04 14:20 problem here is that it's kind of wacky for a Unix/Linux style system to groke 2008-09-04 14:20 bh, not sure the reverse makes sense as a file... maybe 2008-09-04 14:20 grok 2008-09-04 14:20 actually maybe that could be good 2008-09-04 14:20 flips: well you have it as something else 2008-09-04 14:20 if the reverses can be fixed size 2008-09-04 14:20 so you can directly index the reverse of a block 2008-09-04 14:21 the thing about it is it'll be small 2008-09-04 14:21 get a token into some other structure 2008-09-04 14:21 and easily verified by a simple inode integrity check 2008-09-04 14:21 well, then you can map it into the page cache 2008-09-04 14:21 decending downward 2008-09-04 14:21 downward? 2008-09-04 14:21 you can special case it and not worry about aliasing, etc... 2008-09-04 14:21 inode->indirect->data 2008-09-04 14:21 the normal stuff 2008-09-04 14:22 aliasing=multiple references 2008-09-04 14:23 bh, I'm going to refresh the online check doc and add it to the design mix 2008-09-04 14:23 got to be thought about from early 2008-09-04 14:23 because you'll have only one per voluem and it's special cased 2008-09-04 14:23 right 2008-09-04 14:23 right, which is why I'm mentioning it to you 2008-09-04 14:23 going to drop the multivolume wanking 2008-09-04 14:23 so you have considered a lot of things beforehand and not deadend your project 2008-09-04 14:24 from a design point of view 2008-09-04 14:24 it's a simple solution for a difficult to track and reproduce data structure, could be too simplistic, you're the fs expert here not me 2008-09-04 14:25 in the online cheker code, it'll have to be one of the first metadata files to check other than the allocation map 2008-09-04 14:27 bh, I think it's about as simplistic as necessary 2008-09-04 14:28 it would be wrong to bog down the fs with a topheavy structure just for fsck 2008-09-04 14:29 it's just an idea 2008-09-04 14:29 I wasn't rejecting 2008-09-04 14:29 hugs? 2008-09-04 14:29 just pointing out that it's not necessary for the required persistent structure to be complex 2008-09-04 14:29 sure, like I said, it's just an idea 2008-09-04 14:30 so what's necessary is to reintroduce a notion of allocation groups 2008-09-04 14:30 the same could apply for not so frequent reverse mappings as well, there still has to be an ordering issue to be considered at mount/check time 2008-09-04 14:30 and record any pointers that cross those groups 2008-09-04 14:31 ordering? 2008-09-04 14:31 the good thing about having it as a file is that it can be easily checked in a single file 2008-09-04 14:31 yeah mount check ordering 2008-09-04 14:31 still don't get it 2008-09-04 14:31 you want to be able to moun this volume asap 2008-09-04 14:32 exactly 2008-09-04 14:32 but you need a certain set of metadata checked first 2008-09-04 14:32 that's why all checks are incremental 2008-09-04 14:32 whether or not it's consistent or not 2008-09-04 14:32 very little is checked before it stops 2008-09-04 14:32 starts 2008-09-04 14:32 not much more than the sb magic number 2008-09-04 14:32 tux3 already checks magic numbers on inode table leaves and file index leaves by the way 2008-09-04 14:32 well, what about checking the bare minimal metadata before you can mount it ? what is that ? 2008-09-04 14:33 1) allocation map 2008-09-04 14:33 respectively 0x90de and 0xc0de 2008-09-04 14:33 2) some random reverse map 2008-09-04 14:33 ... 2008-09-04 14:33 what else ? 2008-09-04 14:33 list it 2008-09-04 14:33 that's my suggestion 2008-09-04 14:33 no checking before mount ;-) 2008-09-04 14:33 well, ok 2008-09-04 14:33 incremental checking starts as soon as root dir is opened 2008-09-04 14:34 don't you want your b-tree checked before doing something with it ? 2008-09-04 14:34 it gets checked on the fly 2008-09-04 14:34 the btree code has to be written not to oops even if you feed it random numbers 2008-09-04 14:34 what about other metadata like the allocation map ? 2008-09-04 14:34 also checked on the fly 2008-09-04 14:34 what if you have a corruption in the b-tree ? how are you going to deal with that ? 2008-09-04 14:35 ext2/3 work like this and it is very effective 2008-09-04 14:35 or a corruption in the allocation map ? 2008-09-04 14:35 except they don't do the only the fly fsck 2008-09-04 14:35 corruption detected in the btree... means a scan for lost leaves has to occur 2008-09-04 14:35 and eio on that file until it's complete 2008-09-04 14:35 maybe 2008-09-04 14:37 just had a thought 2008-09-04 14:37 we could have a special log item every now and then that just duplicates some throwaway copies of the top few levels of the inode btree 2008-09-04 14:37 these structures rarely change 2008-09-04 14:38 its quiting time for me, i'll be back, good seeing you again flips and maze 2008-09-04 14:38 so when they do, just invalidate that log item 2008-09-04 14:39 flips: can we please support front truncation of files? 2008-09-04 14:39 maze, I am writing a post about that right now ;-) 2008-09-04 14:39 among other things 2008-09-04 14:39 oh, awesome 2008-09-04 14:39 "the long and short of truncation" 2008-09-04 14:39 sparse checking should be easy 2008-09-04 14:39 do you mean, actually moving data forward logically, or just punching a hole in the front? 2008-09-04 14:39 it's been my belief that appendable front truncatable files are the best 2008-09-04 14:40 because unaligned front truncation is nasty 2008-09-04 14:40 no, freeing blocks from the front, if it's unaligned then you end up with a full block, with some bytes 'unused' 2008-09-04 14:40 right, and you leave the logical addresses untouched? 2008-09-04 14:41 by logical you mean from the point of view of the apps? yes, they just see zeroes there, if they seek, but opening the file would preferably (probably not doable, since this is vfs) seek to the first 'used' byte 2008-09-04 14:42 right, that's exactly what I'm implementing 2008-09-04 14:42 this would be just awesome for any sort of logging 2008-09-04 14:42 there's a big comment in the code about how deficient my first cut truncate function is in that respect ;-) 2008-09-04 14:42 otherwise the vfs would need a patch to seek to non-free byte first 2008-09-04 14:43 http://tux3.org/tux3?fd=b64615fb8a11;file=user/test/dleaf.c 2008-09-04 14:43 my belief is large files should be immutable, front-truncatable, appendable 2008-09-04 14:43 front truncation is not an option in tux3 2008-09-04 14:43 versioning requires it 2008-09-04 14:44 heh 2008-09-04 14:44 "hole punch" is the usual term 2008-09-04 14:44 there's a nasty little corner case with extents 2008-09-04 14:44 punch a hole in the middle of an extent, the metadata expands 2008-09-04 14:45 unlike all other hole punches 2008-09-04 14:45 punch a hole in the middle of a versioned extent and braindamage is a clear and present danger 2008-09-04 14:49 hole punch is a telecine term 2008-09-04 14:49 hole punching is different - because you can do it in the middle of files 2008-09-04 14:49 that's why we like it 2008-09-04 14:49 that also has a usecase 2008-09-04 14:50 what is the difference between a hole punch at the beginning of a file and a front truncate? 2008-09-04 14:51 just had a thought: it would be nice to have an ioctl to return the first "present" offset in a file, for log reading 2008-09-04 14:51 offset padded down to block boundary with zeros 2008-09-04 14:52 then that exabyte upper limit actually makes sense 2008-09-04 14:52 it could be conceivable to actually hit that one day 2008-09-04 14:52 and have to rotate ;-) 2008-09-04 14:56 news item: msft browsers lose just .5 more share to non-msft then it will be a market share tie on w3schools 2008-09-04 14:56 meaning half the people learning about html as learning it with a non-msft browser 2008-09-04 14:57 just had a thought: it would be nice to have an ioctl to return the first "present" offset in a file, for log reading -> precisely, I'd envision that to be the default location when you open such a file 2008-09-04 14:57 hah! 2008-09-04 14:57 nice 2008-09-04 14:57 open(...O_FRONT); 2008-09-04 14:58 loc padded down to block boundary 2008-09-04 14:58 pos I mean 2008-09-04 14:58 and aligned I mean 2008-09-04 14:59 everybody missed my pun on tree chopping so far 2008-09-04 14:59 btree_chop 2008-09-04 15:00 veritable paul bunyan 2008-09-04 15:00 I suppose that's because I didn't spell it that way 2008-09-04 15:00 currently leaf_chop, I have to change it 2008-09-04 15:07 tim_dimm, you now have a commit dedicated to you 2008-09-04 15:07 http://tux3.org/tux3 2008-09-04 15:07 the paul bunyan commit? 2008-09-04 15:07 flips: online checking the most important and igored things I know of in most file systems today 2008-09-04 15:07 that one yes 2008-09-04 15:07 bh, ignored no longer 2008-09-04 15:07 my first commit dedication- I'm touched 2008-09-04 15:07 I'll get a post together in the next couple of days 2008-09-04 15:08 flips: by you or folks in the general community ? 2008-09-04 15:08 I'll also start thinking about relative block pointers 2008-09-04 15:09 could get some excellent compression that way 2008-09-04 15:09 also code complexity ;-) 2008-09-04 15:09 because I think its the best stop gap measure we have so far for petabyte volumes 2008-09-04 15:09 bh, by the tux3 community 2008-09-04 15:09 yeah, thanks ;) 2008-09-04 15:09 I'm so glad somebody listens to me 2008-09-04 15:09 because this is a critical problem 2008-09-04 15:09 we'll always be here for you ;-) 2008-09-04 15:10 probably the most important problem for file systems as this moment followed by snapshots 2008-09-04 15:10 :) 2008-09-04 15:10 one of them, true 2008-09-04 15:10 I just hope that I'm being useful in these discussions 2008-09-04 15:10 just plain bugginess is probably the number one problem 2008-09-04 15:10 affects reiser4, zfs, btrfs 2008-09-04 15:10 maybe not hammer 2008-09-04 15:11 and maybe that is because I'm just not reading the bug reports 2008-09-04 15:11 I suspect it's just plain "not hammer" 2008-09-04 15:14 bh: just curious. what's your day gig? 2008-09-04 15:15 (pardon my curiosity) 2008-09-04 15:16 flips, after return 0;, how about a print "TIMBER" 2008-09-04 15:16 good call 2008-09-04 15:16 well 2008-09-04 15:17 we want to chop the tree, not bring down the system ;-) 2008-09-04 15:17 it's really tree_disintegrate 2008-09-04 15:17 tim_dimm: Novell's R&D group 2008-09-04 15:17 gotcha 2008-09-04 15:17 I'm mostly a concurrency person with the -rt patch 2008-09-04 15:17 mr locking 2008-09-04 15:17 how about writing "timberrrr" on the _error exit_ to chop tree? 2008-09-04 15:17 locking instrumentation specifically 2008-09-04 15:18 and -rt conversion of the kernel to be fully preemptible 2008-09-04 15:18 bh is going to test his locking intrumentation on tux3 2008-09-04 15:18 ok, I'm thinking... what next 2008-09-04 15:18 nice 2008-09-04 15:18 pretty much me and Ingo are the only two folks on this planet to have made some attempt and map out the problem space for that 2008-09-04 15:18 and I'm am awfully close to saying, kernel port 2008-09-04 15:18 but it's ingo's patch 2008-09-04 15:18 -rt that is 2008-09-04 15:18 I think it's kernel port next 2008-09-04 15:19 first a little cleanup of the current source 2008-09-04 15:19 not much cleanup 2008-09-04 15:19 we're going to do a proper fork for the kernel I think 2008-09-04 15:19 too hard to make a lot of the code match 2008-09-04 15:19 we'll see 2008-09-04 15:19 tim_dimm: but I'm ex-netapp WAFL 2008-09-04 15:19 bh does a good job of not telling me any secrets ;-) 2008-09-04 15:19 mostly as a sustaining engineer which the vast majority of that kind of work there 2008-09-04 15:19 oh wow 2008-09-04 15:20 yeah, so I've seen what an enterprise file system should look like roughly and Linux is far far behind that 2008-09-04 15:20 agreed 2008-09-04 15:20 as one of the guilty parties 2008-09-04 15:20 bh: I'm bizdev at MetaRAM 2008-09-04 15:20 what is that ? 2008-09-04 15:20 thus the _dimm part 2008-09-04 15:20 big memory 2008-09-04 15:20 metaram is cool 2008-09-04 15:21 fred weber, former cto of amd's startup 2008-09-04 15:21 double the ddr2 limit 2008-09-04 15:21 so you're an engineer or a business person ? 2008-09-04 15:21 and ddr3 2008-09-04 15:21 biz with an ear for engineering 2008-09-04 15:21 and why are you here btw ? 2008-09-04 15:21 bizdev for flips 2008-09-04 15:21 roller skate instructor 2008-09-04 15:21 right flips? 2008-09-04 15:21 yup 2008-09-04 15:21 I consult 2008-09-04 15:21 our biz is sk8ing 2008-09-04 15:22 zen of sk8biz 2008-09-04 15:22 used to be at violin memory 2008-09-04 15:22 that's where we met 2008-09-04 15:22 right 2008-09-04 15:22 1/2TB of DRAM used as storage 2008-09-04 15:22 tim_dimm: eh ? 2008-09-04 15:22 now you can cram that 1/2TB into a server 2008-09-04 15:22 violin is a ssd startup 2008-09-04 15:22 I'm just wondering what your interest here is as a non-engineer, seems odd 2008-09-04 15:23 uh, kinda hard to articulate in one line 2008-09-04 15:23 and I'm suspicious of business folks in general as a rule :) 2008-09-04 15:23 well, I'm interested 2008-09-04 15:23 you could be an EMC mole of some sort or something 2008-09-04 15:23 :) 2008-09-04 15:23 my role here is tux3 evangelism 2008-09-04 15:23 no, i just skate fast 2008-09-04 15:24 no mole action 2008-09-04 15:24 so you're in LA with flips ? 2008-09-04 15:24 yup 2008-09-04 15:24 venice 2008-09-04 15:24 ah ok 2008-09-04 15:24 nice ot know 2008-09-04 15:24 to know 2008-09-04 15:24 bh, tim_dimm is learning C 2008-09-04 15:24 u? 2008-09-04 15:24 among other things 2008-09-04 15:24 bh, from the biggest C slackers on the block 2008-09-04 15:24 just a random angry kernel dude 2008-09-04 15:25 akd 2008-09-04 15:25 apparently angry enough to be a Solaris kernel engineer according to them :) 2008-09-04 15:25 rakd 2008-09-04 15:25 tim_dimm is learning C about the same rate I'm learning skating 2008-09-04 15:25 gee, hope so 2008-09-04 15:25 bh, I used to be in post production as an online editor and colorist 2008-09-04 15:25 I wonder how big a bribe sun would offer for me to work on zfs ;-) 2008-09-04 15:26 I'd be happy to 2008-09-04 15:26 what got me into technology was i/o bottlenecks 2008-09-04 15:26 start: rm * 2008-09-04 15:26 oh really 2008-09-04 15:26 ? 2008-09-04 15:26 and abandon tux3 ? 2008-09-04 15:26 depends on the size of the bribe 2008-09-04 15:26 uncompressed 4k digital cinema is 48MB per frame, 1.2GB/s 2008-09-04 15:26 you're doing well at Google and happy right ? 2008-09-04 15:26 ACTION has his price 2008-09-04 15:26 ok 2008-09-04 15:26 nice to know that you have a price 2008-09-04 15:26 good thing it's open source hmm 2008-09-04 15:27 can't take it back now 2008-09-04 15:27 it's unlikely that they'll give you that bribe unless they're in need of something for that NetApp/Sun lawsuit 2008-09-04 15:27 don't you think that tux3 would be a better file system ? 2008-09-04 15:28 bh: did you ever read flips' ramback, faster than a speeding bullet post? 2008-09-04 15:28 bh, of course it will 2008-09-04 15:28 tux3 will have about 1/10th the cache footprint of zfs 2008-09-04 15:28 which is a major source of bugs for them 2008-09-04 15:29