2008-08-24 02:41 <flips> 88 interested observers on the mailing list
2008-08-24 02:42 <flips> needs to translate into more commentary
2008-08-24 04:17 -!- pgquiles(~pgquiles@239.Red-83-41-113.dynamicIP.rima-tde.net) has joined #tux3
2008-08-24 04:21 <bh> flips: is lvm3 extent aware ?
2008-08-24 04:21 <flips> lvm4 is
2008-08-24 04:22 <flips> um
2008-08-24 04:22 <flips> sorry!
2008-08-24 04:22 <flips> it is just a block device
2008-08-24 04:22 <bh> hey, nice to see that you're awake now
2008-08-24 04:22 <flips> that means you throw bio structs at it
2008-08-24 04:22 <bh> 
ACTION just finished clubbing around San Francisco

2008-08-24 04:22 <bh> I sped thorugh LA today to get up there
2008-08-24 04:22 <bh> here
2008-08-24 04:22 <flips> 
ACTION got back from death race 2000 not too long ago

2008-08-24 04:23 <bh> I would have stopped if I had time, beside we saw each other not that long ago
2008-08-24 04:23 <bh> what is that ?
2008-08-24 04:23 <flips> bios are kinda like extents
2008-08-24 04:23 <flips> beyond that, lvm knows nothing about it
2008-08-24 04:23 <bh> so does that mean that the sha1 hash can be done a per extent basis in lvm4 ?
2008-08-24 04:23 <flips> it has a concept called extents
2008-08-24 04:23 <flips> but it isn't extents
2008-08-24 04:23 <flips> it is just fixed size multiples of the lvm allocation unit
2008-08-24 04:23 <bh> what the purpose of putting that in the raid layer ?
2008-08-24 04:24 <flips> there is no lvm4, I mispoke
2008-08-24 04:24 <flips> sha1 is a stupid hash to use
2008-08-24 04:24 <flips> it is ridiculously expensive to compute
2008-08-24 04:24 <flips> we're not doing crypto
2008-08-24 04:25 <flips> oh
2008-08-24 04:25 <flips> but you were thinking about hashed storage
2008-08-24 04:25 <flips> that is, content addressed storage
2008-08-24 04:25 <flips> sha1 is still pretty extravagant
2008-08-24 04:26 <flips> anyway, why the raid layer vs below it?
2008-08-24 04:26 <flips> don't know
2008-08-24 04:26 <flips> you have to reassemble your raid bits to do your content hash on them
2008-08-24 04:26 <bh> well, what else could be used ?
2008-08-24 04:26 <flips> depending on the properties of the hash it might be hard to do otherwise
2008-08-24 04:26 <flips> xor
2008-08-24 04:26 <flips> check out dx_hack_hash
2008-08-24 04:27 <flips> it performs well and is cheap to compute
2008-08-24 04:27 <flips> performs => distributes evenly
2008-08-24 04:27 <flips> sha1 is better, but not so much better as to be worth the cpu load
2008-08-24 04:28 <flips> it is also a much wider hash
2008-08-24 04:28 <flips> you can't use a 32 bit hash for this without a collision scheme
2008-08-24 04:30 <bh> well, what did you think about getting some kind of generic blob support to universally represetn chnk of data in a file so that you can avoid replicating it ?
2008-08-24 04:30 <bh> it would apply to uncompressed as well as compress storage
2008-08-24 04:30 <flips> http://en.wikipedia.org/wiki/Content-addressable_storage
2008-08-24 04:30 <bh> I wouldn't expect a radi layer to be a aware of that stuff
2008-08-24 04:31 <bh> 
ACTION can't chat much longer

