2008-09-10 00:09 <pranith> new delhi, india
2008-09-10 00:10 <pranith> what do you do?
2008-09-10 00:13 <bh> hey
2008-09-10 00:14 <flips> hi bh
2008-09-10 00:23 <flips> johns hopkins
2008-09-10 00:23 <flips> u
2008-09-10 00:24 <flips> wrong channel
2008-09-10 00:35 <pranith> hmm
2008-09-10 00:35 <pranith> u work at johns hopkins?
2008-09-10 00:37 <flips> no, in santa monica
2008-09-10 00:37 <flips> linux kernel hacker
2008-09-10 00:37 <flips> time to sleep
2008-09-10 00:37 <flips> see you later
2008-09-10 00:50 <pranith> :)
2008-09-10 00:50 <pranith> goodnite
2008-09-10 01:52 -!- kbingham(~kbingham@92.0.11.166) has joined #tux3
2008-09-10 03:13 -!- kbingham(~kbingham@193.132.141.186) has joined #tux3
2008-09-10 06:07 -!- stargazr5(~gauravstt@59.95.3.98) has joined #tux3
2008-09-10 07:02 -!- stargazr5(~gauravstt@59.95.35.187) has joined #tux3
2008-09-10 08:03 -!- RzM|Away(~RazvanM@pool-151-196-118-156.balt.east.verizon.net) has joined #tux3
2008-09-10 09:28 -!- RazvanM(~RazvanM@dazzler.isi.jhu.edu) has joined #tux3
2008-09-10 10:36 -!- Kirantpatil(~kiran@122.167.179.145) has joined #tux3
2008-09-10 10:37 -!- Kirantpatil(~kiran@122.167.179.145) has left #tux3
2008-09-10 11:19 -!- Bobby(~Bobby@122.160.64.177) has joined #tux3
2008-09-10 11:19 <Bobby> hello
2008-09-10 11:25 -!- Bobby(~Bobby@122.160.64.177) has joined #tux3
2008-09-10 11:51 -!- Bobby(~Bobby@122.160.64.177) has joined #tux3
2008-09-10 12:19 <flips> morning
2008-09-10 12:35 <konrad> reading the lesson from last night
2008-09-10 12:35 <flips> test of fire
2008-09-10 12:49 <flips> int set_xattr(struct inode *inode, char *name, unsigned len, void *data, unsigned size)
2008-09-10 12:49 <flips> {
2008-09-10 12:49 <flips> 	atom_t atom = get_atom(inode->sb->atable, name, len);
2008-09-10 12:49 <flips> 	return xcache_update(inode, atom, data, len);
2008-09-10 12:49 <flips> }
2008-09-10 12:49 <flips> short and sweet?
2008-09-10 12:51 <konrad> yes
2008-09-10 12:52 <konrad> should that be xcache_update(inode, atom, data, size)?
2008-09-10 12:54 <flips> it should
2008-09-10 12:54 <flips> now is
2008-09-10 12:55 <flips> was originally going to be namelen and datalen
2008-09-10 12:55 <flips> it reads better as it is now
2008-09-10 12:55 <flips> now lets see if it works
2008-09-10 12:57 <flips> the test sets xattrs on the atom table directory inode
2008-09-10 12:58 <flips> it works
2008-09-10 12:58 <flips> 	set_xattr(inode, "foo", 3, "bar", 3);
2008-09-10 12:58 <flips> 	xcache_dump(inode);
2008-09-10 12:58 <flips> xattr 1: 0x8050fc8:  62 61 72                                          "bar"
2008-09-10 12:58 <flips> the test would have passed even with the bug above ;-)
2008-09-10 13:10 -!- kbingham(~kbingham@92.20.206.84) has joined #tux3
2008-09-10 13:14 <flips> next step is to get xattrs on/off disk
2008-09-10 13:28 <flips> notice in the above factoring we can easily have multiple atom tables
2008-09-10 13:28 <flips> I wonder what that is good for
2008-09-10 13:28 <flips> multiple xattr namespaces
2008-09-10 13:31 -!- kbingham(~kbingham@92.22.74.132) has joined #tux3
2008-09-10 13:35 <flips> "Stasticially speaking, the part of your disk that loses data is probably in the movies that suck, not the movies that are good, simply because the vast majority of movies suck. " -- http://alumnit.ca/~apenwarr/log/?m=200809#08
2008-09-10 13:35 <flips> wiser words were seldom spoken
2008-09-10 13:43 <bh> 
ACTION discusses concurrency issues with flips 

