2008-09-09 00:04 <flips> yo
2008-09-09 00:17 <flips> 
ACTION starts writing encode_xattrs

2008-09-09 00:24 <flips> hmm, issue
2008-09-09 00:24 <flips> what endianness of xattr data?
2008-09-09 00:25 <flips> I suppose the filesystem does not care
2008-09-09 00:26 <flips> if the application cares, it better take care of it
2008-09-09 00:28 <shapor> flips: unlink a 0 length file causes an infinite loop heh
2008-09-09 00:28 <flips> heh
2008-09-09 00:29 <flips> fixed yet?
2008-09-09 00:29 <shapor> free <- [ffffdddddddddddd]
2008-09-09 00:29 <shapor> bfree: block 0xffffdddddddddddd already free!
2008-09-09 00:29 <shapor> free <- [ffffdddddddddddd]
2008-09-09 00:29 <shapor> bfree: block 0xffffdddddddddddd already free!
2008-09-09 00:29 <flips> 
ACTION thinks about why that might be

2008-09-09 00:29 <flips> those dddddddd are uninited data
2008-09-09 00:29 <konrad> shapor: that happens to me a lot
2008-09-09 00:29 <flips> bad
2008-09-09 00:29 <flips> you should complain more
2008-09-09 00:30 <konrad> :D
2008-09-09 00:30 <shapor> does tree_chop do the right thing if there is no data int he btree?
2008-09-09 00:30 <shapor> hm
2008-09-09 00:30 <konrad> and by 'that' I mean the infinite loop with the exact same values
2008-09-09 00:30 <shapor> or is the way we're creating files in fuse broken
2008-09-09 00:31 <flips> 	/* let's clear out the buffer array and data and set to deadly data 0xdd */
2008-09-09 00:31 <flips> 	memset(data_pool, 0xdd, max_buffers*bufsize);
2008-09-09 00:31 <flips> do you want me to fix it, or do you want to sniff first?
2008-09-09 00:31 <flips> it's deep in the poo
2008-09-09 00:32 <flips> no question its a tux3 bug
2008-09-09 00:32 <shapor> i suspected fuse
2008-09-09 00:32 <flips> the d's above prove it
2008-09-09 00:32 <shapor> hm
2008-09-09 00:32 <flips> should be able to reproduce easily either with tux3.c or inode.c
2008-09-09 00:33 <flips> hack the test a little
2008-09-09 00:33 <shapor> starts out like this:
2008-09-09 00:33 <shapor> ---- delete file ----
2008-09-09 00:33 <shapor> lookup inode 0x21, 0 + 21
2008-09-09 00:33 <shapor> open_inode: found inode 0x21
2008-09-09 00:33 <shapor> mode 0100666 uid 0 gid 0 root 21:1 
2008-09-09 00:33 <shapor> free <- [0]
2008-09-09 00:33 <shapor> free <- [0]
2008-09-09 00:33 <shapor> bfree: block 0x0 already free!
2008-09-09 00:33 <shapor> free <- [0]
2008-09-09 00:33 <shapor> bfree: block 0x0 already free!
2008-09-09 00:34 <flips> ffffdddddddddddd <- I'm surprised the allocator manages to deal with this
2008-09-09 00:34 <shapor> that repeats for a while
2008-09-09 00:34 <shapor> then
2008-09-09 00:34 <shapor> filemap_blockio: read <0:bbbbbbbb>
2008-09-09 00:34 <shapor> filemap_blockio: unmapped block bbbbbbbb
2008-09-09 00:34 <shapor> free <- [ffffdddddddddddd]
2008-09-09 00:34 <flips> got to check some limits there
2008-09-09 00:34 <shapor> bfree: block 0xffffdddddddddddd already free!
2008-09-09 00:34 <shapor> and the loop begins
2008-09-09 00:34 <flips> it's possibly trying to treat a block of zeros a dleaf
2008-09-09 00:35 <flips> or it did a getblk where it should have done a bread
2008-09-09 00:35 <flips> something :-)
2008-09-09 00:35 <shapor> is this the first tux3 bug fuse has found?
2008-09-09 00:35 <flips> think so
2008-09-09 00:36 <flips> actually, fuse found a couple bugs in dir.c
2008-09-09 00:40 <shapor> ah i see
2008-09-09 00:40 <flips> so soon?
2008-09-09 00:40 <shapor> reproduced the bug by adding a test case to dleaf.c
2008-09-09 00:40 <shapor> and running make dleaftest
2008-09-09 00:40 <flips> your favorite file
2008-09-09 00:41 <shapor> empty dleaf is the culprit
2008-09-09 00:41 <flips> and the fix?
2008-09-09 00:42 <shapor> fix?
2008-09-09 00:42 <shapor> its more fun to break!
2008-09-09 00:42 <shapor> :P
2008-09-09 00:42 <shapor> so we allocate a dleaf even for a 0 length file?
2008-09-09 00:43 <shapor> that is something that will be optimized away right?
2008-09-09 00:44 <shapor> 143 /*
2008-09-09 00:44 <shapor> 144  * Reasons this dleaf truncater sucks:
2008-09-09 00:44 <flips> yes
2008-09-09 00:44 <shapor> haha
2008-09-09 00:44 <flips> it will be optimized away
2008-09-09 00:44 <shapor> good thing we aren't doing premature optimization
2008-09-09 00:44 <flips> very good
2008-09-09 00:45 <shapor> bug wouldnt be noticed
2008-09-09 00:45 <shapor> flips: were you high when you wrote this?
2008-09-09 00:45 <flips> quite
2008-09-09 00:45 <flips> konrad was complicit
2008-09-09 00:46 <flips> so what is the condition it doesn't handle?
2008-09-09 00:46 <konrad> heh
2008-09-09 00:46 <flips> empty dleaf, but initialized?
2008-09-09 00:46 <flips> where did those ddddddd's come from?
2008-09-09 00:46 <shapor> nah it just overflowed
2008-09-09 00:47 <shapor> to some other area
2008-09-09 00:47 <shapor> at first it was all zeros
2008-09-09 00:48 <shapor> flips: in general how are we going to deal with corruption
2008-09-09 00:48 <shapor> we need a lot more integrity checking
2008-09-09 00:48 <shapor> it will slow it down
2008-09-09 00:48 <flips> yes
2008-09-09 00:48 <flips> that's life
2008-09-09 00:49 <flips> the rule is: you should be able to randomize any block and not cause an oops
2008-09-09 00:49 <flips> everything has to fail on nasty random disk data
2008-09-09 00:49 <shapor> definitely
2008-09-09 00:49 <shapor> filesystems are hard
2008-09-09 00:49 <flips> that can be pretty lightweight checking
2008-09-09 00:49 <flips> see dir.c
2008-09-09 00:49 <flips> very mature code
2008-09-09 00:49 <flips> has obviously gone through a lot of fixes in that regard
2008-09-09 00:50 <flips> not nice code mind you
2008-09-09 00:50 <flips> just heavily fixed
2008-09-09 00:51 <shapor> so i was able to find that bug anyway
2008-09-09 00:51 <shapor> because "touch file" is working in my repo :)
2008-09-09 00:52 <flips> :-)
2008-09-09 00:53 <shapor> well sort-of working
2008-09-09 00:53 <shapor> the mtime is wrong
2008-09-09 00:53 <flips> expected
2008-09-09 00:54 <shapor> ah duh
2008-09-09 00:54 <shapor> is getaatr just broken?
2008-09-09 00:54 <shapor> hm
2008-09-09 00:54 <flips> could be
2008-09-09 00:54 <shapor> i'm calling store_inode after setting the i_mtime 
2008-09-09 00:54 <shapor> er save_inode
2008-09-09 00:55 <shapor> it does seem to be doing it by looking at the debug info
2008-09-09 00:55 <flips> huh, the xattr encoder seems to work
2008-09-09 00:55 <flips> you also have to set the ->present bit for the mtime
2008-09-09 00:56 <flips> I don't think anything does that for you
2008-09-09 00:58 <shapor> i thought i saw something in inode.c
2008-09-09 00:58 <shapor> hrm
2008-09-09 00:59 <flips> way back
2008-09-09 00:59 <flips> then it became discretionary
2008-09-09 00:59 <flips> without a test case ;-)
2008-09-09 00:59 <shapor> oh
2008-09-09 00:59 <shapor> tisk tisk
2008-09-09 01:12 <flips> ?
2008-09-09 01:12 <flips> encode_xattrs is functional, now for decode
2008-09-09 01:14 <shapor> flips: you can pull fuse utime support + dealf bug test from me
2008-09-09 01:14 <flips> ok, need a place to decode the xattrs to
2008-09-09 01:14 <flips> hmm
2008-09-09 01:14 <flips> kay
2008-09-09 01:14 <shapor> no fix yet, been dicking with the mtime issue
2008-09-09 01:14 <flips> you just want to send your cruft over?
2008-09-09 01:14 <flips> oh
2008-09-09 01:14 <flips> utime
2008-09-09 01:14 <shapor> its annoying me that everything is 1969
2008-09-09 01:15 <shapor> epoch
2008-09-09 01:15 <shapor> we need the logic to make the timestamps default to eachother
2008-09-09 01:15 <shapor> but thats not even the issue
2008-09-09 01:15 <shapor> even the ctime is broken
2008-09-09 01:15 <flips> have you thought about setting up a dedicated repo for me to pull from, into which you only pull one head?
2008-09-09 01:15 <flips> or do you want your dicking around recorded for posterity ;-)
2008-09-09 01:16 <shapor> theres only one head in my repo
2008-09-09 01:16 <flips> because you merged
2008-09-09 01:16 <flips> but all your merges show up over here
2008-09-09 01:16 <shapor> ah, annoying
2008-09-09 01:16 <shapor> why is hg such a pita
2008-09-09 01:16 <flips> unless you do that version specific pull
2008-09-09 01:16 <shapor> this is supposed to just work
2008-09-09 01:16 <flips> git is identical
2008-09-09 01:17 <flips> well its not really wrong
2008-09-09 01:17 <shapor> cant you cherry pick my change?
2008-09-09 01:17 <flips> yes
2008-09-09 01:17 <flips> but its time consuming
2008-09-09 01:17 <shapor> should be oneliner
2008-09-09 01:17 <flips> much more efficient for you to just pull your time to a dedicated repo. that can be automatic
2008-09-09 01:17 <flips> pull your tip
2008-09-09 01:17 <flips> well
2008-09-09 01:18 <flips> not much difference
2008-09-09 01:18 <flips> try hg view
2008-09-09 01:18 <flips> you'll see all the extra stuff
2008-09-09 01:20 <flips> shapor, the times are all broken because they are never set
2008-09-09 01:20 <flips> you can see where to set them in inode.c
2008-09-09 01:20 <flips> there's a gettime available I think
2008-09-09 01:20 <shapor> http://www.selenic.com/mercurial/wiki/index.cgi/CommunicatingChanges#line-63
2008-09-09 01:20 <shapor> would that be easier?
2008-09-09 01:21 <shapor> doesn't decode_attrs set them in struct inode?
2008-09-09 01:21 <shapor> gets called in open_inode
2008-09-09 01:22 <flips> they never get set to an actual time
2008-09-09 01:23 <shapor> they should now with my utime code though
2008-09-09 01:23 <shapor> not sure why its not working
2008-09-09 01:23 <shapor> hrm
2008-09-09 01:23 <shapor> too many interfaces
2008-09-09 01:24 <shapor> bah
2008-09-09 01:24 <flips> way too many
2008-09-09 01:24 <flips> 	inode->i_mtime = inode->i_ctime = inode->i_atime = iattr->mtime; ><- this is where to set the time
2008-09-09 01:24 <flips> in inode.c
2008-09-09 01:25 <konrad> I thought some of the times were stored differently (lower resolution)
2008-09-09 01:25 <flips> brings up the question: what is the format of a tux3 time?
2008-09-09 01:25 <konrad> yeah
2008-09-09 01:25 <flips> yes
2008-09-09 01:25 <flips> so, I'd like to get away from the traditional decimal encoding
2008-09-09 01:25 <flips> were the fraction is millionths or billionths
2008-09-09 01:25 <flips> and use strictly binary
2008-09-09 01:26 <flips> that means multiplying and dividing to convert to the braindamaged linux format
2008-09-09 01:26 <flips> not sure whether this is wise
2008-09-09 01:27 <shapor> hrm 202         u64 i_size, i_mtime, i_ctime, i_atime;
2008-09-09 01:27 <shapor> u64?
2008-09-09 01:28 <flips> that's just in the inode, the memory version
2008-09-09 01:28 <flips> on disk it gets sqzed, maybe
2008-09-09 01:28 <shapor> yeah but still
2008-09-09 01:28 <shapor> whats the point of u64 in memory even?
2008-09-09 01:28 <flips> u32 is too small
2008-09-09 01:28 <flips> and c doesn't play well with others
2008-09-09 01:28 <shapor> so we have our own format?
2008-09-09 01:29 <flips> we have to use the linux format there
2008-09-09 01:29 <flips> when we got to kernel
2008-09-09 01:29 <shapor> hm
2008-09-09 01:29 <flips> because those are in the generic part of the inode
2008-09-09 01:29 <shapor> i'm getting tired
2008-09-09 01:29 <flips> I haven't divided up the inode into generic and filesystem specific parts yet
2008-09-09 01:29 <shapor> i think my changes are crap, might not want to merge them
2008-09-09 01:29 <shapor> they dont add much
2008-09-09 01:29 <shapor> other than sort-of working touch
2008-09-09 01:29 <flips> sleep on it
2008-09-09 01:29 <flips> fly away
2008-09-09 01:29 <flips> hack onthe plane
2008-09-09 01:30 <flips> see how nicely encode_xattrs came out
2008-09-09 01:30 <flips> in iattr.c
2008-09-09 01:31 <flips> decode_xattrs is a little messier because we have to guess how big to make the cache
2008-09-09 01:31 <flips> I suppose I'd better run a size-guessing pass first to know the size for thecache
2008-09-09 02:30 -!- kbingham(~kbingham@193.132.141.186) has joined #tux3
2008-09-09 02:32 -!- MaZe(~MaZe@c-24-6-86-168.hsd1.ca.comcast.net) has joined #tux3
2008-09-09 02:52 <bh> development is going pretty well
2008-09-09 03:02 <flips> I'd say
2008-09-09 04:42 <flips> konrad, your fuse post got linked from lwn.net: http://lwn.net/Articles/297308/
2008-09-09 04:42 <konrad> jesus
2008-09-09 04:43 <flips> night
2008-09-09 04:43 <konrad> night
2008-09-09 04:55 <konrad> where'd that get linked from?
2008-09-09 06:31 -!- MaZe(~MaZe@c-24-6-86-168.hsd1.ca.comcast.net) has joined #tux3
2008-09-09 12:17 -!- RazvanM(~RazvanM@dazzler.isi.jhu.edu) has joined #tux3
2008-09-09 12:41 <bh> nice
2008-09-09 14:22 <flips> 
ACTION makes another cuppa before pulling the trigger on the "one less feature" psot

2008-09-09 14:22 <flips> post
2008-09-09 14:41 <pgquiles> flips: by depending so much on LVM, aren't you limiting the OSs on top of tux3 can be run? What if I want to use tux3 with Solaris, FreeBSD or HP-UX?
2008-09-09 14:42 <pgquiles> by "limiting the OSs" I mean "it will require a lot of work to make tux3 work with non-Linux OSs"
2008-09-09 14:43 <flips> they will have a lot of work anyway
2008-09-09 14:43 <flips> gpl license is incompatible with all those
2008-09-09 14:43 <flips> but if tux3 catches on in linux then they will just have to do it
2008-09-09 14:44 <flips> pgquiles, you mean to say you already read the one less feature post?
2008-09-09 14:46 <flips> 
ACTION thinks about making it an early sk8 day

2008-09-09 14:46 <pgquiles> flips: yes
2008-09-09 14:47 <flips> anyway, this isn't more than people already depend on lvm
2008-09-09 14:47 <pgquiles> ah, ok
2008-09-09 14:48 <flips> what I don't want to do is depend on an lvm built into a filesystem, maintained by a very small group of developers and used by only one application
2008-09-09 14:48 <flips> it's bad enough depending on my generic btree code ;-)
2008-09-09 14:49 <pgquiles> :-)
2008-09-09 14:50 <pgquiles> I'm really impressed at how much you do in so few lines of code
2008-09-09 14:50 <flips> easy when you leave out the error handling :-)
2008-09-09 14:50 <flips> well
2008-09-09 14:51 <pgquiles> you make filesystem development sound easy, like "hey, this morning I feel like I'm going to write my filesystem" :-)
2008-09-09 14:51 <flips> trying to put some of that in too
2008-09-09 14:51 <flips> that's how I felt 6 weeks ago
2008-09-09 14:51 <flips> thought it could be prototyped in 2 weeks
2008-09-09 14:51 <flips> I was wrong
2008-09-09 14:51 <flips> looks like 8 weeks
2008-09-09 14:52 <flips> and that is only with the unexpected help of fuse
2008-09-09 14:52 <flips> and of course with the help of all the helpers
2008-09-09 14:52 <flips> are seem to be increasing exponentially
2008-09-09 14:53 <flips> who seem I mean
2008-09-09 14:54 <flips> timothy has a baby girl
2008-09-09 14:54 <pgquiles> newborn?
2008-09-09 14:56 <pgquiles> they are very nice while in the poop-machine age
2008-09-09 14:57 <pgquiles> when teeth show... they cry all the time :-)
2008-09-09 14:58 <flips> newborn indeed
2008-09-09 14:58 <flips> it's worth the effort
2008-09-09 14:59 <pgquiles> it is, indeed
2008-09-09 15:00 <pgquiles> until they are 12 years old and start behaving like young terrorists :-D
2008-09-09 15:00 <flips> lkml is running slow today
2008-09-09 15:05 <pgquiles> bedtime
2008-09-09 15:07 <flips> bye
2008-09-09 15:07 <flips> adios
2008-09-09 15:44 -!- kbingham(~kbingham@92.8.9.246) has joined #tux3
2008-09-09 15:44 <flips> finally showed up on lkml: http://lkml.org/lkml/2008/9/9/402
2008-09-09 15:45 <flips> "Tux3 Report: One less feature"
2008-09-09 16:15 <flips> new file
2008-09-09 16:15 <flips> xattr.c
2008-09-09 16:16 <flips> will skate first then make atom resolution actually work 
2008-09-09 16:25 <RazvanM> a quick q: is it ok to submit some patches to allow tux3 to compile on mac? :P
2008-09-09 16:34 <flips> if you can work out the license issues
2008-09-09 16:34 <flips> not sure how you'd do that
2008-09-09 16:34 <flips> compile under a linux emulator maybe
2008-09-09 16:36 <RazvanM> I'm only interested in running tux3 in userspace
2008-09-09 16:36 <RazvanM> does this conflict with any license?
2008-09-09 16:37 <flips> not that I know of
2008-09-09 16:38 <RazvanM> good :D
2008-09-09 16:38 <flips> sounds like a cool project
2008-09-09 16:39 <flips> the fuse lib you link with will need to be gpl
2008-09-09 16:39 <flips> or compatible
2008-09-09 16:39 <flips> gpl v3 compatible, which is a little easier than v2
2008-09-09 16:39 <RazvanM> I don't want to link to fuse actually
2008-09-09 16:40 <flips> directly using kernel calls is traditionally ok
2008-09-09 16:40 <flips> you're probably using libc, right?
2008-09-09 16:40 <flips> I think macos uses libc
2008-09-09 16:40 <flips> that's compatible
2008-09-09 16:40 <RazvanM> true
2008-09-09 16:40 <RazvanM> some things are not quite the same
2008-09-09 16:41 <RazvanM> the libc is deeply embedded in mac
2008-09-09 16:41 <flips> I can imagine
2008-09-09 16:41 <flips> obviously, tux3 will really need forks now ;-)
2008-09-09 16:41 <flips> tux3 xattrs are intended to be forks as well
2008-09-09 16:41 <RazvanM> one cool thing I want to accomplish to be able to run an FTP server to expose the tux3 ;-)
2008-09-09 16:42 <flips> don't be in a big rush to do that unless you are great at debugging
2008-09-09 16:42 <RazvanM> well... I am actually attempting this for some linux fs anyway
2008-09-09 16:43 <RazvanM> doing it also for tux3 fits well :D
2008-09-09 16:43 <flips> ftp load is fairly forgiving
2008-09-09 16:43 <flips> read mostly
2008-09-09 16:44 <flips> ok, I'd better get my skate in
2008-09-09 16:44 <flips> promised to do a tux3 university session tonight at 8
2008-09-09 16:46 <flips> amazing how many more penis extension spams I get when I am actively posting about Tux3, I wonder if there is a relation
2008-09-09 16:46 <RazvanM> 8pm? (like in 15 minutes?)
2008-09-09 16:47 <RazvanM> ohh... the other coast
2008-09-09 16:47 <flips> right
2008-09-09 16:48 <RazvanM> great! we have time to go home and eat till then :P
2008-09-09 16:49 <RazvanM> do we need to review some material before showing up? :D
2008-09-09 16:50 <flips> optional
2008-09-09 16:50 <flips> if you have time, read "understanding the linux kernel" and "linux device drivers" ;-)
2008-09-09 16:50 <konrad> haha
2008-09-09 16:50 <RazvanM> understanding is on my right, the ldd is at home :P
2008-09-09 16:51 <RazvanM> I found the "understanding..." more useful so that's why I hauled it to school
2008-09-09 16:52 <flips> linux device drivers will grow on you
2008-09-09 16:52 <RazvanM> this 3rd edition really put some weight
2008-09-09 16:52 <flips> it's the deeper of the two
2008-09-09 16:52 <flips> lets see which edition I have
2008-09-09 16:52 <RazvanM> LDD is the first one I got in touch actually
2008-09-09 16:52 <RazvanM> the first edition
2008-09-09 16:52 <RazvanM> some years ago :D
2008-09-09 16:53 <flips> 3rd, and I still find it on the superficial side
2008-09-09 16:53 <RazvanM> for fs stuff or in general?
2008-09-09 16:57 <flips> in general
2008-09-09 16:57 <flips> vfs, vm, whatever
2008-09-09 16:58 <RazvanM> :D
2008-09-09 17:31 <kbingham> damn... looks like 8pm your time is about 4am in uk :S
2008-09-09 17:33 <kbingham> i'll have to be a passive observer in the morning :)
2008-09-09 18:46 <flips> back
2008-09-09 18:46 <flips> what's wrong with being up at 4 a.m?
2008-09-09 19:11 <flips> mmm, a little sake and sushi to get focussed
2008-09-09 19:11 -!- vcgomes(~vcgomes@li17-238.members.linode.com) has joined #tux3
2008-09-09 19:50 -!- RazvanM(~RazvanM@pool-151-196-118-156.balt.east.verizon.net) has joined #tux3
2008-09-09 19:55 <flips> who's here and awake?
2008-09-09 19:56 <MaZe> I am ;-)
2008-09-09 19:56 <flips> that's a quorum
2008-09-09 19:56 <MaZe> mmm, sake and sushi...
2008-09-09 19:57 <flips> was good
2008-09-09 19:57 <flips> well
2008-09-09 19:57 <flips> I better heat up another one
2008-09-09 19:58 <RazvanM> 
ACTION is also awake

2008-09-09 19:59 <flips> got a browser ready?
2008-09-09 20:00 <MaZe> always...
2008-09-09 20:00 <RazvanM> lxr? :P
2008-09-09 20:00 <flips> http://lxr.linux.no/linux <- ok, open this
2008-09-09 20:00 <flips> of course
2008-09-09 20:00 <MaZe> as expected
2008-09-09 20:00 -!- RalucaME(~ral@pool-151-196-118-156.balt.east.verizon.net) has joined #tux3
2008-09-09 20:00 -!- nataliep(~nataliep@72.14.224.1) has joined #tux3
2008-09-09 20:00 <flips> hi natalie
2008-09-09 20:00 <nataliep> hi dan
2008-09-09 20:01 <flips> max, have you met natalie?
2008-09-09 20:01 <flips> maze?
2008-09-09 20:01 <MaZe> flips: http://lxr.linux.no/linux <- ok, open this
2008-09-09 20:01 <MaZe> hmm?
2008-09-09 20:01 <flips> http://lxr.linux.no/linux+v2.6.26.5/fs/open.c#L1106 <- let's start with sys_open
2008-09-09 20:02 <flips> everybody see it?
2008-09-09 20:02 <MaZe> yes - we should perhaps first ask though how many people are listnening
2008-09-09 20:02 <nataliep> 
ACTION nods

2008-09-09 20:02 <RazvanM> 
ACTION nods too

2008-09-09 20:02 <flips> 3 is fine with me
2008-09-09 20:02 <MaZe> 
ACTION nods sagely

2008-09-09 20:02 <RalucaME> nods :)
2008-09-09 20:03 <flips> it's logged anyway
2008-09-09 20:03 <MaZe> true
2008-09-09 20:03 <flips> ok, every syscall in linux starts with sys_
2008-09-09 20:03 <flips> and continues with the name you get from man
2008-09-09 20:03 <flips> so man 2 open
2008-09-09 20:03 <flips> all it does is a little linkage
2008-09-09 20:04 <flips> then real action starts in do_sys_open
2008-09-09 20:04 <flips> so lets go there by clicking on it
2008-09-09 20:04 <flips> and click on the Function link
2008-09-09 20:04 <flips> http://lxr.linux.no/linux+v2.6.26.5/fs/open.c#L1084
2008-09-09 20:04 <MaZe> why isn't sys_open isn't just a call to sys_openat(AT_FDCWD, ...)?
2008-09-09 20:04 <flips> we're still in the same file
2008-09-09 20:04 <flips> good question
2008-09-09 20:05 <flips> ask al viro and add some epithet on the end ;-)
2008-09-09 20:05 <MaZe> can sys_* never call sys_* ?
2008-09-09 20:05 <MaZe> or is this something that could be cleaned up?
2008-09-09 20:05 <flips> syscalls use a weird linkage
2008-09-09 20:05 <flips> gcc and do it, but its odd
2008-09-09 20:05 <flips> can do it
2008-09-09 20:05 <MaZe> sys_creat calls sys_open
2008-09-09 20:05 <MaZe> so it could probably be replaced
2008-09-09 20:06 <flips> I open call sys_ functions from deep in kernel
2008-09-09 20:06 <flips> often
2008-09-09 20:06 <flips> let me recant
2008-09-09 20:06 <flips> syscalls _sometimes_ use a weird linkage
2008-09-09 20:06 <flips> so yes you could nest them
2008-09-09 20:06 <flips> al doesn't for no reason I know
2008-09-09 20:07 <flips> it's like "yuck, is a nasty top level entry point"
2008-09-09 20:07 <MaZe> gcc and do it, but its odd - what did you mean?
2008-09-09 20:07 <flips> I was rambling
2008-09-09 20:07 <MaZe> ;-)
2008-09-09 20:07 <flips> the weird stuff happens before we even get there
2008-09-09 20:07 <flips> in the syscall table
2008-09-09 20:08 <MaZe> so by the time we hit sys_* we're in pure C land?
2008-09-09 20:08 <flips> #ok, so we're in a different address space than we were a nanosceond
2008-09-09 20:08 <flips> yes
2008-09-09 20:08 <flips> usually
2008-09-09 20:08 <flips> some syscalls have strange register linkage
2008-09-09 20:08 <flips> anyway the vfs doesn't much care about that
2008-09-09 20:08 <flips> it gets away from syscall land as soon as it can
2008-09-09 20:09 <flips> what we are going to see, is a lot of messing around with user addresses
2008-09-09 20:09 <flips> because a nanosecond ago or so, we were in processor ring 3
2008-09-09 20:09 <flips> userspace
2008-09-09 20:09 <flips> now we're in ring 0
2008-09-09 20:09 <flips> different address space
2008-09-09 20:09 <flips> kind of
2008-09-09 20:10 <MaZe> different priveledge level
2008-09-09 20:10 <flips> that too
2008-09-09 20:10 <flips> everthing is a little different
2008-09-09 20:10 <flips> kind of like the twilight zone
2008-09-09 20:10 <flips> we're on the inside of the glass looking out now, like in that harry potter movie
2008-09-09 20:10 <flips> ok
2008-09-09 20:10 <flips> so we have to get the name for the open
2008-09-09 20:10 <flips> it's in a different address space
2008-09-09 20:11 <flips> so we do copy_from_user to get it
2008-09-09 20:11 <flips> just looking for the def of getname
2008-09-09 20:11 <flips> it's not very interesting actually
2008-09-09 20:11 <flips> it stores the name on a full page of kernel memory
2008-09-09 20:12 <flips> or it used to
2008-09-09 20:12 <flips> now I see we use a kmem cache for it
2008-09-09 20:12 <RazvanM> http://lxr.linux.no/linux+v2.6.26.5/fs/namei.c#L141
2008-09-09 20:12 <flips> http://lxr.linux.no/linux+v2.6.26.5/include/linux/fs.h#L1615
2008-09-09 20:12 <flips> thanks
2008-09-09 20:12 <MaZe> and an audit hook
2008-09-09 20:13 <flips> things change around in here fairly frequently
2008-09-09 20:13 <flips> it's usually worth starting from the top in lxr every time
2008-09-09 20:13 <flips> just so you can check for details that changed
2008-09-09 20:13 <MaZe> by the top you mean all the way from sys_open or some other top?
2008-09-09 20:13 <flips> that audit thingy is new
2008-09-09 20:13 <flips> right
2008-09-09 20:14 <flips> like I said, getname is boring
2008-09-09 20:14 <flips> let's go back to do_ _open
2008-09-09 20:14 <MaZe> perhaps, another question: how much of a fs is driven by userspace triggered syscalls?
2008-09-09 20:14 <flips> nearly all of it
2008-09-09 20:14 <flips> particularly for traditional fs's
2008-09-09 20:14 <flips> new ones tend to have some daemons helping
2008-09-09 20:15 <flips> generally, the more daemons, the less reliable
2008-09-09 20:15 <MaZe> which are effectively kernel threads doing syscalls?
2008-09-09 20:15 <flips> not doing syscalls
2008-09-09 20:15 <flips> using internal interfaces
2008-09-09 20:15 <flips> using syscalls internally sucks, because of being in the wrong address space
2008-09-09 20:15 <flips> the syscall expects to get its data from userspace
2008-09-09 20:15 <MaZe> oh, right the copy_from_user stuff
2008-09-09 20:15 <flips> right
2008-09-09 20:16 <flips> anyway you're using syscalls internally, something linux is broken
2008-09-09 20:16 <flips> or you're stupid
2008-09-09 20:16 <MaZe> heh
2008-09-09 20:16 <flips> about 50/50
2008-09-09 20:16 <flips> the next interesting place is do_filp_open
2008-09-09 20:17 <flips> lxr is a little funky indexing some of these
2008-09-09 20:17 <MaZe> would do_filp_open be the kernel-internal interface to open?
2008-09-09 20:18 <flips> factoring is a little arbitrary
2008-09-09 20:18 <MaZe> [ie. would this be what you would call from above mentioned kernel threads/daemons?]
2008-09-09 20:18 <flips> it's another helper that happens to do almost all the work
2008-09-09 20:18 <flips> yes you can
2008-09-09 20:18 <flips> if its not static, then something is using it
2008-09-09 20:18 <flips> often something bogus
2008-09-09 20:18 <flips> something external that is
2008-09-09 20:18 <flips> not statie = part of kernel api
2008-09-09 20:19 <flips> often unwisely ;-)
2008-09-09 20:19 <flips> http://lxr.linux.no/linux+v2.6.26.5/fs/namei.c#L1761
2008-09-09 20:19 <flips> I wish lxr was smarter about finding defs of extern functions
2008-09-09 20:19 <flips> I went to usage, then to the first reference onthe list
2008-09-09 20:19 <flips> now things are happening
2008-09-09 20:20 <MaZe> [actually filp_open seems to be the kernel-interface, not that it much matters]
2008-09-09 20:20 <flips> that is true
2008-09-09 20:20 <flips> see "arbitrary factoring" above
2008-09-09 20:20 <flips> it's kind of a pile is some ways ;-)
2008-09-09 20:20 <flips> in other ways it's beautiful
2008-09-09 20:20 <flips> only about 3 of those ;-)
2008-09-09 20:21 <flips> we'll get to some scary code now
2008-09-09 20:21 <RazvanM> do_filp_open is pretty big...
2008-09-09 20:21 <flips> path_lookup_open
2008-09-09 20:22 <flips> it;'s big because it's implementing all of unix semantics + all of linux semantics + historical cruft + arcane voodooism nobody is quite sure about
2008-09-09 20:22 <RazvanM> http://lxr.linux.no/linux+v2.6.26.5/fs/namei.c#L1238
2008-09-09 20:23 <MaZe> so the vfs layer does permissions checking... not the fs itself?
2008-09-09 20:23 <flips> we're going to stay away from path lookup to avoid brain damage
2008-09-09 20:23 <flips> that is correct
2008-09-09 20:23 <flips> the vfs checks permissions and does a lot of locking too
2008-09-09 20:23 <flips> also implements the namespace caching
2008-09-09 20:23 <flips> it does a huge amount of work
2008-09-09 20:24 <MaZe> what's namespace caching?
2008-09-09 20:24 <flips> dentry cache
2008-09-09 20:24 <flips> every time you open a file, linux creates a dentry for the name
2008-09-09 20:24 <flips> that lives in cache
2008-09-09 20:24 <flips> dentry points at inode
2008-09-09 20:24 <MaZe> so what does the dentry cache map between?
2008-09-09 20:24 <flips> dentries are pretty big, inodes are pretty big memory structures too
2008-09-09 20:25 <MaZe> filename and inode (possibly lack of inode)?
2008-09-09 20:25 <flips> the dentry maps filename -> inode
2008-09-09 20:25 <flips> in cache
2008-09-09 20:25 <MaZe> does filename include full path?
2008-09-09 20:25 <flips> only when tere is a miss in the dentry cache does the vfs go to the filesystem
2008-09-09 20:25 <flips> no, not the full path
2008-09-09 20:25 <RazvanM> Important sizes:
2008-09-09 20:25 <RazvanM>         block 1024
2008-09-09 20:25 <RazvanM>         inode 300
2008-09-09 20:25 <RazvanM>         dentry 128
2008-09-09 20:25 <RazvanM>         bh 56
2008-09-09 20:25 <RazvanM>         kmem_cache 12
2008-09-09 20:25 <flips> the parent inode and the filename
2008-09-09 20:25 <MaZe> relative to the fs root?
2008-09-09 20:25 <MaZe> ah
2008-09-09 20:25 <flips> razvanm, nice
2008-09-09 20:26 <RazvanM> flips might want to correct me ;-)
2008-09-09 20:26 <flips> so every time you open a file, you get a dentry+inode+file
2008-09-09 20:26 <flips> already a lot of cache memory
2008-09-09 20:26 <flips> for a tiny thing maybe
2008-09-09 20:26 <flips> with 6 btyes in it echo hello >foo
2008-09-09 20:26 <nataliep> oh thats why it gets pretty big
2008-09-09 20:27 <flips> it's only the beginning
2008-09-09 20:27 <nataliep> among other slabs
2008-09-09 20:27 <flips> you also get an "address_space" for the inode
2008-09-09 20:27 <flips> misnamed
2008-09-09 20:27 <flips> that is the radix tree
2008-09-09 20:27 <MaZe> so if the file is opened, the dentry + inode are locked in cache?
2008-09-09 20:27 <flips> yes
2008-09-09 20:27 <flips> and the whole chain of parents
2008-09-09 20:27 <flips> up to the superblock of the fs
2008-09-09 20:27 <flips> not locked
2008-09-09 20:28 <flips> they can be evicted
2008-09-09 20:28 <MaZe> usage count increased?
2008-09-09 20:28 <flips> only until the inode goes away
2008-09-09 20:28 <flips> sorry
2008-09-09 20:28 <MaZe> you've lost me then.
2008-09-09 20:28 <flips> the inode's use count is elevated
2008-09-09 20:28 <flips> until the dentry goes away
2008-09-09 20:28 <flips> it's about the nastiest part of the whole vfs
2008-09-09 20:28 <flips> and we're here already
2008-09-09 20:29 <MaZe> so dentries can come and go as they please?
2008-09-09 20:29 <flips> what happens is, dentries spend a lot of their life sitting around in cache with zero use count
2008-09-09 20:29 <flips> that's what happens if you open a file, do something, and close it
2008-09-09 20:29 <RazvanM> $ cat /proc/slabinfo  | egrep 'dentry|#'
2008-09-09 20:29 <RazvanM> # name            <active_objs> <num_objs> <objsize> <objperslab> <pagesperslab> : tunables <limit> <batchcount> <sharedfactor> : slabdata <active_slabs> <num_slabs> <sharedavail>
2008-09-09 20:29 <RazvanM> dentry            253015 253576    132   29    1 : tunables  120   60    8 : slabdata   8744   8744      0
2008-09-09 20:29 <flips> only when the vm comes along and tries to shrink the caches to recover memory do the dentries and inodes go away
2008-09-09 20:29 <MaZe> note 132
2008-09-09 20:30 <flips> yes, something ahs been pushing stuff out
2008-09-09 20:30 <flips> it changes from time to time
2008-09-09 20:30 <flips> these days, linux pushes too much cache out at the wrong times
2008-09-09 20:30 <flips> you will notice that if you run on a slow machine
2008-09-09 20:30 <flips> see, this is the real vfs course ;-)
2008-09-09 20:31 <flips> ok, lifetime of objects in cache is one of the biggest touchy spots in linux
2008-09-09 20:31 <flips> it's often very hard to know what owns what
2008-09-09 20:31 <MaZe> there's no way to tell the vfs you're doing a bg filesystem scan and to not cache for eternity?
2008-09-09 20:31 <flips> and yet, you have to when you work on fs code
2008-09-09 20:32 <flips> there are various ways to tell it that
2008-09-09 20:32 <flips> good ways is another question
2008-09-09 20:32 <flips> we have the concept of hot and cold ends of lru list
2008-09-09 20:32 <flips> when something is gets accessed, it gets moved to the hot end
2008-09-09 20:32 <flips> and stuff is evicted from the cold end
2008-09-09 20:32 <flips> in theory
2008-09-09 20:32 <flips> in practice... well
2008-09-09 20:33 <flips> linux has been benchmarked as worse than random replacement policy
2008-09-09 20:33 <flips> somebody needs to go in and fix that
2008-09-09 20:33 <MaZe> so a queue basically
2008-09-09 20:33 <shapor> the only way i'm aware of to inform the kernel about your intentions is posix_fadvise, and that doesnt let you do much
2008-09-09 20:33 <flips> a lru list, yes
2008-09-09 20:33 <flips> acts like a queue
2008-09-09 20:33 <shapor> certainly nothing related to dentries
2008-09-09 20:33 <flips> old stuff is supposed to move down to the cold end and get evicted
2008-09-09 20:34 <flips> shapor, though you were on a plane
2008-09-09 20:34 <flips> just a sec
2008-09-09 20:34 <shapor> not yet
2008-09-09 20:34 <flips> back
2008-09-09 20:34 <MaZe> is there one global dentry cache? per cpu? per socket? per fs? per inode?
2008-09-09 20:34 <flips> ok, we're not doing vm
2008-09-09 20:34 <flips> this is vfs ;-)
2008-09-09 20:34 <RazvanM> is global, right? :P
2008-09-09 20:34 <flips> there is one global dentry cache
2008-09-09 20:35 <flips> it is indexed by fs*dir*name
2008-09-09 20:35 <flips> so it acts like one per fs
2008-09-09 20:35 <MaZe> so it maps superblock:inode:filename -> inode?
2008-09-09 20:35 <shapor> the only way i know of purging it is umount(), right flips?
2008-09-09 20:35 <flips> yes
2008-09-09 20:35 <flips> in general,yes
2008-09-09 20:35 <flips> there are internal interfaces for purging
2008-09-09 20:36 <flips> a fs has access to that
2008-09-09 20:36 <flips> but almost nobody understands how to use that or cares to find out
2008-09-09 20:36 <flips> if you get it wrong, al will bark at you
2008-09-09 20:36 <MaZe> aren't we wasting a lot of memory by continuously keeping the 'fs' in there?  most systems don't have that many mounted filesystems
2008-09-09 20:36 <flips> we waste huge buckets of memory
2008-09-09 20:37 <flips> yes, linux is a little special in this regard
2008-09-09 20:37 <flips> dentry cache is a linux only thing
2008-09-09 20:37 <flips> it gives a performance advantage in general
2008-09-09 20:37 <flips> but it uses massive gobs of memory
2008-09-09 20:37 <flips> it's tricky
2008-09-09 20:38 <flips> you can always print out the path a file was opened by
2008-09-09 20:38 <RazvanM> other OSs doesn't cache the dentries?
2008-09-09 20:38 <flips> by following parent links in the dentry cache
2008-09-09 20:38 <MaZe> I don't think other os's have dentries?
2008-09-09 20:38 <flips> I'm not _that_ familiar with bsd etc
2008-09-09 20:38 <flips> but I think not
2008-09-09 20:38 <MaZe> earlier you'd said the dentries could be evicted?
2008-09-09 20:38 <flips> the above gets interesting when the namespace topology is changing while you follow links
2008-09-09 20:39 <flips> they can
2008-09-09 20:39 <flips> let's go find the dentry cache
2008-09-09 20:39 <MaZe> so how does that match up with being able to follow the parent links in the dentry cache?
2008-09-09 20:39 <flips> <prenant pause while lxr spins>
2008-09-09 20:40 <flips> hmm, no dentry.c
2008-09-09 20:40 <RazvanM> http://lxr.linux.no/linux+v2.6.26.5/include/linux/dcache.h#L81
2008-09-09 20:40 <MaZe> there's a dcache.h
2008-09-09 20:41 <flips> ok, namei.c is the home of the dentry cache
2008-09-09 20:41 <flips> inconsistent naming
2008-09-09 20:42 <MaZe> struct dentry is defined in dcache.h though
2008-09-09 20:42 <flips> in general in linux, you want to be looking for "get" and "put" operations
2008-09-09 20:42 <flips> get means in object count, put means dec
2008-09-09 20:42 <flips> strange terminology, made in linux I think
2008-09-09 20:43 <flips> dache.c
2008-09-09 20:43 <flips> http://lxr.linux.no/linux+v2.6.26.5/fs/dcache.c
2008-09-09 20:43 <flips> so, dput
2008-09-09 20:43 <flips> http://lxr.linux.no/linux+v2.6.26.5/fs/dcache.c#L185
2008-09-09 20:44 <flips> big mess
2008-09-09 20:44 <flips> but you have to get familiar with it
2008-09-09 20:44 <flips> we also have iput, drop usage count of an inode
2008-09-09 20:45 <flips> is this too much down inthe nitty gritty?
2008-09-09 20:45 <MaZe> nope
2008-09-09 20:45 <MaZe> speaking for myself only of course - but the nitty gritty is always what I failed to grasp
2008-09-09 20:45 <flips> figuring out how an inode gets released is challenging
2008-09-09 20:46 <flips> look at iput, then iput_final
2008-09-09 20:46 <MaZe> http://lxr.linux.no/linux+v2.6.26.5/fs/inode.c#L1149
2008-09-09 20:46 <flips> generally, if the fs does not want to take care of something, the vfs will do it for it
2008-09-09 20:46 <flips> this is the case in iput_final
2008-09-09 20:47 <flips> normally, inodes are dropped by generic_drop_inode
2008-09-09 20:47 <flips> there we see some classic unix
2008-09-09 20:48 <flips> the decision whether to delete an unlinked inode or not
2008-09-09 20:48 <flips> by this time, the dentry is long gone
2008-09-09 20:48 <flips> so is the directory entry, if i_nlink is zero
2008-09-09 20:48 <flips> we're nearly done for today
2008-09-09 20:49 <MaZe> I'm a little surpised by the fact than op can be null..
2008-09-09 20:49 <flips> hour is coming up
2008-09-09 20:49 <RazvanM> we still have 10 more minutes! :D
2008-09-09 20:49 <flips> the op can be null because the vfs does it in that case
2008-09-09 20:49 <flips> I'm going to answer questions for the next 10 minutes
2008-09-09 20:49 <RazvanM> 
ACTION was about to ask about about deleting a directory

2008-09-09 20:50 <MaZe> so you than have a null op in the superblock operations and instead have it handled through such if statements all over the place?
2008-09-09 20:50 <flips> ok, let's go look a file_operations
2008-09-09 20:50 <MaZe> that seems like very non-OO
2008-09-09 20:50 <flips> maze, correy
2008-09-09 20:50 <flips> correct
2008-09-09 20:50 <flips> it's oo linux style
2008-09-09 20:50 <flips> very few linux hackers known any oo language
2008-09-09 20:50 <MaZe> is there a reason for that? that also seems worse performance wise...
2008-09-09 20:51 <MaZe> since we then have the if instead of just calling the method
2008-09-09 20:51 <flips> it doesn't cost much cpu
2008-09-09 20:51 <flips> it's sloppy
2008-09-09 20:51 <flips> and looks ugly
2008-09-09 20:51 <flips> and is inconsistent
2008-09-09 20:51 <MaZe> it's another branch that can be mispreditcted though
2008-09-09 20:51 <flips> every operation has its own custom way of doing things, usually
2008-09-09 20:51 <flips> if the branch matters, we tell the compiler not to mispredict
2008-09-09 20:52 <MaZe> ugh...
2008-09-09 20:52 <flips> see "likely/uinlikely"
2008-09-09 20:52 <flips> unlikely
2008-09-09 20:52 <MaZe> yeah, I know
2008-09-09 20:52 <flips> the inefficiencies here are somewhat covered up by the fact that there are slow disks underneath
2008-09-09 20:52 <flips> and then, it's not really inefficient
2008-09-09 20:53 <flips> the stuff that _can_ cost lots of cpu has been profiled and fixed long ago
2008-09-09 20:53 <MaZe> ok, so it's just disgusting and extra code complexity ;-)
2008-09-09 20:53 <flips> these days, it costs a lot more to contend a spinlock than mispredict a branch
2008-09-09 20:53 <flips> yes, it's fairly disgusting
2008-09-09 20:53 <flips> one never learns to love it ;-)
2008-09-09 20:53 <flips> respect it, yes
2008-09-09 20:54 <flips> it does a lot, has a huge amount of flexibility
2008-09-09 20:54 <flips> ok, there was a question
2008-09-09 20:54 <flips> let's go look at how ext2 deletes a directory
2008-09-09 20:54 <MaZe> is stuff like this not fixable?
2008-09-09 20:54 <MaZe> right, delete a directory.
2008-09-09 20:54 <flips> the right person could fix it
2008-09-09 20:54 <flips> you have to have memorized stevens
2008-09-09 20:55 <flips> and you have to like fighting in pig shit
2008-09-09 20:55 <flips> do you llike fighting in pig shit?
2008-09-09 20:55 <flips> because you have some of the other qualifications ;-)
2008-09-09 20:56 <MaZe> I have a tendency to fight uphill battles, yes.
2008-09-09 20:56 <flips> http://lxr.linux.no/linux+v2.6.26.5/fs/ext2/namei.c#L275 <- ext2_rmdir
2008-09-09 20:56 <flips> pretty easy to read
2008-09-09 20:56 <flips> and write for that matter
2008-09-09 20:56 <flips> I didn't say uphill ;-)
2008-09-09 20:56 <flips> it's not a hill
2008-09-09 20:57 <flips> it's a ditch at the bottom of the farm
2008-09-09 20:57 <RazvanM> flips: ack
2008-09-09 20:57 <MaZe> ah, but sh*t flows downhill, and if you're at the bottom
2008-09-09 20:57 <MaZe> stevens - which book is that referring to?
2008-09-09 20:57 <RazvanM> when I asked the question I did not remember that the OS will refuse to delete a non-empty dir :P
2008-09-09 20:57 <flips> ext2_rmdir is plugged into this thing: http://lxr.linux.no/linux+v2.6.26.5/fs/ext2/namei.c#L376
2008-09-09 20:57 <flips> and *_operations structure
2008-09-09 20:58 <flips> passes for an instance of a class in linux
2008-09-09 20:58 <flips>  Advanced Programming in the UNIX Environment, Addison-Wesley, 1992.
2008-09-09 20:59 <flips> ok, now that we have found what ext2_rmdir is plugged into, we can follow it back up into the vfs
2008-09-09 20:59 <flips> clock on ext2_dir_inode_operations
2008-09-09 21:00 <flips> sorry
2008-09-09 21:00 <flips> clock on inode_operations
2008-09-09 21:00 <RazvanM> http://lxr.linux.no/linux+v2.6.26.5/include/linux/fs.h#L1250
2008-09-09 21:00 <flips> then usage
2008-09-09 21:01 <flips> lxr is spinning
2008-09-09 21:01 <RazvanM> this is the slowest operations...
2008-09-09 21:01 <flips> yes, and 3 doing it at the same time is enough to bring it to its knees
2008-09-09 21:01 <flips> apparently
2008-09-09 21:02 <RazvanM> actually, I would say is as slow as usual
2008-09-09 21:02 <flips> as you can see, this is a popular struct
2008-09-09 21:02 <RazvanM> true
2008-09-09 21:02 <flips> your are looking for the instances that are _not_ in a specific filesystem
2008-09-09 21:03 <flips>  fs/namei.c, line 2971
2008-09-09 21:03 <flips> for example
2008-09-09 21:03 <flips> whoops, not interesting
2008-09-09 21:03 <MaZe> bad_inode.c inode.c libfs.c
2008-09-09 21:03 <flips> razvanm probably had the right idea
2008-09-09 21:04 <flips> yes, inode.c is good
2008-09-09 21:04 <RazvanM> http://lxr.linux.no/linux+v2.6.26.5/fs/inode.c#L114
2008-09-09 21:05 <RazvanM> uhh... we're 5 minutes over time :P
2008-09-09 21:05 <RazvanM> 
ACTION says big thanks!

2008-09-09 21:05 <MaZe> ;-)
2008-09-09 21:05 <flips> yep
2008-09-09 21:05 <flips> so homework:
2008-09-09 21:05 <flips> find out were inode_operations->rmdir is called
2008-09-09 21:06 <flips> it isn't spelled that way
2008-09-09 21:06 <flips> this is what makes linux fun ;-)
2008-09-09 21:06 <flips> very little is spelled the way you would expect
2008-09-09 21:06 <RazvanM> :D
2008-09-09 21:06 <flips> ok, did we have fun today?
2008-09-09 21:06 <nataliep>  that was awesome, too short :) thanks to all... i love the format of this class :)
2008-09-09 21:06 <RazvanM> 
ACTION did had fun :-)

2008-09-09 21:07 <flips> thanks natalie :-)
2008-09-09 21:07 <RalucaME> thanx flips, was cool
2008-09-09 21:07 <flips> the most important item is how to navigate lxr
2008-09-09 21:07 <flips> welcome, ralucame
2008-09-09 21:07 <RazvanM> 
ACTION is RalucaME's twin ;-)

2008-09-09 21:07 <RalucaME> :)
2008-09-09 21:07 <MaZe> where it's called from outside of fs'es? or within?
2008-09-09 21:08 <MaZe> way too short - agreed.
2008-09-09 21:08 <MaZe> at this rate we'll need more than a few of these ;-)
2008-09-09 21:08 <MaZe> Thanks!
2008-09-09 21:08 <flips> aha
2008-09-09 21:08 <flips> from the vfs
2008-09-09 21:08 <flips> that is, outside the fs
2008-09-09 21:08 <flips> things eventually start to fit a pattern
2008-09-09 21:09 <flips> and you don't need me to suggest how to follow the twisty paths any more
2008-09-09 21:09 <flips> at first it looks like random gibberish
2008-09-09 21:09 <flips> then later, you learn it is actually random gibberish
2008-09-09 21:09 <RazvanM> :-)
2008-09-09 21:09 <flips> but it is fast and flexible gibberish
2008-09-09 21:09 <MaZe> flips: i_op->rmdir ?
2008-09-09 21:10 <flips> sounds good
2008-09-09 21:10 <MaZe> ups ;-)
2008-09-09 21:10 <nataliep> aww 
2008-09-09 21:10 <flips> I personally always spell my ops "ops"
2008-09-09 21:10 <flips> makes it much easier to navitage
2008-09-09 21:10 <flips> so you look for ops->rmdir and you always find it
2008-09-09 21:11 <MaZe> the code was "inode->i_op = &empty_iops;" in alloc_inode
2008-09-09 21:11 <flips> boring
2008-09-09 21:11 <flips> haven't found the real one nwo
2008-09-09 21:11 <flips> yet I mean
2008-09-09 21:12 <RazvanM> http://lxr.linux.no/linux+v2.6.26.5/fs/namei.c#L2256
2008-09-09 21:13 <flips> that's it
2008-09-09 21:13 <flips> gold star
2008-09-09 21:14 <RazvanM> :P
2008-09-09 21:16 <MaZe> oh, lol
2008-09-09 21:16 <nataliep> more homework?
2008-09-09 21:16 <MaZe> and I just sent it via pm
2008-09-09 21:16 <flips> figure out how a struct inode gets deleted ;-)
2008-09-09 21:17 <RazvanM> 
ACTION will do pm next time

2008-09-09 21:17 <MaZe> wild guess: iput gets called?
2008-09-09 21:17 <flips> thursday again ok?
2008-09-09 21:17 <MaZe> at 8pm?
2008-09-09 21:17 <flips> maze, that's a good first order approximation
2008-09-09 21:17 <flips> yes
2008-09-09 21:17 <nataliep> sounds good
2008-09-09 21:18 <MaZe> see you then!
2008-09-09 21:19 <flips> cu
2008-09-09 21:41 -!- nataliep(~nataliep@72.14.224.1) has left #tux3
2008-09-09 22:09 -!- pranith(~ca4bcee2@66.90.73.223) has joined #tux3
2008-09-09 22:14 -!- pranith(~ca4bcee2@66.90.73.223) has joined #tux3
2008-09-09 22:15 <pranith> hello
2008-09-09 22:15 <pranith> anyone here?
2008-09-09 22:21 <flips> hi
2008-09-09 22:23 <pranith> hi flips
2008-09-09 22:23 <flips> what's up?
2008-09-09 22:23 <pranith> are u daniel phillips?
2008-09-09 22:23 <flips> yes
2008-09-09 22:24 <pranith> ok, i mailed you yesterday about tux3 :)
2008-09-09 22:24 <flips> I remember
2008-09-09 22:24 <flips> welcome to #tux3
2008-09-09 22:24 <pranith> thank you :)
2008-09-09 22:24 <flips> have you been reading the mailing list archives?
2008-09-09 22:24 <pranith> hmm, not much actually
2008-09-09 22:25 <flips> that is a very good place to start
2008-09-09 22:25 <pranith> im joining it now..
2008-09-09 22:25 <flips> http://tux3.org/pipermail/tux3/
2008-09-09 22:26 <pranith> ok
2008-09-09 22:28 <pranith> flips, any particular mail you want me to start with?
2008-09-09 22:28 <flips> any order
2008-09-09 22:28 <flips> just poke around until you find one that interests yhou
2008-09-09 22:29 <flips> and follow the thread
2008-09-09 22:29 <flips> see what people are doing
2008-09-09 22:29 <flips> the fuse stuff is very interesting
2008-09-09 22:29 <pranith> ok
2008-09-09 22:35 <flips> excellent ramen
2008-09-09 22:35 <flips> that japanese store wasn't kidding when they said it was "a little spicy"
2008-09-09 22:36 <pranith> hmm
2008-09-09 22:46 <pranith> flips, do u think i need to have some background about file systems to start with?
2008-09-09 22:46 <flips> always helpful
2008-09-09 22:46 <pranith> as i mentioned, i've just recently started going throught the design book...
2008-09-09 22:46 <flips> there is a lot written on it
2008-09-09 22:47 <flips> a linux specific book would be good too
2008-09-09 22:47 <flips> I never read the beos book
2008-09-09 22:47 <flips> or any book on filesystem design ;-)
2008-09-09 22:47 <pranith> i couldn't find any linux specific os book :(
2008-09-09 22:47 <pranith> filesystem*
2008-09-09 22:47 <flips> "understanding the linux kernel"
2008-09-09 22:47 <flips> probably best for this
2008-09-09 22:48 <pranith> for filesystems?
2008-09-09 22:48 <flips> wikipedia is good too
2008-09-09 22:48 <flips> yes
2008-09-09 22:48 <pranith> ok
2008-09-09 22:48 <flips> http://www.yolinux.com/TUTORIALS/LinuxClustersAndFileSystems.html
2008-09-09 22:48 <pranith> any concepts i need to pay particular attention to?
2008-09-09 22:48 <flips> vfs
2008-09-09 22:48 <flips> locking
2008-09-09 22:48 <flips> struct bio
2008-09-09 22:49 <flips> struct page
2008-09-09 22:49 <flips> struct inode
2008-09-09 22:49 <flips> struct dentry
2008-09-09 22:49 <flips> struct buffer_head
2008-09-09 22:50 <flips> http://en.wikipedia.org/wiki/Filesystem
2008-09-09 22:50 <flips> http://en.wikipedia.org/wiki/Ext2
2008-09-09 22:50 <flips> http://en.wikipedia.org/wiki/Ext3
2008-09-09 22:51 <flips> http://en.wikipedia.org/wiki/Journaling_file_system
2008-09-09 22:51 <flips> http://en.wikipedia.org/wiki/Comparison_of_file_systems
2008-09-09 22:51 <flips> http://en.wikipedia.org/wiki/ACID
2008-09-09 22:51 <flips> <- very important
2008-09-09 22:51 <pranith> hmm, ACID? first time i'm hearing about this
2008-09-09 22:52 <flips> it is the most important concept of all
2008-09-09 22:52 <pranith> ohk, i knew abt these. just never heard the term ACID :)
2008-09-09 22:53 <pranith> knew in the sense, i heard abt them. not "know" knowing :)
2008-09-09 22:53 <flips> need to memorize those concepts
2008-09-09 22:53 <pranith> ok
2008-09-09 23:14 <flips> feh I just got bitten by the stupid ext2 convention than zero inode means deleted entry
2008-09-09 23:14 <flips> what's the matter with having an inode numbered zero again?
2008-09-09 23:14 <pranith> zero inode?
2008-09-09 23:14 <flips> inum = 0
2008-09-09 23:15 <pranith> hmm
2008-09-09 23:15 <flips> that's what ext2 uses to determine a dirent is deleted
2008-09-09 23:15 <flips> a little better than DOS, which sets the first character of the filename to 'e'
2008-09-09 23:15 <flips> but not much
2008-09-09 23:16 <flips> why not rely on name_len = zero instead?
2008-09-09 23:16 <flips> dumb
2008-09-09 23:16 <flips> I might change that for tux3
2008-09-09 23:16 <pranith> u better do :)
2008-09-09 23:17 <flips> can't call it ext2_create_entry any more then ;-)
2008-09-09 23:17 <flips> so far it's exactly compatible
2008-09-09 23:17 <flips> but this is annoying
2008-09-09 23:18 <flips> I think I will at least create an is_deleted macro
2008-09-09 23:18 <flips> everywhere it relies on inum = 0
2008-09-09 23:18 <pranith> might sound stupid, but i dont know.. whats the need for a deleted dirent?
2008-09-09 23:18 <flips> so you can recover the space to use for some other filename
2008-09-09 23:19 <pranith> isn't that recovered during deletion time?
2008-09-09 23:19 <flips> that's the code I'm working on
2008-09-09 23:20 <pranith> oh! :)
2008-09-09 23:20 <pranith> and inum is what? the number of inodes?
2008-09-09 23:22 <flips> static inline int is_deleted(ext2_dirent *dirent)
2008-09-09 23:22 <flips> {
2008-09-09 23:22 <flips> 	return !dirent->inum;
2008-09-09 23:22 <flips> }
2008-09-09 23:23 <pranith> hmm
2008-09-09 23:23 <pranith> thats nice
2008-09-09 23:45 -!- cdk(~chinmay@121.246.36.139) has joined #tux3
2008-09-09 23:46 <flips> can now find/create xattr atoms in the atom table
2008-09-09 23:46 <flips> enough for today
2008-09-09 23:48 <pranith> sleeping?
2008-09-09 23:50 <flips> soon
2008-09-09 23:57 <pranith> which place?
2008-09-09 23:59 <flips> santa monica, CA
2008-09-09 23:59 <flips> and you?