2008-10-11 00:40 hi 2008-10-11 00:41 title of the next post is set 2008-10-11 00:41 "Thinking about Syncing" 2008-10-11 00:41 even better, there's an algorithm in mind 2008-10-11 01:50 -!- MaZe(~MaZe@c-24-6-86-168.hsd1.ca.comcast.net) has joined #tux3 2008-10-11 02:47 -!- Bobby_(~Bobby@122.162.70.20) has joined #tux3 2008-10-11 05:35 -!- Bobby_(~Bobby@122.162.70.20) has joined #tux3 2008-10-11 06:20 -!- Bobby_(~Bobby@122.162.70.20) has joined #tux3 2008-10-11 06:40 -!- Bobby_(~Bobby@122.162.70.20) has joined #tux3 2008-10-11 07:49 -!- less(~less@145-116-238-192.uilenstede.casema.nl) has joined #tux3 2008-10-11 08:13 -!- Bobby__(~Bobby@122.162.70.206) has joined #tux3 2008-10-11 09:18 -!- pgquiles(~pgquiles@247.Red-83-41-112.dynamicIP.rima-tde.net) has joined #tux3 2008-10-11 09:36 -!- hirofumi(~hirofumi@210.171.168.39) has joined #tux3 2008-10-11 12:12 -!- Bobby__(~Bobby@122.162.70.206) has joined #tux3 2008-10-11 12:22 -!- pranihome(~Bobby@122.162.70.206) has joined #tux3 2008-10-11 12:34 http://lodge.glasgownet.com/2008/10/11/its-hammer-time/ <- hammer and tux3 2008-10-11 12:44 flips, are hammer and tux3 comparable? 2008-10-11 12:48 never went through what hammer was really... 2008-10-11 13:07 they use a similar method to do versioning 2008-10-11 13:08 significant differences too 2008-10-11 13:08 hammer has linear versioning, one long chain of snapshots at high granularity while tux3 does tree versioning with snapshots of snapshots 2008-10-11 13:35 -!- ajonat(~ajonat@190.48.107.122) has joined #tux3 2008-10-11 13:39 -!- bobby(~bobby@122.162.70.206) has joined #tux3 2008-10-11 13:39 amazing facts department: a freshly untarred 2.6.26.5 tree has 276008641 bytes of file data / 25715 files, average file size 10733 bytes 2008-10-11 13:40 since untarring kernel trees is one of the main linux fs benchmarks, we care about this 2008-10-11 13:40 average file size has grown over the years from about 8k to nearly 11k 2008-10-11 13:40 not growing very fast, really 2008-10-11 13:41 in the same period the total file data size has about tripled 2008-10-11 15:41 yet another amazing fact: average length of a filename in 2.6.26.5 kernel tree is 36 chars 2008-10-11 15:41 translates into 85 names per ext3 dirent block 2008-10-11 15:50 -!- ajonat_(~ajonat@190.48.116.113) has joined #tux3 2008-10-11 17:01 hey 2008-10-11 17:06 9080 / 1000. 2008-10-11 17:06 whoops 2008-10-11 17:06 wrong window ;) 2008-10-11 17:09 my calculations suggest we will be able to achieve 97.6% of raw disk write bandwidth for the case of untarring a kernel tree to an empty filesystem, complete with atomic commit, but provided the direct data pointer inode attribute is implemented, to get rid of the btree root + leaf per file 2008-10-11 17:10 with the current layout, we can get about 56% of raw 2008-10-11 17:14 Ext3 at present achieves 14% of raw bandwidth as measured on my system here 2008-10-11 17:14 I'm sure I'm missing some overheads that will pull that 97% number lower 2008-10-11 17:14 but we have an awful lot of room for error here 2008-10-11 17:15 put it another way: ext3 write performance sucks hard 2008-10-11 17:15 low bar to jump over 2008-10-11 19:11 what accounts for ext3's write performance ?issues ? 2008-10-11 19:24 journal for one thing 2008-10-11 19:26 what else ? 2008-10-11 19:27 is xfs faster ? 2008-10-11 19:29 don't know, why don't you run some tests? 2008-10-11 19:33 jjfjfjfjfjfjf 2008-10-11 19:33 shit 2008-10-11 19:33 sorry 2008-10-11 19:39 ok, a fairer test shows ext3 coming in at 25 MB/sec 2008-10-11 19:39 untar a tarfile from ramfs 2008-10-11 19:40 still a very far way from there to speed of the disk 2008-10-11 19:45 most disk top out at that rate 2008-10-11 19:45 unless you have a raid array or something like that 2008-10-11 19:46 -!- data`(~data@echo489.server4you.de) has joined #tux3 2008-10-11 19:47 not really 2008-10-11 19:47 dd will get about 64 MB/sec on this disk 2008-10-11 20:00 ok, just confirmed... dd from ramfs to my disk runs from 56 to 64 MB/sec 2008-10-11 20:01 same disk that's running my workstation and server right now ;) 2008-10-11 20:01 course, have to be quite careful not to destroy it while running the dd write test 2008-10-11 20:02 let's round that throughput to 60 MB/s 2008-10-11 20:03 Ext3 therefore hits about 42% of raw bandwidth 2008-10-11 20:04 we are aiming higher with tux3 2008-10-11 20:05 initially, just over 50% of raw would be nice, before optimizing to get rid of the two btree blocks per file for small files 2008-10-11 20:05 then I don't see why we can't hit 80-90% of raw after optimizing 2008-10-11 22:18 -!- pranith_(~bobby@122.162.70.206) has joined #tux3 2008-10-11 22:18 hey all 2008-10-11 22:29 hi 2008-10-11 23:11 flips, hey 2008-10-11 23:11 hi