2008-09-10 13:45 <bh> thinking about how'd I parallelize b-tree operations
2008-09-10 13:47 <flips> righto
2008-09-10 13:48 <flips> first obvious invariant: lock acquisition order is root-to-leaf
2008-09-10 13:49 <flips> obvious optimization rule: nodes near the root must not stay locked for long periods, including never locked across a read of disk data, other than the data of the ndoe itself
2008-09-10 13:51 <flips> nuther obvious one: no holding of locks above a node being read from disk
2008-09-10 13:51 <flips> this one is kinda tough sometimes, in cases like rename where the vfs holds locks
2008-09-10 13:59 <flips> here's a subtle and important one: subtrees below a locked node can be locked by another process, this is normal and important for throughput
2008-09-10 14:00 <flips> time for another hit of that excellent ramen
2008-09-10 14:28 <flips> hmm, I should probably stop put contributers email addys in the first line of the log
2008-09-10 14:28 <flips> where spambots can get them
2008-09-10 14:29 <flips> second line is most likely ok, it's the contributers call: do they want fame + spam? or just satisfaction?
2008-09-10 14:29 <flips> personally I try to err on the side of fame and have efficient spam filters
2008-09-10 14:31 <konrad> my email is in tons of public places already, I've already got decent spam filters
2008-09-10 14:33 <konrad> finished reading through last night's lesson
2008-09-10 14:33 <konrad> and accompanying lxr pages
2008-09-10 14:34 <flips> and?
2008-09-10 14:35 <flips> 
ACTION can confirm that this ramien is excellent