2008-08-24 04:31 <flips> kay, I can't either
2008-08-24 04:31 <flips> got to consider the sleep thing
2008-08-24 04:32 <bh> interesting
2008-08-24 04:32 <flips> some kind of cheap hash that results in a protocol exchange between upstream and downstream to see if the blocks are really identical would be useful
2008-08-24 04:33 <bh> last bit, think about cdta localit and online disk checking.
2008-08-24 04:33 <bh> internet is dying
2008-08-24 04:33 <bh> night
2008-08-24 04:33 <flips> cdta?
2008-08-24 04:33 <flips> ah
2008-08-24 04:33 <bh> data locality
2008-08-24 04:33 <flips> sure
2008-08-24 04:34 <flips> been thinking indeed
2008-08-24 04:34 <flips> see the log
2008-08-24 04:34 <bh> for performance reasons, they should be considered together
2008-08-24 04:34 <bh> how far up ?
2008-08-24 04:34 <bh> is anything I say useful ?
2008-08-24 04:35 <flips> yes
2008-08-24 04:35 <flips> very
2008-08-24 04:35 <flips> check it out later
2008-08-24 04:35 <flips> shapor and me
2008-08-24 04:35 <flips> conclusion is that storing a thing that is kind of like a snapshot but does not have the actual snapshot data, just hashes of it
2008-08-24 04:36 <flips> would be useful for checking
2008-08-24 04:36 <flips> and efficient
2008-08-24 04:36 <flips> vs the stupid braindamage that zfs has popularized
2008-08-24 04:36 <flips> anything you say?
2008-08-24 04:36 <flips> yes
2008-08-24 04:37 <flips> inspired the hash snap idea
2008-08-24 05:56 -!- tim_dimm(~timothyhu@cpe-76-90-98-247.socal.res.rr.com) has joined #tux3
2008-08-24 12:47 -!- tim_dimm(~timothyhu@cpe-76-90-98-247.socal.res.rr.com) has joined #tux3
2008-08-24 14:07 -!- tim_dimm(~timothyhu@cpe-76-90-98-247.socal.res.rr.com) has joined #tux3
2008-08-24 14:36 -!- tim_dimm(~timothyhu@cpe-76-90-98-247.socal.res.rr.com) has joined #tux3
2008-08-24 15:18 <flips> iattr.c decoded an attribute list
2008-08-24 15:18 <flips> now an encoder
2008-08-24 15:18 <flips> or maybe I should check it in as is
2008-08-24 15:19 <flips> make shapor's eyes bleed
2008-08-24 15:21 <shapor> check it in
2008-08-24 15:22 <shapor> should be more exciting than just "return 0"
2008-08-24 15:22 <flips> it is
2008-08-24 15:22 <flips> it's real gouge your eyes out stuff
2008-08-24 15:23 <pgquiles> strigi dox suck
2008-08-24 15:23 <pgquiles> :-(
2008-08-24 15:24 <flips> pgquiles, just put out a call for tech writers
2008-08-24 15:24 <pgquiles> flips: problem is tech writers would first need to understand what each class, method, etc do, which is the difficult part of these docs
2008-08-24 15:25 <pgquiles> I'm not even sure which classes are internal and which ones are intended for use by applications!
2008-08-24 15:25 <flips> g99 -g -Wall iattr.c && ./a.out
2008-08-24 15:25 <flips> block = 1234, depth = 1
2008-08-24 15:25 <flips> I guess I will make it decode more than one attr before checking in
2008-08-24 15:25 <flips> pgquiles, decent tech writers understand that stuff
2008-08-24 15:26 <flips> jon corbet for example
2008-08-24 15:26 <flips> but he doesn't work for free... always
2008-08-24 15:42 <flips> shapor, iattr.c skeleton decoder is in
2008-08-24 15:42 <flips> next, skeleton encoder
2008-08-24 15:42 <flips> then really use both
2008-08-24 15:44 <flips> 
ACTION considers the wisdom of changing his skate wheels

2008-08-24 15:44 <shapor> http://www.officemax.com/omax/catalog/sku.jsp?skuId=21607263
2008-08-24 15:44 <shapor> nifty
2008-08-24 15:48 <flips> sounds big
2008-08-24 16:10 <flips> getting close to sk8 oclock
2008-08-24 17:54 <flips> getting really close to sk8 oclock
2008-08-24 18:38 -!- tim_dimm(~timothyhu@cpe-76-90-98-247.socal.res.rr.com) has joined #tux3
2008-08-24 21:50 <bh> 
ACTION has a relatively solid internet connection now

2008-08-24 22:59 <shapor> flips: pull from me, some minor fixes
2008-08-24 23:00 <flips> hopefully not to iattr.c
2008-08-24 23:00 <shapor> no
2008-08-24 23:00 <flips> kay
2008-08-24 23:00 <flips> now how do I do that again
2008-08-24 23:00 <flips> forgot to write down te prescription
2008-08-24 23:00 <flips> oh
2008-08-24 23:00 <flips> it was hard
2008-08-24 23:00 <flips> you have a bunch of heads
2008-08-24 23:00 <flips> and when I pulled I got them all
2008-08-24 23:01 <shapor> hg pull static-http://shapor.com/tux3/shapor-tux3
2008-08-24 23:01 <flips> was a major pain to get rid of them
2008-08-24 23:01 <flips> right
2008-08-24 23:01 <shapor> hrm
2008-08-24 23:01 <flips> but not just that
2008-08-24 23:01 <flips> best is to clone, then pull into that, then selectively pull from the local copy
2008-08-24 23:01 <shapor> i should get rid of the heads first
2008-08-24 23:01 <flips> well there are probably better ways
2008-08-24 23:01 <shapor> hm
2008-08-24 23:01 <flips> right
2008-08-24 23:02 <flips> make a clean repo to pull from
2008-08-24 23:02 <flips> that's what the kernel crowd does
2008-08-24 23:02 <flips> I'll peek at the repo online
2008-08-24 23:03 <flips> why not set up a cgi?
2008-08-24 23:04 <shapor> ok i recloned
2008-08-24 23:04 <shapor> and put one of my changes is (fix dependencies in Makefile)
2008-08-24 23:07 <flips> have you tried hg view?
2008-08-24 23:07 <shapor> no
2008-08-24 23:07 <flips> try it :-)
2008-08-24 23:07 <flips> I can see your repo is clean right away with it
2008-08-24 23:08 <shapor> $ hg view
2008-08-24 23:08 <shapor> /usr/bin/env: wish: No such file or directory
2008-08-24 23:08 <shapor> heh
2008-08-24 23:08 <flips> make it there
2008-08-24 23:13 <bh> ey
2008-08-24 23:14 <bh> I've got a more solid internet connection right now
2008-08-24 23:14 <bh> so I can talk for a bit before it drops out
2008-08-24 23:14 <bh> 
ACTION is still prepping for Burning Man

