2008-08-25 00:00 big job, nobody wants to do it, its ugly 2008-08-25 00:02 ok zfs goes a bit too far they suport little and big both in the same filesystem 2008-08-25 00:02 thats just stupid 2008-08-25 00:02 Every data structure in ZFS is written in the byte order of the machine writing it, along with a flag to indicate what byte order was used. A ZFS volume on an Opteron machine will be little-endian; one controlled by an UltraSPARC will be big-endian. If you swap the disk between the two machines, it still will workand the more you write to it, the more it will become optimized for native reading. 2008-08-25 00:03 i was just saying put a little/big flag in the sb 2008-08-25 00:04 but yes, then you need double the conversion code 2008-08-25 00:04 bfd 2008-08-25 00:04 merge collision 2008-08-25 00:04 in iattr.c 2008-08-25 00:05 oops 2008-08-25 00:09 merged 2008-08-25 00:09 was worth it just to see how merge conflicts go in mercurial 2008-08-25 00:09 the answer is: smooth and obvious 2008-08-25 00:09 I love it how it starts the editor for you 2008-08-25 00:10 yeah i did that once 2008-08-25 00:10 yes, smooth and obvious 2008-08-25 00:11 i was pleasantly suprised, thought "this is too easy" 2008-08-25 00:11 sure smacks svn 2008-08-25 00:12 hg does need a way to delete a head 2008-08-25 00:12 though if I had that, I probably would not have tried merging like a good boy 2008-08-25 00:13 it's only just after midnight, I should add another attr maybe 2008-08-25 00:14 link count 2008-08-25 00:14 the last one that's needed for initial prototype I think 2008-08-25 00:15 say, are we going to allow more than 4 billion links to the same file? 2008-08-25 00:16 why is ctime clumped with mode,uid,gid? 2008-08-25 00:17 aren't they normally all set at the same time? 2008-08-25 00:17 ctime? 2008-08-25 00:17 create time 2008-08-25 00:17 change time 2008-08-25 00:17 no it is create, you're right about being set together 2008-08-25 00:17 when the uid/gid/mode are normally set 2008-08-25 00:18 but not likely to be shared 2008-08-25 00:18 true 2008-08-25 00:18 just feels wrong to put ctime in there 2008-08-25 00:18 we can have a separate attr that only encdes ctime, maybe 2008-08-25 00:18 could be wrong indeed 2008-08-25 00:19 it doesn't make a huge difference, about 2 extra bytes/inode 2008-08-25 00:19 to have it separate 2008-08-25 00:19 that's about 5% of the size of an inode 2008-08-25 00:19 basic inode 2008-08-25 00:21 so 16 attribute types supported? or 15? 2008-08-25 00:22 16 2008-08-25 00:22 one of them is "extended attribute" 2008-08-25 00:22 attribute structure and variations can get aribtrarily complicated, so the 16 is just to capture the most common ones 2008-08-25 00:23 right so how do you know how many are stored? 2008-08-25 00:23 the inode dictionary gives the size of the inode 2008-08-25 00:23 ileaf dict 2008-08-25 00:23 how many bits is that? 2008-08-25 00:24 64K 2008-08-25 00:24 but limit is the size of a table block 2008-08-25 00:24 we are going to have to let inodes overflow into the next block 2008-08-25 00:25 added another attribute 2008-08-25 00:25 took about 5 minutes this time 2008-08-25 00:25 sign of a good interface 2008-08-25 00:26 will think about separating out mtime 2008-08-25 00:26 or have an alternate, separate mtime 2008-08-25 00:26 that is probably the way to go 2008-08-25 00:26 you mean ctime? 2008-08-25 00:26 the presense of mtime with no owner means "inherit" 2008-08-25 00:26 yes ctime 2008-08-25 00:27 could get tricky with multiple versions 2008-08-25 00:27 also might have a separate mtime, for when database-type writes modify the file without changing the size 2008-08-25 00:27 yeah i was thinking that when i read iattr.c 2008-08-25 00:28 the immediate goal is just to get the prototype up 2008-08-25 00:28 optimize for ownership inheritance later 2008-08-25 00:28 I think all the necessary attributes are there now 2008-08-25 00:29 possilby want a blocks count, but can just ignore that to start 2008-08-25 00:29 its funny though, when you trim the size down this much you see how much fat is really there 2008-08-25 00:29 compared to? 2008-08-25 00:29 with the non-inheritent compact metadata storage the vast majority will be redundant mode,owner 2008-08-25 00:30 yes 2008-08-25 00:30 it would be nice to get down to 16 byte minimum inode size 2008-08-25 00:30 24 bytes a "hello" immediate file 2008-08-25 00:31 why 24? 2008-08-25 00:32 just thinkin what the mininum would be 2008-08-25 00:32 need 5 bytes for hello 2008-08-25 00:32 2 bytes to say this is in immediate data attribute + version 2008-08-25 00:32 so 16 + 7 ~= 24 2008-08-25 00:33 ;-) 2008-08-25 00:33 yeah newline at the end ;) 2008-08-25 00:33 so the whole point of tux3 is to compress the zumastor configuration database? i knew it!! 2008-08-25 00:34 right 2008-08-25 00:35 versus how big on zfs? 2008-08-25 00:35 I shudder to think 2008-08-25 00:35 512 bytes dnode I think 2008-08-25 00:36 but I don't know what a dnode is 2008-08-25 00:36 I imagine it's hugely grosser than that 2008-08-25 00:36 they use 128 bytes minimum for a pointer 2008-08-25 00:36 I don't know if they have immediate data 2008-08-25 00:36 oh they do 2008-08-25 00:36 bits you mean 2008-08-25 00:36 in the 128 byte pointer maybe 2008-08-25 00:36 bytes I mean 2008-08-25 00:36 ACTION blinks 2008-08-25 00:36 not kidding 2008-08-25 00:37 zfs is pretty gross actually 2008-08-25 00:37 it looks best in a brochure 2008-08-25 00:38 sounds like ipv6, but much worse 2008-08-25 00:40 I wonder which one has more deployments 2008-08-25 00:40 ipv6 by a lot 2008-08-25 00:41 its been around.... 15 years? 2008-08-25 00:41 I've never run into one in the wild 2008-08-25 00:41 as a percentage of who _could_ use it, it may be around a tie right now 2008-08-25 00:42 ok, iattr.c should be nearly done for now 2008-08-25 00:42 have to hook it up to inode.c 2008-08-25 00:42 nah, big networks are all doing v6 for backbones 2008-08-25 00:43 any big win? 2008-08-25 00:43 makes routing easier 2008-08-25 00:43 supported in hardware on the big routers 2008-08-25 00:43 you actully get a discount if you talk v6 to them 2008-08-25 00:43 discount? 2008-08-25 00:44 oh 2008-08-25 00:44 onthe peering 2008-08-25 00:44 yeah 2008-08-25 00:44 thanks, but no thanks 2008-08-25 00:44 i'll keep my nat 2008-08-25 00:44 it is kind of sad that I now will replace 4 lines with 150 lines 2008-08-25 00:45 few computers need public ips 2008-08-25 00:45 the amount of code that was needed to do the endian conversions + encode/decode attrs 2008-08-25 00:45 why 2008-08-25 00:45 why? 2008-08-25 00:46 typical phillips bloatware code :P 2008-08-25 00:46 somebody should add endian attributes to gcc 2008-08-25 00:46 and reliable, predictable bit fields 2008-08-25 00:47 whats not reliable/predictable about bit fields in gcc? 2008-08-25 00:47 there's no guarantee on where they will end up in the data object 2008-08-25 00:48 so you can't use them to define disk formats 2008-08-25 00:48 code would be a lot less if you could 2008-08-25 00:50 shall we go with the "howmuch" function, or think of a more respectable name? 2008-08-25 00:54 howmuch is respectable 2008-08-25 00:54 it allready changed to howbig ;-) 2008-08-25 00:55 how about __iattr_how_many_bytes 2008-08-25 00:55 ooh pretty 2008-08-25 00:56 just preface every function with __ 2008-08-25 00:56 so you always remember which file you're looking at 2008-08-25 00:56 and that the authors _ key was working 2008-08-25 00:57 what about the type of the return value? 2008-08-25 00:57 aren't you supposed to encode that in the name? 2008-08-25 00:57 oh right 2008-08-25 00:59 i threw up a lot working on bind last week 2008-08-25 00:59 you know its going to be bad when you have to look in the "bin" dir for all the source code 2008-08-25 01:00 wow, that was easy to integrate 2008-08-25 01:00 the high level code got about half the size 2008-08-25 01:01 vs the straight struct banging 2008-08-25 01:02 grep -r seems to indicate 64844 occurances of "isc" in the bind9 source tree 2008-08-25 01:02 isc? 2008-08-25 01:02 oh, thats just lines containing isc 2008-08-25 01:02 internet systems consortium 2008-08-25 01:02 the company that makes bind 2008-08-25 01:03 everything is isc_ 2008-08-25 01:03 about about discdrive? 2008-08-25 01:03 :-) 2008-08-25 01:03 oh and thats just *lines containing isc* 2008-08-25 01:03 not occurances 2008-08-25 01:04 if you add up all the bytes "isc" takes up in the bind source its probably an order of magnitude larger than the djbdns source 2008-08-25 01:08 isc_uint32_t isc_random_jitter(isc_uint32_t max, isc_uint32_t jitter); 2008-08-25 01:08 heh 2008-08-25 01:08 oh, now we can have a generic attribute dumper 2008-08-25 01:08 instead of a lame hexdump 2008-08-25 01:08 indeed 2008-08-25 01:09 kudos for you for at least trying to make that stinking thing a little better 2008-08-25 01:10 waste of time 2008-08-25 01:10 what I meant 2008-08-25 01:10 the direct c file includes are going to break pretty soon 2008-08-25 01:11 and it will go to a "proper" makefile 2008-08-25 01:12 for the moment I think I will include iattr.c in ileaf.c 2008-08-25 01:12 the notmain thing will break then 2008-08-25 01:12 ugh 2008-08-25 01:12 why did you start the attrs at 6? 2008-08-25 01:12 maybe it all breaks right now 2008-08-25 01:12 just so I could see them 2008-08-25 01:12 time to change the base to zero, almost 2008-08-25 01:13 though zeros are rather common 2008-08-25 01:13 most of the mistakes were caught by the assert on unknown kind, which would not have been unknown if zero was an attribute 2008-08-25 01:15 good call 2008-08-25 01:19 oh wow, the c file includes/notmain hack didn't break when I included iattr.c in ileaf.c 2008-08-25 01:20 this monster gets to stumble on another cycle 2008-08-25 01:24 http://lwn.net/Articles/112567/ 2008-08-25 01:25 should support xattr out of the gate 2008-08-25 01:31 ah, inode table dump looks much better with proper attribute dump 2008-08-25 01:31 yes, xattr is in from the start, except not the first kernel port 2008-08-25 01:31 got to cut some corners somewhere 2008-08-25 01:32 ah, now I notice that a bogus empty inode table leaf has crept in 2008-08-25 01:33 now that the table dump isn't all noisy 2008-08-25 01:33 1 level btree 0xbf900988 at 64: 2008-08-25 01:33 0x0/0, 4084 free: 2008-08-25 01:33 0x47/1, 4054 free: 2008-08-25 01:33 0x47: ctime 0 mode 81c0 uid 0 gid 0 btree (block 48 depth 1) (30 bytes) 2008-08-25 01:33 0x64/1, 4054 free: 2008-08-25 01:33 0x64: ctime 0 mode 41c0 uid 0 gid 0 btree (block 45 depth 1) (30 bytes) 2008-08-25 01:34 what sort of work is involved in porting to the kernel? 2008-08-25 01:34 have to un c99 it 2008-08-25 01:34 lindent 2008-08-25 01:34 locks 2008-08-25 01:34 hook up to bio interface 2008-08-25 01:34 hook up to vfs interfaces 2008-08-25 01:34 another dozen things I forgot 2008-08-25 01:35 hm, fun 2008-08-25 01:41 whoops, broke make with the #define main tricks 2008-08-25 01:41 I knew that was too easy 2008-08-25 01:48 The ctime--change time--is the time when changes were made to the file or directory's inode (owner, permissions, etc.). The ctime is also updated when the contents of a file change. It is needed by the dump command to determine if the file needs to be backed up. You can view the ctime with the ls -lc command 2008-08-25 01:49 so ctime always gets incremented when mtime does 2008-08-25 01:49 bleah 2008-08-25 01:49 the should probably be bundled 2008-08-25 01:49 what use is that? 2008-08-25 01:49 yes 2008-08-25 01:50 pretty crap feature 2008-08-25 01:50 beyond crap 2008-08-25 01:50 what's your source? 2008-08-25 01:50 so its essentially a copy of the mtime, but also gets updated if you chmod/chown 2008-08-25 01:50 flips: the internets 2008-08-25 01:50 and experimenting 2008-08-25 01:50 thanks for the heads up 2008-08-25 01:50 so yes, refactor that steaming pile 2008-08-25 01:51 are the drugs we have these days as good as the ones those guys were on? 2008-08-25 01:51 heh 2008-08-25 01:52 reminds me of a line my car geek friends have 2008-08-25 01:52 80s engine management is the result of 60s drug use 2008-08-25 01:52 what we are going to do is let mtime shadow ctime 2008-08-25 01:52 yeah and only add ctime if needed 2008-08-25 01:52 yes 2008-08-25 01:52 more cruft 2008-08-25 01:53 to debug 2008-08-25 01:53 xfs inodes are 256bytes by default 2008-08-25 01:54 caused some problems with selinux xattrs 2008-08-25 01:54 not enough room for them to fit in 2008-08-25 01:55 ext3 fits them in 2008-08-25 01:55 hey, want to collaborate on an article about filesystems for linux world? 2008-08-25 01:55 I've been asked to write about versioning filesystems 2008-08-25 01:56 zfs, btrfs, tux3 2008-08-25 01:56 sure 2008-08-25 01:56 I'll send email around 2008-08-25 01:56 it will be fun 2008-08-25 01:56 something like proctology 2008-08-25 01:56 get to learn all about them 2008-08-25 01:56 i should try btrfs 2008-08-25 01:56 yes 2008-08-25 02:00 ah the ctime and mtime are actually often different 2008-08-25 02:01 hmm, char * has a special feature that void * does not have 2008-08-25 02:02 you can subtract it from a pointer to anything else, and the other pointer is quietly converted to char * 2008-08-25 02:02 void * causes an error on subtract 2008-08-25 02:02 that is probably a flaw in definition of void * 2008-08-25 02:04 because you can set the mtime using utime() 2008-08-25 02:04 like tar does, when you untar something 2008-08-25 02:05 but you cannot alter the ctime 2008-08-25 02:05 however for the majority of the files we write() to, they will be equal 2008-08-25 02:06 I see 2008-08-25 02:06 ctime can stay in the owner group 2008-08-25 02:06 well 2008-08-25 02:06 no way 2008-08-25 02:06 let me see 2008-08-25 02:07 I was thinking if mtime can shadow it 2008-08-25 02:07 but now it seems it can't 2008-08-25 02:07 mtime could shadow ctime, yes 2008-08-25 02:07 only add mtime if someone sets it with utime() 2008-08-25 02:08 but if mtime is explicitly set then it can't shadow ctime 2008-08-25 02:08 it can be set to some time in the past, right? 2008-08-25 02:08 yeah 2008-08-25 02:08 why not have it shadow ctime 2008-08-25 02:08 right 2008-08-25 02:08 unless mtime is present 2008-08-25 02:08 it should 2008-08-25 02:09 and that attribute group should be ctime/size instead of mtime/size 2008-08-25 02:09 mtime gets its own attribute 2008-08-25 02:09 yep 2008-08-25 02:28 done 2008-08-25 02:30 and done for the evening 2008-08-25 02:32 its early 2008-08-25 02:34 mtime also needs to be added on a chmod/chown 2008-08-25 02:34 as a copy of the old ctime (if it doesn't already exist) 2008-08-25 02:35 mtime is also always deleted when ctime is updated due to a write 2008-08-25 03:15 -!- pgquiles(~pgquiles@239.Red-83-41-113.dynamicIP.rima-tde.net) has joined #tux3 2008-08-25 05:17 -!- pgquiles(~pgquiles@6.Red-81-39-193.dynamicIP.rima-tde.net) has joined #tux3 2008-08-25 08:07 -!- tim_dimm(~timothyhu@cpe-76-90-98-247.socal.res.rr.com) has joined #tux3 2008-08-25 10:38 -!- tim_dimm(~timothyhu@cpe-76-90-98-247.socal.res.rr.com) has joined #tux3 2008-08-25 10:49 -!- MaZe(~MaZe@216-239-45-4.google.com) has joined #tux3 2008-08-25 14:01 -!- MaZe(~MaZe@216-239-45-4.google.com) has joined #tux3 2008-08-25 14:25 crappy python 2008-08-25 14:25 quietly overflows its numerics in spite of running at 1/200th the speed of C 2008-08-25 14:28 oh wait 2008-08-25 14:29 was me 2008-08-25 14:29 python uses a**b for power, not a^b 2008-08-25 14:49 then how do you do bitwise xor? 2008-08-25 14:51 oh i thought you said that the other way 2008-08-25 14:51 why would you think it was ^? 2008-08-25 14:52 hard to see why python needs xor 2008-08-25 14:52 well 2008-08-25 14:52 -!- tim_dimm(~timothyhu@cpe-76-90-98-247.socal.res.rr.com) has joined #tux3 2008-08-25 14:52 I guess it does 2008-08-25 14:52 haven't finished my first cup of coffee is why 2008-08-25 14:52 navel gazing post on time resolution is up 2008-08-25 14:53 now back to the question of creating an actual exabyte file 2008-08-25 14:53 and that will be 1^60 bytes, not 1^60 less one 2008-08-25 14:55 to do that I think I will store the highest addressable byte in the csize attribute, not the actual size, which is one greater 2008-08-25 14:55 which means zero is not allowed as a csize value 2008-08-25 14:56 we will remove the size attribute instead 2008-08-25 14:56 or I might just spend the extra bit ;-) 2008-08-25 15:26 flips: you've got mail 2008-08-25 15:26 so I do 2008-08-25 15:27 interesting 2008-08-25 15:39 -!- caoliver(~oliver@75-134-208-20.dhcp.trcy.mi.charter.com) has joined #tux3 2008-08-25 15:43 15:40 <== One of the features of btrfs is fs-based softraid with duplicated metadata. So if it detects a bad checksum of hte metadata on one disk, it can get it from another location. It can even do that with 1 disk 2008-08-25 15:44 misfeature imho 2008-08-25 15:44 raid doesn't belong in the fs 2008-08-25 15:44 they will be debugging that for ages 2008-08-25 15:45 tux3 may take a more practical approach 2008-08-25 15:45 if it detects an error in metadata, rebuilt the index 2008-08-25 15:46 the index is just an accelerator after all 2008-08-25 15:52 how will it detect the error? 2008-08-25 15:52 what index is just an accelerator? 2008-08-25 15:52 btree index 2008-08-25 15:53 only the leaves matter 2008-08-25 15:53 they each will be identified with the data they reference 2008-08-25 15:53 since btrfs gives less protection to data, that puts it on equal footing 2008-08-25 15:53 ok what if you lose a sector some of your metadata is on 2008-08-25 15:53 both can lose data if redundancy of underlying storage is exceeded 2008-08-25 15:54 which metadata? 2008-08-25 15:54 say a dleaf 2008-08-25 15:54 anything really 2008-08-25 15:54 then you blow a hole in some data, what is new? 2008-08-25 15:54 each dleaf stands on its own 2008-08-25 15:54 with btrfs you just read from a dedundant copy 2008-08-25 15:54 doesn't help if a chunk of data was lost 2008-08-25 15:54 what if its an inode table 2008-08-25 15:54 same thing 2008-08-25 15:55 lose a range of inodes 2008-08-25 15:55 it isn't going to happen 2008-08-25 15:55 if it does, so some data is gone 2008-08-25 15:55 but btrfs has a feature which makes that not happen, right? 2008-08-25 15:55 try pulling two disks from a btrfs array and see what happens 2008-08-25 15:55 (oops probably) 2008-08-25 15:55 i am only talking 1 disk 2008-08-25 15:55 no 2008-08-25 15:55 btrfs claims to have such a feature 2008-08-25 15:55 it's wanking 2008-08-25 15:56 job of the raid system 2008-08-25 15:56 ok i'm not referring to the implementation 2008-08-25 15:56 i'm referring to the design 2008-08-25 15:56 stupid design 2008-08-25 15:56 very costly in terms of complexity 2008-08-25 15:56 ok 2008-08-25 15:56 wrong level 2008-08-25 15:56 too complex 2008-08-25 15:56 yes 2008-08-25 15:56 complexity = unreliability 2008-08-25 15:56 ACTION blushes about dleaf 2008-08-25 15:56 heh 2008-08-25 15:57 at least that complexity is confined 2008-08-25 15:57 raid complexity tends to get splatted throughout an entire system 2008-08-25 15:57 if you don't take measures to confine it 2008-08-25 15:57 most peopledont really care about losing data on a single disk system 2008-08-25 15:57 its proably more likely you lose the whole disk than get a bad block anyway 2008-08-25 15:58 true, and the only time it ever happened to me was when the disk stopped and died 2008-08-25 15:58 or upgraded an ubuntu system with root on lvm 2008-08-25 15:58 only two times 2008-08-25 15:58 in 15 years of abusing my disks and filesystems 2008-08-25 15:58 the other claimed feature if being able to read the metadata off the least busy device 2008-08-25 15:59 hah 2008-08-25 15:59 I'll believe that when I see it 2008-08-25 15:59 just have lots of spindles 2008-08-25 15:59 and let it go 2008-08-25 15:59 detecting that seems...hard 2008-08-25 15:59 yes 2008-08-25 15:59 quixotic 2008-08-25 15:59 there are so many things that actually matter 2008-08-25 15:59 like having a light footprint on cache 2008-08-25 16:00 never mind tlb 2008-08-25 16:01 got that guitar player's cd 2008-08-25 16:01 ten bucks and I am a happy puppy 2008-08-25 16:25 serial typos :-/ 2008-08-25 17:12 flips: you've got mail 2008-08-25 17:13 my penis is already long enough, thanks <- somebody made me type that 2008-08-25 17:14 was that somebody shapor? 2008-08-25 17:14 man in the middle attack I think 2008-08-25 17:14 lol 2008-08-25 17:14 nice 2008-08-25 17:15 http://www.shiningsilence.com/dbsdlog/2008/08/25/3041.html 2008-08-25 17:15 reading 2008-08-25 17:18 tim_dimm, you have male 2008-08-25 17:18 it is just about sk8 oclock 2008-08-25 17:49 time for a wheel change 2008-08-25 17:49 these ones ground down to the nub from slaloming down seaview terrace ;-) 2008-08-25 17:50 doubt I'll get out today. maybe. 2008-08-25 17:50 have a 7pm with my spousal unit 2008-08-25 17:50 interviewing the night nurse 2008-08-25 17:51 night nurse? 2008-08-25 17:51 "interviewing the night nurse" sounds like a bad porn 2008-08-25 17:51 shapor and I will drink a toast to you 2008-08-25 17:51 it's on shapor 2008-08-25 17:51 helps out a few nights during first few weeks 2008-08-25 17:51 hey! 2008-08-25 17:51 I should be there for that 2008-08-25 17:51 ! 2008-08-25 17:52 sure should 2008-08-25 17:52 topic swap; these ceramic mini bearings will be fast at maryhill 2008-08-25 17:53 doing a good job scatching the paint off my frames sliding down that rail 2008-08-25 17:53 too bad I only have 16 2008-08-25 17:53 could not convince shapor to try 2008-08-25 17:53 maybe today 2008-08-25 17:53 then there's the barrel the skateboarders jump over 2008-08-25 17:53 should be good for a pretty spectacular crash 2008-08-25 17:54 on thurday, it will be 120 skateboarders vs. 8 inliners 2008-08-25 17:54 we'll be a bunch of dorks 2008-08-25 17:54 they get out of the way more obligingly lately 2008-08-25 17:54 but we might be faster than them 2008-08-25 17:54 I take care to skate close to them when they veer towards me 2008-08-25 17:55