2008-09-10 14:37 <konrad> so my question (maybe it's stupid): what is an inode?
2008-09-10 14:37 <konrad> my current guess is 'an in-memory representation of the stuff surrounding a file, except for the contents'
2008-09-10 14:38 <flips> it's two or three things that are often conflated
2008-09-10 14:39 <flips> 1) (the real def) it is a structure that caches the details of a filesystem object or device object in the vfs
2008-09-10 14:39 <flips> 2) it is the image of an above object in file store
2008-09-10 14:40 <flips> 3) it is the numeric id of the backing store image of an inode
2008-09-10 14:40 <flips> actually, 0) it is an object that caches all the data and attributes of a filesystem object or system device
2008-09-10 14:41 <flips> the notion of object being separate from how it is cached or stored
2008-09-10 14:41 <flips> so you guess is close to the mark
2008-09-10 14:41 <flips> very close
2008-09-10 14:41 <konrad> alright
2008-09-10 14:41 <flips> in tux3, sometimes caches the contents as well
2008-09-10 14:42 <flips> well
2008-09-10 14:42 <flips> always caches the contents
2008-09-10 14:42 <flips> because it points at a "mapping"
2008-09-10 14:42 <flips> which is a radix tree that points at the cached pages of the data of the inode
2008-09-10 14:43 <flips> also caches the xattr data, which in tux3 is nearly the same as the file data
2008-09-10 14:43 <konrad> heh
2008-09-10 14:43 <konrad> how does ext[234] and friends handle xattr data and quotas?
2008-09-10 14:44 <flips> weirdly
2008-09-10 14:44 <flips> in both cases
2008-09-10 14:44 <flips> read ext3/xattr.c
2008-09-10 14:44 <konrad> going
2008-09-10 14:45 <flips> tries to pack xattrs for different inodes together in blocks, then notice when entire xattr blocks are the same and have multiple pointers to them from different inodes
2008-09-10 14:45 <flips> quotas are done through this awful vfs-level abstraction
2008-09-10 14:45 <flips> quota files
2008-09-10 14:45 <flips> a real mess
2008-09-10 14:45 <flips> wrong idea
2008-09-10 14:46 <flips> I am not sure whether there is any connection between xaddrs and quota in ext*
2008-09-10 14:47 <flips> actually, the vfs thoughtfully provides a bypass around the quota file mess so a filesystem that wants to do it right can do so
2008-09-10 14:47 <flips> don't know if anybody uses that bypass
2008-09-10 14:52 <konrad> for ext3: All attributes must fit in the inode and one additional block.
2008-09-10 14:55 <flips> right. lame.
2008-09-10 14:56 <konrad> heh.
2008-09-10 14:57 <flips> tux3 goes at it more like HFS file fork
2008-09-10 14:57 <konrad> ext3 uses the macros le32_to_cpu (and equivalently for tux3, be??_to_cpu)
2008-09-10 14:57 <flips> strangely, macos doesn't do xattrs like file forks, it limits them like ext*
2008-09-10 14:57 <flips> I'm going to respell those I think
2008-09-10 14:57 <flips> they're clunky
2008-09-10 14:58 <flips> from_be_u32 and to_be_u32 <- less clunky
2008-09-10 14:59 <flips> or from_beu32 and to_beu32
2008-09-10 15:00 <flips> or from_u32b and to_u32b
2008-09-10 15:00 <flips> vs from_u32l and to_u32l
2008-09-10 15:00 <flips> or from_u32be and to_u32be
2008-09-10 15:00 <flips> vs from_u32le and to_u32le
2008-09-10 15:01 <flips> not quite decided
2008-09-10 15:01 <flips> but probably will do a big spam edit in the next couple of days to make it better than it is
2008-09-10 15:01 <flips> we have a lot of endian work ahead of us and the inlines should support it, not get i n the way
2008-09-10 15:03 <flips> from_beu32 and to_beu32 <- this is probably the form that is the easiest the edit and least likely to offend kernel hacks
2008-09-10 15:03 <flips> easist to edit I mean
2008-09-10 15:04 <flips> in kernel they will likely just be #defined to be the kernel faves
2008-09-10 15:04 <flips> it's pathetic that gcc doesn't just make this an attribute
2008-09-10 15:56 <MaZe> my vote:
2008-09-10 15:56 <MaZe>  from_u32be and to_u32be
2008-09-10 15:57 <flips> ok
2008-09-10 15:57 <MaZe> seems easiest to read
2008-09-10 15:57 <flips> I think yours is the casting vote because you are the only one who voted
2008-09-10 15:57 <MaZe> ;-)
2008-09-10 15:59 <MaZe> I know there's already been tons of discussion about C++ in the kernel, but sometimes, some aspects of it (OO, private fields, accessors) would make the interfaces so much cleaner...
2008-09-10 15:59 <MaZe> it's too bad some sort of OO shim can't be included in C
2008-09-10 16:00 <flips> really
2008-09-10 16:00 <flips> too bad the C and C++ camps don't even speak to each other any more
2008-09-10 16:00 <flips> feel free to write a chunk of tux3 in c++ if you want
2008-09-10 16:00 <flips> for example, tux3.c
2008-09-10 16:01 <flips> c++ desperately needs designated initializers
2008-09-10 16:13 <flips> maze, there ya go
2008-09-10 16:14 <MaZe> hmm? what do you mean?
2008-09-10 16:14 <flips> I see that the tux3 announcement is more popular than the 2.6.24.4 announcement on lkml.org
2008-09-10 16:14 <flips> endian conversions respelled according to your taste
2008-09-10 16:14 <MaZe> 2.6.24.7 was out already ;-)
2008-09-10 16:14 <MaZe> oh, right , cool!
2008-09-10 16:14 <MaZe> so you probably mean 2.6.26.4 which was a screw up and was soon 2.6.26.5
2008-09-10 16:15 <flips> heh
2008-09-10 16:15 <flips> you'd think that would make the announcement even more popular
2008-09-10 16:15 <flips> what was the screw up?
2008-09-10 16:15 <MaZe> it didn't compile ;-)
2008-09-10 16:16 <flips> wow
2008-09-10 16:16 <flips> really?
2008-09-10 16:16 <flips> how could that happen
2008-09-10 16:16 <MaZe> at least some relativelly important option
2008-09-10 16:16 <flips> we should donate gregkh a computer
2008-09-10 16:16 <MaZe> http://kernel.org/pub/linux/kernel/v2.6/ChangeLog-2.6.26.5
2008-09-10 16:17 <flips> there's a build option exactly to catch stuff like that
2008-09-10 16:17 <flips> and... how about trying to build before posting?
2008-09-10 16:17 <flips> not that I always do it
2008-09-10 16:17 <MaZe> oh, at least he fixed it by releasing a new number
2008-09-10 16:18 <flips> the the consequences of messing that up are less far reaching with tux3 than stable linux
2008-09-10 16:18 <MaZe> I've got some best-left-unnamed teams that like to release bugfixed version of sw with the same version number
2008-09-10 16:18 <flips> right, and hundreds or thousands of people who innocently download the screwup will be confused and/or annoyed
2008-09-10 16:19 <MaZe> people don't download that quickly
2008-09-10 16:19 <flips> because one of the things gregkh also doesn't do, is rename screwups as -dontuse
2008-09-10 16:19 <MaZe> it was fixed in 6 hours
2008-09-10 16:19 <flips> yes they do
2008-09-10 16:19 <MaZe> most people pick it up through the distros
2008-09-10 16:19 <flips> check out the load spikes on lkml.org
2008-09-10 16:19 <flips> sorry
2008-09-10 16:19 <flips> kernel.org
2008-09-10 16:19 <MaZe> I'm still running 2.6.26.3 and waiting for a reboot to hit 2.6.26.5...
2008-09-10 16:20 <MaZe> with even my laptop getting average uptimes of 3-4 weeks, reboots ain't that often, so upgrades ain't that often
2008-09-10 16:20 <flips> behind ;-)
2008-09-10 16:20 <flips> I won't mention what I'm running ;-)
2008-09-10 16:20 <flips> my workstation is also the tux3.org server
2008-09-10 16:20 <MaZe> I really want 2.6.27.1 to come out though
2008-09-10 16:20 <flips> so I don't reboot much
2008-09-10 16:20 <konrad> heh
2008-09-10 16:20 <flips> or try the latest flights of fancy of kernel devs to soon
2008-09-10 16:20 <MaZe> the wireless driver ath9k should fix a lot of my wireless woes
2008-09-10 16:21 <flips> me too
2008-09-10 16:21 <MaZe> <- notice the 2.6.27.1 ;-) when 2.6.27 isn't out yet
2008-09-10 16:21 <MaZe> I figure once 2.6.27.1 is out 2.6.27 shouldn't eat your data anymore
2008-09-10 16:21 <flips> looking forward to it with almost as much anticipation as an open ati driver that performs better than 50% as well as the bespoke one
2008-09-10 16:21 <flips> heh
2008-09-10 16:22 <MaZe> I did upgrade to 2.6.27rc3 and I'm not sure whether it was ath9k, or 2.6.27 or a bad build
2008-09-10 16:22 <flips> ok, have to do something about a haircut now
2008-09-10 16:22 <MaZe> or bad config options
2008-09-10 16:22 <flips> before jumping back in and finishing up adding xattr support to tux3.c
2008-09-10 16:22 <MaZe> but it promptly ran out of swiotlb buffers and corrupted my hard disk
2008-09-10 16:23 <flips> my ath woes are taken care of by having an eee
2008-09-10 16:23 <MaZe> spent a weekend recovering... thankfully had a one week old backup (earlier that week my laptop stopped booting...)
2008-09-10 16:23 <flips> they messed with setting up the binary/evil driver
2008-09-10 16:23 <flips> works great
2008-09-10 16:23 <flips> course I've got a bunch of other aths around taht would benefit
2008-09-10 16:23 <flips> my wife's machine for example
2008-09-10 16:24 <MaZe> I'm using madwifi drivers now on a macbook pro 3,1 - they work, but occasionally they disconnect, and you need to unload and reload the entire wireless stack
2008-09-10 16:24 <flips> which has a wire running into it because I don't have the energy to mess with the braindamanged firmware laod
2008-09-10 16:24 <flips> madwifi has been solid as a rock for me in the 4-5 years I've used it
2008-09-10 16:24 <flips> on a pci wireless
2008-09-10 16:25 <MaZe> I have a 'fix-wireless.sh' running in an xterm - it pings default gateway, if it's unreachable for 5 seconds, then prompty shuts down dhcpc/wpa_supplicant/wireless and brings it all back up - best part is you don't even lose existing established network conenctions (ssh, etc)
2008-09-10 16:26 <MaZe> it's still annoying though, because you occasionally get these 15 second pauses (happens maybe once an hour)
2008-09-10 16:26 <flips> :p
2008-09-10 16:27 <flips> I was running a very old incarnation of madwifi
2008-09-10 16:27 <flips> likely some value in that
2008-09-10 16:27 <flips> couldn't get the latest working after trying for an hour or so, so just plugged in the wire
2008-09-10 16:27 <flips> which is way faster anyway
2008-09-10 16:28 <MaZe> agreed, you want wired for everything stationary
2008-09-10 16:28 <MaZe> laptops aren't stationary though...
2008-09-10 16:29 <flips> right, which is why I love my eee
2008-09-10 16:29 <flips> don't have to worry about a thing, somebody else does
2008-09-10 16:30 <flips> not to mention the fact that it fits comfortably in the flap of my camera backpack
2008-09-10 16:32 <MaZe> it runs linux?
2008-09-10 16:32 <flips> yes
2008-09-10 16:32 <flips> beautifully
2008-09-10 16:32 <MaZe> by default?
2008-09-10 16:33 <flips> everybody loves it here
2008-09-10 16:33 <flips> yes
2008-09-10 16:33 <MaZe> hmm
2008-09-10 16:33 <flips> funny thing is, the linux and windows versions cost the same, but you get 20G of flash disk with linux and only 12G with XP
2008-09-10 16:33 <flips> 901 is the one to get
2008-09-10 16:34 <flips> I have the 900 and I'll probably pick up a 901 pretty soon
2008-09-10 16:34 <flips> need more than one for this family
2008-09-10 16:40 <flips> tux3 has bloated up to ~6,500 lines of .c + .h, sparsely commented and densely written, including unit tests
2008-09-10 16:41 <flips> so I think the kernel port will come in around 10K lines, complete with versioning, commit transactions and shiny new directory index
2008-09-10 16:41 <flips> about 1-2 months away from knowing
2008-09-10 16:41 <flips> depends a lot on how tux3 university goes ;-)
2008-09-10 16:52 <flips> http://userweb.kernel.org/~warthog9/damaged_server/ <- wow
2008-09-10 16:52 <flips> I'll think twice about using fedex
2008-09-10 16:57 <flips> sk8 oclock
2008-09-10 17:03 <konrad> ouch
2008-09-10 17:03 <konrad> are you counting the somewhat redundant tux3fuse/tux3fs in those 6500?
2008-09-10 18:30 -!- MaZe(~MaZe@216-239-45-4.google.com) has joined #tux3
2008-09-10 18:51 -!- nataliep_(~nataliep@66-102-14-1.google.com) has joined #tux3
2008-09-10 19:22 <RazvanM> 
ACTION just realized that the next tux3 university is tomorrow and not today :P

