2008-10-24 01:51 folks 2008-10-24 01:51 I see people are talking about the lockless page cache 2008-10-24 02:17 a bit of... 2008-10-24 05:54 -!- FelipeS(~Felipe@r77h15.res.gatech.edu) has joined #tux3 2008-10-24 08:30 -!- mingming(~mingming@c-24-22-117-202.hsd1.or.comcast.net) has joined #tux3 2008-10-24 08:52 -!- tim_dimm(~timothyhu@cpe-76-90-98-247.socal.res.rr.com) has joined #tux3 2008-10-24 09:05 -!- hirofumi(~hirofumi@210.171.168.39) has joined #tux3 2008-10-24 09:15 -!- data(~data@echo489.server4you.de) has joined #tux3 2008-10-24 09:21 -!- tim_dimm(~timothyhu@cpe-76-90-98-247.socal.res.rr.com) has joined #tux3 2008-10-24 10:06 -!- pgquiles(~pgquiles@156.Red-88-25-133.staticIP.rima-tde.net) has joined #tux3 2008-10-24 10:15 -!- MaZe(~MaZe@216-239-45-4.google.com) has joined #tux3 2008-10-24 10:36 -!- RazvanM(~RazvanM@dazzler.isi.jhu.edu) has joined #tux3 2008-10-24 10:45 -!- mingming(~mingming@32.97.110.51) has joined #tux3 2008-10-24 12:31 -!- RazvanM(~RazvanM@dazzler.isi.jhu.edu) has joined #tux3 2008-10-24 15:11 -!- FelipeS(~Felipe@r77h15.res.gatech.edu) has joined #tux3 2008-10-24 15:44 -!- tim_dimm(~timothyhu@cpe-76-90-98-247.socal.res.rr.com) has joined #tux3 2008-10-24 16:12 -!- RazvanM(~RazvanM@dazzler.isi.jhu.edu) has joined #tux3 2008-10-24 16:13 ACTION got to the point where he needs to understand how get_block works 2008-10-24 16:17 ACTION wishes underscores didn't make him cringe 2008-10-24 16:18 ravanm, the vfs calls the filesystem saying "for this buffer, what is the physical address?" and the filesystem fills in the b_blocknr in the buffer 2008-10-24 16:19 the function is misnamed 2008-10-24 16:19 it doesn't get the block, but the address of the block 2008-10-24 16:20 or preciscely, "for this inode at this logical block offset, please fill in the buffer->b_blocknr" 2008-10-24 16:20 it's actually dumb to use a buffer to pass the result back, it should just be the function result 2008-10-24 16:25 thanks for the answer! :D 2008-10-24 16:25 -!- data(~data@echo489.server4you.de) has joined #tux3 2008-10-24 16:25 to fill the context, what I'm trying to implement is block_read_full_page 2008-10-24 16:28 well, I think it is time to do a big directory move, move everything out of user/test into / in the repo 2008-10-24 16:28 (thinking out loud) the block_read_full_page assumes that the page is filled by some bhs 2008-10-24 16:28 any objection? 2008-10-24 16:28 block_read_full_page will add buffers if there are none 2008-10-24 16:29 from where it will take the info to do that? 2008-10-24 16:29 from the index of the page? 2008-10-24 16:30 it only needs to know the block size 2008-10-24 16:30 which get gets from page->mapping->sb 2008-10-24 16:30 how about the start point? 2008-10-24 16:30 ok, let me see, we have doc/ in the top level of the repo 2008-10-24 16:30 (in romfs it was from index: http://lxr.linux.no/linux+v2.6.26/fs/romfs/inode.c#L432 ) 2008-10-24 16:31 so maybe I should just move user/test/* to user/* 2008-10-24 16:31 and then there will be a kernel and a fuse one? 2008-10-24 16:31 aaa... fuse is inside the user now 2008-10-24 16:32 use, it would be doc/ user/ kernel/ 2008-10-24 16:33 doc/ user/ kernel/ README COPYING INSTALL Makefile 2008-10-24 16:33 something like that 2008-10-24 16:34 and the Makefile from the root will build both user and kernel? 2008-10-24 16:34 and user/ will eventually have fsck.tux3 2008-10-24 16:34 I guess we won't try to build kernel 2008-10-24 16:34 probably just call the makefile in user 2008-10-24 16:35 it could possibly extract a patch from a mercurial repo it knows about 2008-10-24 16:35 err 2008-10-24 16:35 git repo for kernel stuff 2008-10-24 16:35 it could also do make tarball and make docs 2008-10-24 16:35 or make deb even 2008-10-24 16:36 ok, anyway /test/ is going to go away right now 2008-10-24 16:37 sucks hg and git don't really understand the concept of mv 2008-10-24 16:37 hg does! 2008-10-24 16:37 I mean I moved some stuff around using it 2008-10-24 16:37 renamed a directory 2008-10-24 16:38 "rename files; equivalent of copy + remove" 2008-10-24 16:38 it fakes it 2008-10-24 16:38 yup 2008-10-24 16:38 but the history is not lost 2008-10-24 16:41 it is kind of 2008-10-24 16:41 it doesn't have the notion that the moved object is the same 2008-10-24 16:41 in fact hg and git really don't have notions of objects, only of equality 2008-10-24 16:41 equality of file text 2008-10-24 16:41 deficiency 2008-10-24 16:41 why is not enought? :D 2008-10-24 16:42 but it works sort of ok most of the time 2008-10-24 16:42 well for example if a person changes the name, you know they're the same person, even if they change hats too 2008-10-24 16:43 so if in a changeset you both mv and edit the mved file, git and hg lose track 2008-10-24 16:44 true 2008-10-24 16:44 Depends on how seriously it is modified 2008-10-24 16:44 I changed a file for less than 10% and it was still tracked 2008-10-24 16:45 this was in hg? 2008-10-24 16:45 or git? 2008-10-24 16:47 git 2008-10-24 16:47 ok there we go 2008-10-24 16:48 On less than 10% it says 'moved' more was a rewrite iirc 2008-10-24 16:48 one can imagine the messy heuristics to do that 2008-10-24 16:48 accuracy is always better 2008-10-24 16:49 Wine can still trace some code that was rewritten a lot of times and moved various things around 2008-10-24 16:51 git-blame even found some wine 0.0.2 code 2008-10-24 16:53 Q: what does bmap? 2008-10-24 16:53 the original Monotone relied even more heavily on heuristcs for rename 2008-10-24 16:53 (the readpage looks pretty mess in minix :|) 2008-10-24 16:53 there are always places where it causes strange behavior 2008-10-24 16:54 bmap queries the filesystem about the physical location of a given logical block of a file 2008-10-24 16:54 bmap is problematic for filesystems that do deferred allocation 2008-10-24 16:54 static sector_t minix_bmap(struct address_space *mapping, sector_t block) 2008-10-24 16:54 or online defrag, or shrink, or remap 2008-10-24 16:55 so I just need to properly construct the mapping and then ask for the bloks one by one, right? 2008-10-24 16:55 yes 2008-10-24 16:55 bmap doesn't always work, for the reasons above 2008-10-24 16:55 an inherently racy interface 2008-10-24 16:56 so I should make the readpage work instead? :D 2008-10-24 16:56 readpage isn't exposed to userspace 2008-10-24 16:56 that's the point of bmap 2008-10-24 16:56 whay of userspace, principally lilo, to find physical block locations 2008-10-24 16:57 using bmap inside kernel is unconscionable, but probably there are cases 2008-10-24 16:58 I'm going back to readpage :P 2008-10-24 16:58 right 2008-10-24 16:59 note that the readpage interface is also racy, relying on the cached physical block address as it does 2008-10-24 16:59 there is nothing to prevent the physical block address from moving before being read 2008-10-24 17:00 filesystem has to provide that locking 2008-10-24 17:02 so I guess I could easily end up in a bad state by calling stuff in an unexpected order... 2008-10-24 17:03 if your filesystem supports online defrag, shrink, remapping or delayed allocation 2008-10-24 17:51 sk8 oclock 2008-10-24 17:51 going to be a sunset skate 2008-10-24 17:54 enjoy :D 2008-10-24 18:16 ACTION is trying to find who should properly set the i_blkbits in an inode 2008-10-24 18:17 and the answer is: alloc_inode 2008-10-24 19:02 wow... alloc_page_buffers doesn't make a circular list of bh 2008-10-24 19:03 it just make a NULL-terminat list 2008-10-24 19:03 and create_empty_buffers finished the job 2008-10-24 19:18 (again thinking out loud) actually... I don't think I need to create the buffer links to cover the page 2008-10-24 19:18 I can use one 2008-10-24 19:19 get the real address using the get_block and then call the bread to get the data 2008-10-24 19:20 hmm... my __bread also allocated a bh 2008-10-24 19:24 http://lxr.linux.no/linux+v2.6.26/fs/minix/itree_common.c#L145 more complicated things are taking places... 2008-10-24 19:24 because of the indirect blocks 2008-10-24 19:25 back 2008-10-24 19:26 welcome! :D 2008-10-24 19:27 I'm just making some noise here :P 2008-10-24 19:27 razvanm, don't forget that the page buffers are used not just for once off IO but to cache the physical block address 2008-10-24 19:28 so it's probably best to fully populate the page 2008-10-24 19:28 some filesystems may make assumptions 2008-10-24 19:28 I will populate the page 2008-10-24 19:28 but I don't want to keep around the bhs 2008-10-24 19:28 do the filesystems expect them to be around a lot? 2008-10-24 19:29 what I'm implementing right now is block_read_full_page 2008-10-24 19:29 http://lxr.linux.no/linux+v2.6.26.6/fs/block_dev.c#L71 <- blkbits for the inode for a block device is set here 2008-10-24 19:29 probably bogus 2008-10-24 19:29 I solved that thing :P 2008-10-24 19:29 it was a bug in my alloc_inode :D 2008-10-24 19:31 I wonder what costs more, having an extra indirection in the inode to find the block shift, or bloating up all inodes by an extra word? 2008-10-24 19:31 let me try to formulate a coherent question: is ok if I fill implement block_read_full_page without maintaining the bh for it? 2008-10-24 19:31 I suspect the latter is more costly 2008-10-24 19:31 yes, certainly 2008-10-24 19:32 some filesystems do that 2008-10-24 19:32 yeah! romfs :P 2008-10-24 19:32 though they skip block_read_full_page entirely 2008-10-24 19:32 and just do what has to be done directly 2008-10-24 19:32 which I think is going to be the strategy for tux3 2008-10-24 19:32 great! :D 2008-10-24 19:33 slightly larger code in return for avoiding a huge pile of donkey dung 2008-10-24 19:33 minix_readpage is calling only one function: the block_read_full_page 2008-10-24 19:33 -!- ChanServ changed mode/#tux3 -> +o flips 2008-10-24 19:34 changing the title? 2008-10-24 19:34 http://tux3.org ~ Tux3 U, right here Tuesdays and Thursdays at 8 pm Pacific Time ~ Next session: is ->t_block really necessary? 2008-10-24 19:34 -!- flips changed topic to "http://tux3.org ~ Tux3 U, right here Tuesdays and Thursdays at 8 pm Pacific Time ~ Next session: is ->t_block really necessary?" 2008-10-24 19:34 attempting to 2008-10-24 19:34 it worked :D 2008-10-24 19:34 -!- flips changed topic to "http://tux3.org ~ Tux3 U, right here Tuesdays and Thursdays at 8 pm Pacific Time ~ Next session: is ->get_block really necessary?" 2008-10-24 19:35 -!- ChanServ changed mode/#tux3 -> -o flips 2008-10-24 19:35 I was about to ask who is t_block :P 2008-10-24 19:35 if the FS is implementing the readpage directly then there should be no need for get_block, right? 2008-10-24 19:36 at least on the read part 2008-10-24 19:36 (the only one I explored so far) 2008-10-24 19:40 ->get_block is called in lots of places besides readpage 2008-10-24 19:42 those places should be some sort of generic code that tries to simplify the FS, right? 2008-10-24 19:43 by systematically avoiding the generic code the need for get_block should go away 2008-10-24 19:43 not using the generic stuff would also help when porting to another OS :P 2008-10-24 20:05 great! my first call to get_block from minix really worked :D 2008-10-24 20:05 time to go home 2008-10-24 20:21 hey flips 2008-10-24 20:21 hi 2008-10-24 20:21 one more week until the big cabal 2008-10-24 20:21 how's it going with atomic commits ? 2008-10-24 20:21 thursday next 2008-10-24 20:22 on the 30th ? 2008-10-24 20:22 following the thread with matt dillon? 2008-10-24 20:22 yes 2008-10-24 20:22 no, ust he initial post 2008-10-24 20:23 flips: can't find an email link on your new home page 2008-10-24 20:23 you might like to fix that or point out that I'm wrong 2008-10-24 20:24 if it's hard to find it needs to be fixed 2008-10-24 20:24 there is is 2008-10-24 20:24 it is 2008-10-24 20:24 should also link it from the front page, agreed 2008-10-24 20:25 yeah, that would be best, having difficulty finding it 2008-10-24 20:28 do you have a link to the discussion btw ? 2008-10-24 20:29 http://tux3.org/pipermail/tux3/ 2008-10-24 20:31 flips: matt is a great technical ally btw 2008-10-24 20:31 bh, check it out now 2008-10-24 20:31 that's putting it mildly 2008-10-24 20:31 imo, he's the best overall kernel engineer in all of the BSDs minus the original BSD/OS folks 2008-10-24 20:32 matt by the way is responsible for inspiring the linux 2.6 vm design 2008-10-24 20:32 flips: still don't see the link yet 2008-10-24 20:32 flips: yeah, I was behind the scenes in those dats 2008-10-24 20:32 days 2008-10-24 20:32 I saw the entire thing traspire 2008-10-24 20:32 transpire 2008-10-24 20:32 I'll be back later 2008-10-24 20:32 ok 2008-10-24 20:33 try shift-reload 2008-10-24 20:35 still nothing different 2008-10-24 20:42 what browser? 2008-10-24 20:42 something about how it handles frames? 2008-10-24 21:43 -!- tim_dimm(~timothyhu@cpe-76-90-98-247.socal.res.rr.com) has joined #tux3 2008-10-24 21:56 -!- tim_dimm(~timothyhu@cpe-76-90-98-247.socal.res.rr.com) has joined #tux3 2008-10-24 22:16 -!- RazvanM(~RazvanM@pool-151-196-118-156.balt.east.verizon.net) has joined #tux3