2008-08-19 00:04 test for swap was the wrong direction 2008-08-19 00:06 Results 1 - 10 of about 217,000 for tux3 2008-08-19 00:07 time to show some results then 2008-08-19 00:10 ah, there is another bug 2008-08-19 00:10 I also decided to have the leafbuf be the last element in the tree path instead of handled separately 2008-08-19 00:10 that means it is released by brelse_path 2008-08-19 00:11 but tree_expand needs to store it in the path and doesn't 2008-08-19 00:17 hey flips 2008-08-19 00:17 it was nice meeting up with you Friday 2008-08-19 00:17 that was fun 2008-08-19 00:17 when are you up in la, ever? 2008-08-19 00:18 when I'm speeding through in my VW to head to Mountain View 2008-08-19 00:18 I'm going to do it again later on this week for Burning Man 2008-08-19 00:18 well feel free to slow down for a pit stop 2008-08-19 00:19 yeah, now that I know it's that easy to hook up with you folks, yeah 2008-08-19 00:19 maybe do that for a fuel stop or something like that. 2008-08-19 00:19 btw, LA's club scene is a bit weird, haven't figured it out yet 2008-08-19 00:19 ACTION chill's with Goth/Industrial folks 2008-08-19 00:19 haven't been to a club in la 2008-08-19 00:19 daddy thing does that 2008-08-19 00:20 in the SF area that's actually a professional nerd scene 2008-08-19 00:20 I did goth while in berlin 2008-08-19 00:20 my wife really got into it 2008-08-19 00:20 the previous ATM maintainer is a significant DJ in that scene 2008-08-19 00:20 some MIT Media Lab folks, etc... 2008-08-19 00:20 got some nice pics of us gothing 2008-08-19 00:20 oh really, funny 2008-08-19 00:20 you and wli should get together then :) 2008-08-19 00:20 ah wli 2008-08-19 00:20 he's more of that S&M type, I just like the music 2008-08-19 00:20 wow didn't know 2008-08-19 00:21 harald welte is a serious goth 2008-08-19 00:21 oh yeah, big time dude 2008-08-19 00:21 ran into him in a goth club in berlin, we both said what are you doing here 2008-08-19 00:21 disproportionate engineering and science folks are goth 2008-08-19 00:21 haha 2008-08-19 00:21 that's funnny 2008-08-19 00:21 my ex is a material scientist and love stuff like Joy Division and stuff 2008-08-19 00:21 small world 2008-08-19 00:22 yeah, folks in the SF scene know who I am for the most part, but not what I do per se 2008-08-19 00:22 they knew me when I was starting to complain about how irritating NetApp was and stuff ;) 2008-08-19 00:23 bitched me out when NetApp filed a lawsuit against Sun :) 2008-08-19 00:23 funny 2008-08-19 00:25 netapp should just stick to making money 2008-08-19 00:25 and not making people mad at them 2008-08-19 00:26 well, I fault Sun in this battle 2008-08-19 00:26 q: does ERR_PTR work out ok in userspace? 2008-08-19 00:26 they should have layed off 2008-08-19 00:26 I think I'd like to overload some pointer returns with (negative) error numbers 2008-08-19 00:27 sun probably thinks netapp's claim is weak 2008-08-19 00:27 I'd bet with sun on that 2008-08-19 00:27 well, that's for the courts to decide, but it was because Sun's lawyers stopped talking them is why they eventually filed the lawsuit 2008-08-19 00:28 that's publically known 2008-08-19 00:28 ok, I didn't know 2008-08-19 00:28 hard to know what happened with all the he said she said 2008-08-19 00:28 so really, in this industry with how patents are set up, they really had to cross sue Sun. They filed the lawsuit in a way intentionally so that Sun would also have to cross sue them 2008-08-19 00:29 It's in Dave Hitz's blog 2008-08-19 00:29 I can introduce you to those folks the next time you're up if you want 2008-08-19 00:29 hey how about applying your considerable intellect to the question of whether ERR_PTR is ok to use in userspace 2008-08-19 00:29 I know most of those folks well 2008-08-19 00:29 and I'm sure they'd like to talk to you out of curiosity and stuff 2008-08-19 00:29 maybe one day 2008-08-19 00:29 flips: I know nothing about userspace/kernel space boundary stuff, sorry 2008-08-19 00:30 has nothing to do with kernel 2008-08-19 00:30 well, the next time you head to Mountain View I can set something up for you folks 2008-08-19 00:30 has everything to do with memory mapps 2008-08-19 00:30 in userspace 2008-08-19 00:30 yeah, I'm retarded about this stuff, looking at a latency_trace now to see why the reschedule is taking so long 2008-08-19 00:30 btw, stay away from things like bit spins 2008-08-19 00:31 well, we will get to locking questions pretty soon 2008-08-19 00:31 bit spin... ok 2008-08-19 00:31 talk to rostedt if you have any unclarity about that 2008-08-19 00:31 always was suspicious about that 2008-08-19 00:31 lock_page is a bit spin 2008-08-19 00:31 that is used heavily 2008-08-19 00:31 but the current rwlock implementation sort of a miracle 2008-08-19 00:31 really readly really heavily 2008-08-19 00:31 really good work done by rostedt 2008-08-19 00:31 nice 2008-08-19 00:32 anything that's atomic is f-ed in -rt 2008-08-19 00:32 rwspinlock, right? 2008-08-19 00:32 make sure that you don't those locks for that long 2008-08-19 00:32 I'm pretty good about that 2008-08-19 00:32 only things like timers and the scheduler rq turn off interrupts and rescheduling for relatively long periods of time 2008-08-19 00:32 usually just take a spin lock long enough to get some other synchronizer set up 2008-08-19 00:33 all of that has been type redefined to be backed by a variant of the rtmutex 2008-08-19 00:33 so things like spinlocks are actually mutexes with the ability to sleep across BKL and still have it be persistently held to maintain correctness 2008-08-19 00:33 I'm wondering if I should get some multithreading happening in the userspace code 2008-08-19 00:33 semantic corrrectness 2008-08-19 00:33 get the locks at least partially sorted in userspace 2008-08-19 00:33 using futexes 2008-08-19 00:33 yeah, that might be useful for a mock up 2008-08-19 00:34 ACTION needs to get back to work 2008-08-19 00:34 the alternative is to skip that and just do that part in the kernel port 2008-08-19 00:34 btw, one of the Coverity owners is a Goth 2008-08-19 00:34 and a Stanford CSE professor 2008-08-19 00:34 they hang out near goog in mtv 2008-08-19 00:35 that was on the hiring committed for Sebastian Thrum (sp?) Grand Challenge winner 2008-08-19 00:35 dawson somebody 2008-08-19 00:35 engler 2008-08-19 00:35 nice dude, I gave him Burning Man advice a year ago :) 2008-08-19 00:35 had a good time 2008-08-19 00:35 hiring? 2008-08-19 00:35 what kind of advice does one need for burning man? 2008-08-19 00:36 hiring committee for Stanford CSS 2008-08-19 00:36 CSE department 2008-08-19 00:36 "watch out for the brown tabs" 2008-08-19 00:36 flips: how to have a good time what to look out for, etc... 2008-08-19 00:36 haha 2008-08-19 00:36 floppy naked chicks 2008-08-19 00:36 on bikes 2008-08-19 00:36 sounds, um, athletic 2008-08-19 00:37 well btree leaf ops are functioning ok 2008-08-19 00:37 one issue: inserting keys in sorted order results in many half full leaves 2008-08-19 00:37 because after a leaf is split it never gets inserted into again 2008-08-19 00:38 there must be something clever to do about that 2008-08-19 00:38 ok a node in the b-tree represents a file right ? 2008-08-19 00:38 and you put the versioning information at that node ? 2008-08-19 00:38 some btrees are inode table blocks, some are file indexes 2008-08-19 00:38 how are indirect blocks dumped into that ? 2008-08-19 00:38 a leaf in a btree gets the versioned pointers 2008-08-19 00:38 the btree is the indirect block stuff 2008-08-19 00:39 oh shit, now I get it 2008-08-19 00:39 that's what I was wondering about 2008-08-19 00:39 so the time space trade off is really all about the b-tree and the metadata shoved into it 2008-08-19 00:39 two levels of trees 1) inode table 2) file index 2008-08-19 00:39 is that a correct understanding ? or am I just lost ? 2008-08-19 00:40 btrees are fairly efficient space wise 2008-08-19 00:40 not as efficient as a classic ufs radix tree for an index 2008-08-19 00:40 is my articulation accurate regarding your FS ? 2008-08-19 00:40 yes 2008-08-19 00:40 I get it 2008-08-19 00:40 fuck, wow 2008-08-19 00:40 I didn't at our conversation, but I do now after talking to you and reading the posts 2008-08-19 00:40 it's more efficient to have a bunch of versioned pointers at the leaves of btrees than to be constantly rewrite tree nodes 2008-08-19 00:40 in theory 2008-08-19 00:41 yeah, you'll be able to do all sorts of funky things with it 2008-08-19 00:41 probably 2008-08-19 00:41 there was an OLS paper that talked about something similar actually 2008-08-19 00:41 2005 2008-08-19 00:41 2006 2008-08-19 00:41 would be interesting to see 2008-08-19 00:41 usign some kind of things like what you're talking about but to do DB kind of stuff with file metadata 2008-08-19 00:41 I didn't get the proceedings that year 2008-08-19 00:42 you could take a jpg or something and have a different header or something like that 2008-08-19 00:42 it should be online regardless 2008-08-19 00:42 heh 2008-08-19 00:42 well you could use versioning for that 2008-08-19 00:42 which potentially a powerful thing 2008-08-19 00:42 yes 2008-08-19 00:42 but I'm being fairly unimagination and just using it to implement posix and versioning 2008-08-19 00:42 yeah, I just got your idea, I'm half blow away by it 2008-08-19 00:42 good night's work then 2008-08-19 00:43 blown 2008-08-19 00:43 holy shit 2008-08-19 00:43 this could potentially smoke zfs since it's so rigid 2008-08-19 00:43 you can do all sorts of fucking things with those b-tree nodes 2008-08-19 00:43 am I right ? 2008-08-19 00:45 right 2008-08-19 00:45 it's about one zillion times more compact than zfs 2008-08-19 00:45 yes, wow 2008-08-19 00:45 it's brilliant 2008-08-19 00:48 there are some interesting things being implemented in the inode table leaves 2008-08-19 00:48 the file leaves aren't going to get much fancier 2008-08-19 00:48 they're already pretty darn fancy 2008-08-19 00:49 see dleaf.c 2008-08-19 00:49 insane 2008-08-19 00:49 ok, have to go do work 2008-08-19 00:49 later 2008-08-19 00:49 good luck 2008-08-19 00:49 bye 2008-08-19 01:01 shapor, there's another bug 2008-08-19 01:02 the unit test adds a tree level and should not 2008-08-19 01:08 another bug: some buffers not getting released 2008-08-19 01:38 bogus buffer counts are gone 2008-08-19 01:38 now about that bogus level add 2008-08-19 01:39 sb->entries_per_node wasn't set 2008-08-19 02:11 flips: how are you dealing with concurrency issues with b-tree access ? 2008-08-19 02:11 you'll be doing a lot of reads to that tree and it's got to be able to do it quickly 2008-08-19 02:12 start with a single btree mutex then make it more granular 2008-08-19 02:12 when probing, drop the lock on the level above each time it goes deeper 2008-08-19 02:12 so just the leaf ends up locked 2008-08-19 02:13 if there's a better idea, whack me 2008-08-19 02:13 have you thought about using rcu instead for the read-sides ? 2008-08-19 02:14 what about write coherency in that tree across some kind of atomic sync ? 2008-08-19 02:14 yes I have 2008-08-19 02:14 -!- konrad(~konrad@c-24-16-74-109.hsd1.mn.comcast.net) has joined #tux3 2008-08-19 02:14 not really deeply though 2008-08-19 02:14 it's not a great rcu candidate 2008-08-19 02:14 the granularity issues are tricky and you could be stuck with a contention issue accessing that tree 2008-08-19 02:14 writing has to be really efficient too 2008-08-19 02:15 and rcu pukes pretty badly for writing 2008-08-19 02:15 yeah, I know 2008-08-19 02:15 I think the contention will be pretty good, provided the locks are pushed down the tree 2008-08-19 02:15 I have another trick too 2008-08-19 02:15 cursors 2008-08-19 02:15 a cursor is a probe path into the btree that isn't released 2008-08-19 02:16 you can't have a top level lock or else you'll run into things like the radix tree stuff for the page cache right ? 2008-08-19 02:16 to change the higher level blocks that a cursor owns you have to get everybody to release their cursor 2008-08-19 02:16 and limit yourself to about 2.5 processors for scalability 2008-08-19 02:16 maybe you can push this down to the versioning pointers themselves 2008-08-19 02:16 there won't be a lock inversion with radix tree 2008-08-19 02:17 radix tree lock is taken after btree lock 2008-08-19 02:17 it's not about inversion but contention and cache issues 2008-08-19 02:17 locks are ordered root to leaf in the btree 2008-08-19 02:17 the idea is not to access the root very often 2008-08-19 02:17 that is what the cursors do 2008-08-19 02:17 well, I'd expect top-level locks to really be hammered hard 2008-08-19 02:17 ok 2008-08-19 02:17 what about per cpu locality instead ? 2008-08-19 02:18 it needs to be stated more precisely 2008-08-19 02:18 so you can rip it apart ;-) 2008-08-19 02:18 localize things on an inode level or something like that with SLAB support 2008-08-19 02:18 one cursor per cpu would be nice 2008-08-19 02:18 flips: just trying to help you think it out, not to rip per se, I want you to succeed 2008-08-19 02:18 top level blocks will only change rarely and are possibly rcu candidates 2008-08-19 02:18 I want everybody to succeed :) 2008-08-19 02:18 :-) 2008-08-19 02:19 you might like to talk to peterz about some of these issues 2008-08-19 02:19 he's a tree concurrency expert 2008-08-19 02:19 ok, one concept about these cursors is, you can lop the top levels away from the cursor, so only the deeper levels hold locks 2008-08-19 02:19 then when you need to advance the cursor or something the top level locks are retaken... temporarily 2008-08-19 02:20 yes, peterz would be good 2008-08-19 02:20 I think I ought to port to kernel early and deal with the locking there 2008-08-19 02:20 instead of prototyping that in usespace 2008-08-19 02:20 you see how the locking works in ufs style file indexes? 2008-08-19 02:20 it's cute 2008-08-19 02:20 there is none 2008-08-19 02:21 property of the ind/dind/tind layout 2008-08-19 02:22 flips: you also need to think about file duping 2008-08-19 02:22 ? 2008-08-19 02:22 particularly de-duping 2008-08-19 02:22 not sure what you mean 2008-08-19 02:22 using a sha1 hash to make sure a file's contents are the same and aren't replicated 2008-08-19 02:22 so just having a pointer to it will do 2008-08-19 02:23 say for backing up a Windows volume and not recopying every fucking .dll constant in the system 2008-08-19 02:23 and other immutable files 2008-08-19 02:23 oh right 2008-08-19 02:23 just something to think about 2008-08-19 02:23 yes 2008-08-19 02:24 also possible to handle that at the volume level 2008-08-19 02:26 well, that's got to be handled in the b-tree as well I'd think since it's your only metadata structure that I know of 2008-08-19 02:27 the volume manager can pretend it's giving different blocks to the filesystem when they are actually the same 2008-08-19 02:28 then probably you need reference counting at some level 2008-08-19 02:28 venti and stuff like that 2008-08-19 02:31 well, the metadata grows as you add more functionality, so packing becomes important 2008-08-19 02:32 if I'm coming up with uninterestng things please tell me and I'll shut up 2008-08-19 02:32 you aren't suggesting looking for identical metadata blocks? 2008-08-19 02:33 but having something that can also vary the flatness of a particular file would also be useful like for video applications 2008-08-19 02:33 you could represent discontinguous spans using a special indirect block or something and describe the spans using an extent (?) 2008-08-19 02:33 indirect pointer I mean 2008-08-19 02:33 er, no, block 2008-08-19 02:34 flips: I'm suggesting what ever will work 2008-08-19 02:34 there are also to be extents 2008-08-19 02:34 extents will really flatten things 2008-08-19 02:34 so spans could be represented by an extent right ? 2008-08-19 02:34 ok, good 2008-08-19 02:34 yes 2008-08-19 02:34 sparse extents too 2008-08-19 02:34 good 2008-08-19 02:35 ok, am I raising interesting points or not ? 2008-08-19 02:35 oh yes 2008-08-19 02:35 especially the locking 2008-08-19 02:35 I need to make a specific proposal 2008-08-19 02:35 starting from easy and moving to efficient 2008-08-19 02:35 well, the b-tree thing is so obvious yet so powerful I'm surprised that somebody hasn't tried this already 2008-08-19 02:36 btrfs is btrees, so is zfs 2008-08-19 02:36 but versioning at the leaves is new 2008-08-19 02:36 yeah, but you're using it in a novell way which is why it's interesting to me 2008-08-19 02:36 ok 2008-08-19 02:36 what seems novelle to you? 2008-08-19 02:37 novel 2008-08-19 02:37 a problem with a single big b-tree I would think might be aging elements in memory so that certain frequently used things will be in core for use, like for checking the integrity of a volume without having to load the same indirect pointer again and again 2008-08-19 02:37 flips: using a b-tree generically for all sorts of things 2008-08-19 02:38 generic btrees are new too, right 2008-08-19 02:38 I also don't know as much as you about file systems so my comment could be out of ignorance 2008-08-19 02:38 flips: I'm interested in the power of generic b-trees for all sorts of metadata 2008-08-19 02:38 the buffer cache blocks are lru's 2008-08-19 02:38 lru'd 2008-08-19 02:39 clean, old ones get evicted 2008-08-19 02:39 dirty ones have to be cleaned regularly, that is the atomic commit 2008-08-19 02:39 I will add the third kind of btree probably tomorrow 2008-08-19 02:40 actually, I already added a third kind, the unit test implements a new btree just for testing 2008-08-19 02:40 and to demo what you have to do to specialize the btree 2008-08-19 02:40 what about sensitivity to things like an inode versus indirect versus lower level indirect blocks ? 2008-08-19 02:41 same for all other kinds of metadata 2008-08-19 02:41 there needs to be a kind of ordering or something like that I'd expect 2008-08-19 02:41 for commit? 2008-08-19 02:42 like an NFS use of a volume might be different for a Samba 2008-08-19 02:42 flips: for general reading 2008-08-19 02:42 ...and needs different kinds of metadata loaded and persistent in different ways 2008-08-19 02:42 this why I'm suspicious about the Linux page cache 2008-08-19 02:43 everything is handled the same way 2008-08-19 02:43 in the page cache 2008-08-19 02:43 the aging seems overly simplistic 2008-08-19 02:43 probably is 2008-08-19 02:43 linux kind of sucks there 2008-08-19 02:43 yeah, I've noticed 2008-08-19 02:43 somebody measured and found our pageout performs worse than random 2008-08-19 02:44 bad 2008-08-19 02:44 well my wife is heading to to tomorrow 2008-08-19 02:45 ok 2008-08-19 02:45 and I will drive to the ariport 2008-08-19 02:45 so night then right 2008-08-19 02:45 ? 2008-08-19 02:45 I'll be up still for a few more hours 2008-08-19 02:45 continue anytime ok? 2008-08-19 02:45 sure, I hope it was a useful conversation 2008-08-19 02:45 night for me 2008-08-19 02:45 it was 2008-08-19 02:45 night 2008-08-19 02:45 locking is getting imminent 2008-08-19 02:45 bye 2008-08-19 02:50 you should also think about how to cluster related data together in the b-tree for contigous write allocatin 2008-08-19 02:50 the block allocator is a bitch 2008-08-19 02:50 thinking every much about that 2008-08-19 02:51 I will post some thoughts pretty soon 2008-08-19 02:51 ok, just hope that i'm relevant about this :) 2008-08-19 02:51 inode number targetting is a big part of it 2008-08-19 02:51 oh yes 2008-08-19 02:51 rotating media still rules the wold 2008-08-19 02:51 world 2008-08-19 02:51 because different kinds of metadata need to be treated differently 2008-08-19 02:52 which could be a drawback of having a big b-tree manage all of this 2008-08-19 02:52 I guess you can always dump a shit load of ram into your system as well 2008-08-19 02:52 the allocator will try to places inode table blocks near the directories that link them (note impossibility with hard links) and data blocks near the inode table blocks 2008-08-19 02:52 also impossible in general 2008-08-19 02:53 what about what about relate indirect blocks ? 2008-08-19 02:53 and allocation with regards to versioning pointers and that information ? 2008-08-19 02:53 meaning higher level btree blocks 2008-08-19 02:53 as long as I'm asking good questions, I'll not feel like a fucking dork 2008-08-19 02:53 allocation target needs to be derived from the allocation target of the data blocks 2008-08-19 02:54 versioning makes allocation much harder 2008-08-19 02:54 yes 2008-08-19 02:54 very much so 2008-08-19 02:54 because you basically have to store lots of the data in the same place 2008-08-19 02:54 so you'll have to have an upper bounds on the fs for doing this allocation efficiently 2008-08-19 02:54 that is where the idea of generating functions for allocation comes in 2008-08-19 02:54 like a quadratic hash 2008-08-19 02:55 otherwise you'll be running into collisions 2008-08-19 02:55 there will be massive collisions 2008-08-19 02:55 I am aiming to collide elegantly 2008-08-19 02:55 what about allocation maps in the versioning system ? self contained in the b-tree itself ? 2008-08-19 02:55 that is a cool thing about versioned pointers 2008-08-19 02:55 if it's done on per volume basis, it could be a lot of replication 2008-08-19 02:55 you can tell from the versioned pointers what blocks are free 2008-08-19 02:56 right, so it's unified into the algorithm right ? 2008-08-19 02:56 there is just one global free tree for the whole filesystem 2008-08-19 02:56 knowing when to free a block is part of the versioning algorithm, yes 2008-08-19 02:56 it's pretty subtle 2008-08-19 02:56 well, what about fragmentation of that data ? 2008-08-19 02:56 about the hardest part actually 2008-08-19 02:56 yes, versioning can fragment stuff 2008-08-19 02:56 you'd generally like to have that easily accessible 2008-08-19 02:56 think of a mysql database with snapshots every 5 minutes 2008-08-19 02:56 wham 2008-08-19 02:57 this conversation is logged right ? 2008-08-19 02:57 I believe so 2008-08-19 02:57 ok, just so that folks can ponder this stuff and come up with answers 2008-08-19 02:57 see tux3bot up them 2008-08-19 02:57 well, the allocation map is a bitch 2008-08-19 02:58 true 2008-08-19 02:58 the bitmap thing is pretty cute 2008-08-19 02:58 your read performance and friends are really tightly connected to how fast you can do a lookup in a b-tree 2008-08-19 02:58 you just reminded me, I can't have the allocation bitmap in my inode table 2008-08-19 02:58 it's global to multiple volumes 2008-08-19 02:59 one crude trick: cache the root of the btree 2008-08-19 02:59 and the 1st level for good measure 2008-08-19 02:59 well, replicated it 2008-08-19 02:59 branching factor is 2^8 2008-08-19 02:59 say there are 10 million inodes 2008-08-19 03:00 packed 32/block 2008-08-19 03:00 I think you should think about per CPU-ification straight up initially as apart of the design 2008-08-19 03:00 so that you avoid these issues 2008-08-19 03:00 2^18 blocks about 2008-08-19 03:00 you might have to push it down to an inode level or something and replicate all of the volume bits above it 2008-08-19 03:00 which is 3 btree levels 2008-08-19 03:01 yes, that is the right way to think about it 2008-08-19 03:01 no bouncing 2008-08-19 03:01 yeah, talking to matt about it will help us 2008-08-19 03:01 it's nearly 2 levels 2008-08-19 03:01 worth trying to make it 2 levels 2008-08-19 03:01 er, you. I'm avoiding work right now ;) 2008-08-19 03:01 then cache the root 2008-08-19 03:02 I'll stay up later to compensate 2008-08-19 03:02 that's one probe to get to the inode 2008-08-19 03:02 flips: I think it's critical to think about how you're going to organize the metadata, what for specific use at a specific time 2008-08-19 03:02 the versioning pointer stuff is really potentially powerful 2008-08-19 03:02 been thought about a lot 2008-08-19 03:03 I'm thinking about how to pack the btree nodes better now 2008-08-19 03:03 because caching this shit properly is a major bitch 2008-08-19 03:03 yes 2008-08-19 03:04 right now it's big an homogenous 2008-08-19 03:04 an=and 2008-08-19 03:04 which sounds like shitty cache performance 2008-08-19 03:05 which means that you have to think about these things straight up 2008-08-19 03:05 before trying to really fully implement it 2008-08-19 03:05 it's not homogenous 2008-08-19 03:05 inode table blocks try to have related inodes 2008-08-19 03:06 blocks ? 2008-08-19 03:06 directory blocks have temporally related entries 2008-08-19 03:06