2008-08-24 23:16 <flips> shapor, merged
2008-08-24 23:16 <flips> not painful
2008-08-24 23:16 <flips> only shakey spot was forgetting the url
2008-08-24 23:16 <flips> which I have written down this time
2008-08-24 23:16 <flips> bh, hi
2008-08-24 23:17 <flips> I'm not clear on why prepping is required
2008-08-24 23:17 <flips> probably I just don't understand
2008-08-24 23:19 <shapor> flips: should inode test be asserting ?
2008-08-24 23:19 <flips> no
2008-08-24 23:19 <shapor> (just pulled)
2008-08-24 23:19 <shapor> perhaps 64 bit bug
2008-08-24 23:19 <shapor> i'll look
2008-08-24 23:20 <shapor> outputs about 15 lines then [5972] brelse: Failed assertion "buffer->count"
2008-08-24 23:20 <flips> doesn't assert for me
2008-08-24 23:20 <flips> double free
2008-08-24 23:21 <flips> included the filename?
2008-08-24 23:21 <flips> should clean that up
2008-08-24 23:21 <shapor> yes i included the filename
2008-08-24 23:21 <shapor> valgrind says uninitialized value
2008-08-24 23:21 <shapor> in tuxopen
2008-08-24 23:22 <flips> let me check here
2008-08-24 23:23 <flips> yup
2008-08-24 23:23 <flips> just a sec
2008-08-24 23:25 <shapor> http://pastebin.com/m6e86586e
2008-08-24 23:26 <flips> fixed
2008-08-24 23:26 <flips> you beat me to it?
2008-08-24 23:26 <shapor> no that is the output
2008-08-24 23:26 <shapor> valgrind really blew up
2008-08-24 23:26 <shapor> illegal opcode
2008-08-24 23:26 <shapor> i havne't seen that before
2008-08-24 23:27 <flips> I inherited that dodgy interface from ripping the ext2 dir code
2008-08-24 23:27 <flips> fragile
2008-08-24 23:27 <shapor> sure blame someone else :P
2008-08-24 23:28 <flips> well I'm the one who didn't run valgrind
2008-08-24 23:28 <flips> the encode/decode verges on pretty now, does it not?
2008-08-24 23:28 <shapor> its pretty obvious you aren't using the makefile 
2008-08-24 23:28 <flips> I use make
2008-08-24 23:29 <flips> fairly often
2008-08-24 23:29 <shapor> not for running the test
2008-08-24 23:29 <flips> but not in development, usually just before or after a commit
2008-08-24 23:29 <flips> right
2008-08-24 23:29 -!- tim_dimm(~timothyhu@cpe-76-90-98-247.socal.res.rr.com) has joined #tux3
2008-08-24 23:29 <shapor> hi tim
2008-08-24 23:29 <tim_dimm> hey shapor
2008-08-24 23:29 <flips> hiyah tim
2008-08-24 23:29 <tim_dimm> u missed a great skate today
2008-08-24 23:30 <tim_dimm> flips!
2008-08-24 23:30 <tim_dimm> dude!
2008-08-24 23:30 <flips> I had a pretty good one
2008-08-24 23:30 <tim_dimm> ;-_
2008-08-24 23:30 <flips> doing a little faux grinding
2008-08-24 23:30 <flips> skating on the skateboard obstacles
2008-08-24 23:30 <tim_dimm> really?
2008-08-24 23:30 <tim_dimm> wow
2008-08-24 23:30 <shapor> tim_dimm: did you get my email?
2008-08-24 23:30 <tim_dimm> about chris?
2008-08-24 23:30 <tim_dimm> yeah
2008-08-24 23:31 <shapor> yeah, were you involved in that?
2008-08-24 23:31 <tim_dimm> we went to ikea tonight, so I didn't have time to respond
2008-08-24 23:31 <shapor> ah, sounds... manly
2008-08-24 23:31 <tim_dimm> I also had to clean 40 mini bearings for my race
2008-08-24 23:31 <tim_dimm> that course looks amazing
2008-08-24 23:31 <tim_dimm> I'm crashing guys. just logged on to plug in my phone
2008-08-24 23:32 <shapor> he sent a pic of the road rash he got longboarding downhill
2008-08-24 23:32 <flips> night
2008-08-24 23:32 <tim_dimm> night
2008-08-24 23:32 <tim_dimm> wanna see the road rash in the am
2008-08-24 23:32 <shapor> http://tinyurl.com/6ql2h6
2008-08-24 23:32 <shapor> tim_dimm: g'night
2008-08-24 23:32 <tim_dimm> I have a special treatment for road rash
2008-08-24 23:33 <tim_dimm> das ugly
2008-08-24 23:33 <flips> wiskey?
2008-08-24 23:33 <tim_dimm> hip crash
2008-08-24 23:33 <tim_dimm> no, trying to remember the name
2008-08-24 23:33 <tim_dimm> special bandages
2008-08-24 23:33 <tim_dimm> its late, I'll remember in the am
2008-08-24 23:33 <tim_dimm> k, crashin
2008-08-24 23:33 <flips> anna put mine away
2008-08-24 23:33 <flips> see you
2008-08-24 23:33 <tim_dimm> ttyl
2008-08-24 23:33 <flips> tegaderm
2008-08-24 23:40 <shapor> flips: what is this {en,de}code_{two,four,six,eight} mess?
2008-08-24 23:40 <flips> serial encoding/decoding
2008-08-24 23:40 <flips> always looks like that or worse
2008-08-24 23:42 <shapor> maybe a macro could make it cleaner?
2008-08-24 23:42 <flips> would make it worse
2008-08-24 23:42 <flips> try it
2008-08-24 23:43 <shapor> make once the dust settles
2008-08-24 23:43 <flips> inlines are to be preferred over macros
2008-08-24 23:43 <flips> yes good attitude
2008-08-24 23:43 <flips> also read some similar code
2008-08-24 23:43 <shapor> s/make/maybe/
2008-08-24 23:43 <flips> say, xdelta
2008-08-24 23:43 <flips> then come back and complain ;-)
2008-08-24 23:44 <shapor> heh
2008-08-24 23:44 <flips> serial coding/decoding never looks pretty because the compiler can help very little
2008-08-24 23:44 <flips> the endian conversion is the biggest mess
2008-08-24 23:44 <flips> if you can make that pretty, show me
2008-08-24 23:45 <shapor> btw i fixed some (L) warnings
2008-08-24 23:45 <shapor> if you want to pull
2008-08-24 23:45 <flips> ok
2008-08-24 23:47 <shapor> why do we care about endianness?
2008-08-24 23:48 <shapor> on disk format should be whatever is native
2008-08-24 23:48 <flips> because if somebody writes a filesystem on a ppc they want to be able to read it on an x86
2008-08-24 23:49 <shapor> right, just record that in the superblock
2008-08-24 23:50 <shapor> theres no reason do jerk around with the endianness in the normal case if you never swap dicks
2008-08-24 23:50 <shapor> disks*
2008-08-24 23:50 <flips> all filesystems do endian conversion
2008-08-24 23:51 <flips> zfs will store in native format and convert if you read on the other format, that sucks the worst
2008-08-24 23:51 <shapor> why?
2008-08-24 23:51 <shapor> that seems right
2008-08-24 23:51 <flips> because you have a whole different code patch if somebody goes to a different endian host
2008-08-24 23:52 <flips> better to pick a format and stick with it
2008-08-24 23:52 <flips> that's why there is a network byte order for example
2008-08-24 23:52 <shapor> sounds ideal, its a uncommon case
2008-08-24 23:52 <flips> could do the same wanking with context senstive conversion there, it just isn't wise
2008-08-24 23:52 <shapor> everyone has pcs
2008-08-24 23:53 <flips> no filesystem will get merged in linux without conversion
2008-08-24 23:53 <flips> extept for ramfs/tmpfs
2008-08-24 23:53 <shapor> and tux3
2008-08-24 23:53 <shapor> :P
2008-08-24 23:53 <flips> welcome to the filesystem world
2008-08-24 23:54 <flips> there are some unpretty things that have to be done
2008-08-24 23:54 <shapor> thats just dumb
2008-08-24 23:54 <shapor> for no good reason
2008-08-24 23:54 <flips> not having a consistent disk format would be way dumber
2008-08-24 23:55 <flips> think about it: you end up with all the same code if you do context conversion anyway, plus other code
2008-08-24 23:55 <flips> oh wait
2008-08-24 23:55 <shapor> yeah but its not normally in the code path
2008-08-24 23:55 <flips> chances are you end up with two copies of the conversion code
2008-08-24 23:55 <flips> it's cruft
2008-08-24 23:55 <flips> cpu cost of always converting is small
2008-08-24 23:55 <flips> there are dedicated processor instructions that do it
2008-08-24 23:56 <shapor> 
ACTION is done grumbling about it being a waste

2008-08-24 23:57 <shapor> ddsnap doesn't do anything with endianness iirc
2008-08-24 23:59 <flips> that has to be fixed before merging
2008-08-24 23:59 <flips> it's written in the comments at the top of the file