2008-09-10 19:49 <flips> konrad, yes
2008-09-10 19:49 <flips> konrad, it was a joke
2008-09-10 19:49 <flips> 6,500 lines at this point is really tight
2008-09-10 19:50 <flips> also includes the buffer and page cache emulation
2008-09-10 19:51 <flips> and none of tux3.c belongs in kernel, though it is probably the base on which tux3 mkfs and fsck will be built
2008-09-10 19:54 <flips> incidentally, that is about 1,000 lines/week
2008-09-10 19:54 <flips> a respectable pace
2008-09-10 19:55 <flips> especially considering the rewrite ratio is really high
2008-09-10 19:56 <flips> 
ACTION extracts the cork from a bottle of cabernet

2008-09-10 19:57 <flips> nice um, tasty california wine to go with the pasta
2008-09-10 19:57 <flips> unpretentious, unsophisticated, gives you its phone number right away
2008-09-10 19:58 <flips> top note of jelly beans
2008-09-10 20:55 <flips> next, inode.c need to know about loading and saving xattrs
2008-09-10 21:29 <bh> flips: very respectable
2008-09-10 21:29 <bh> especially if it all works
2008-09-10 21:30 <flips> the babernet worked fine
2008-09-10 21:30 <flips> cabernet
2008-09-10 21:30 <flips> <- proof
2008-09-10 21:30 <flips> 
ACTION has to arrange another cabal meeting

2008-09-10 21:31 <flips> bh, when you up here next?
2008-09-10 21:32 <bh> don't know
2008-09-10 21:32 <bh> I mean, really any time I want
2008-09-10 21:32 <flips> doesn't take long for san diego does it?
2008-09-10 21:32 <flips> right
2008-09-10 21:32 <bh> you'e not that far away
2008-09-10 21:32 <flips> I'll ping you when the next cabernet meeting comes up
2008-09-10 21:33 <bh> cabernet ?
2008-09-10 21:33 <flips> err
2008-09-10 21:33 <flips> cabal ;-)
2008-09-10 21:33 <flips> my tastes run more to bordeaux at cabal meetings
2008-09-10 21:33 <flips> or sake
2008-09-10 21:33 <bh> sorry, oh ok, well, that would be great. Did one happen today ?
2008-09-10 21:33 <flips> no, last was a week or so ago
2008-09-10 21:33 <bh> who came ?
2008-09-10 21:33 <flips> can't say, it's a cabal
2008-09-10 21:34 <flips> good peeps
2008-09-10 21:34 <bh> ok
2008-09-10 22:08 -!- RazvanM(~RazvanM@pool-151-196-118-156.balt.east.verizon.net) has joined #tux3
2008-09-10 22:19 -!- stargazr5(~gauravstt@59.95.19.195) has joined #tux3
2008-09-10 22:54 -!- pgquiles(~pgquiles@253.Red-83-44-239.dynamicIP.rima-tde.net) has joined #tux3