2008-09-16 01:29 `now 2008-09-16 01:30 autokilled... graphic 2008-09-16 01:32 march, it's old 2008-09-16 01:33 truth is, I fully trust in our students to out deduplicate any weeny engineers 2008-09-16 01:35 "what next" is #5 on lkml.org 2008-09-16 01:35 #6 2008-09-16 01:41 hehe 2008-09-16 01:43 hey maze 2008-09-16 01:44 hey 2008-09-16 01:44 we need to get your bio transfer working 2008-09-16 01:44 20 lines or less is defined as "working" 2008-09-16 01:44 ;-) 2008-09-16 01:44 just write a simple endio 2008-09-16 01:44 yeah, I've mostly been reading docs all sunday 2008-09-16 01:44 and browsing the source code 2008-09-16 01:45 put your submitter into sleep on a wait queue 2008-09-16 01:45 that's it 2008-09-16 01:45 one line wait queue declaration 2008-09-16 01:45 I could probably write something that works now, but I need to setup a better (less likely to crash machine) debug scenario than insmod into running machine 2008-09-16 01:45 naw 2008-09-16 01:45 and now it's unfortunately the work week ;-) 2008-09-16 01:45 write something that works 2008-09-16 01:45 forget about debugging 2008-09-16 01:45 hehe 2008-09-16 01:45 it works or it doesn' 2008-09-16 01:45 doesn't 2008-09-16 01:46 you'll know by the amount of smoke 2008-09-16 01:46 I don't like my work machine smoking though ;-) 2008-09-16 01:46 you're not going to make me write it for you? 2008-09-16 01:46 oh, wait a minute 2008-09-16 01:46 there should be a simple-ish solution 2008-09-16 01:46 there is 2008-09-16 01:47 sleep 2008-09-16 01:47 endio wakes 2008-09-16 01:47 simple 2008-09-16 01:47 no, no, no - not mucking around with disk io on my live machine 2008-09-16 01:47 ACTION has to pop some popcorn 2008-09-16 01:47 I've already gone through a painful weekend of data recovery 2008-09-16 01:47 why not? 2008-09-16 01:47 trust me 2008-09-16 01:47 nothing will break 2008-09-16 01:47 I trust you... I don't trust myself. 2008-09-16 01:47 except you might have to reboot ;) 2008-09-16 01:47 but probably not 2008-09-16 01:48 hard to go wrong with a read 2008-09-16 01:48 these days, your task can oops and the machine keeps right on running 2008-09-16 01:49 if you fear, compile uml 2008-09-16 01:49 make ARCH=um 2008-09-16 01:50 hmm 2008-09-16 01:50 ok, trying to write something 2008-09-16 01:50 will try pasting here in a moment 2008-09-16 01:51 deal 2008-09-16 01:51 ACTION goes to write some extent code 2008-09-16 01:51 totally drunk 2008-09-16 01:51 prolly better concentrate on the popcorn 2008-09-16 01:52 we had to celebrate tim's twins tonight 2008-09-16 01:55 balloc_from_range has to become balloc_extent_from_range 2008-09-16 01:56 going to be a mess 2008-09-16 01:56 fortunately, balloc_from_range is pretty tight 2008-09-16 01:57 going to be tighter with big endian scan 2008-09-16 02:17 block_t balloc_extent_from_range(struct inode *inode, block_t start, block_t count, unsigned length) 2008-09-16 02:17 declare looks could 2008-09-16 02:17 could somebody implement this please? 2008-09-16 02:18 ;-) 2008-09-16 02:22 maze, you need my uml recipe 2008-09-16 02:22 hmm, wouldn't mind 2008-09-16 02:22 nothing to fear except fear itself 2008-09-16 02:22 ok 2008-09-16 02:22 would you imagine I just roped myself into helping out someone for work... 2008-09-16 02:22 work? 2008-09-16 02:22 what's that? 2008-09-16 02:23 hehe - that annoying aspect of life 2008-09-16 02:24 that occupies 5pm-9am 2008-09-16 02:25 maze, wget http://phunq.net/root_fs 2008-09-16 02:25 100M 2008-09-16 02:26 exactly 2008-09-16 02:34 20% 2008-09-16 02:34 you've got slow uplink ;-) 2008-09-16 02:35 I could have pulled a dvd off of kernel.org by now 2008-09-16 02:36 we'll move 2008-09-16 02:36 to a faster host 2008-09-16 02:36 pretty soon 2008-09-16 02:36 this host is my desktop 2008-09-16 02:36 kernel.org hosts dvds now? 2008-09-16 02:37 not kernel.org 2008-09-16 02:37 home grown 2008-09-16 02:37 homeboy 2008-09-16 02:37 in response to MaZe's comment 2008-09-16 02:37 ;) 2008-09-16 02:37 got it? 2008-09-16 02:38 28% 2008-09-16 02:38 wah 2008-09-16 02:38 sucks 2008-09-16 02:38 what isp is your desktop on? 2008-09-16 02:38 speakeasy 2008-09-16 02:38 they are looking sucky 2008-09-16 02:38 especially at the price I pay 2008-09-16 02:39 granted comcast sent out a letter saying that starting october users going over 250G a month have to pay extra 2008-09-16 02:39 I'm nowhere close 2008-09-16 02:39 internet is barbaric in us of a 2008-09-16 02:40 primitive savages 2008-09-16 02:40 yep 2008-09-16 02:40 I don't come close either, at least I don't think 2008-09-16 02:40 -!- pgquiles__(~pgquiles@50.Red-79-153-248.staticIP.rima-tde.net) has joined #tux3 2008-09-16 02:40 I could if upload was better ... 2008-09-16 02:40 ok, how's it? 2008-09-16 02:40 you have to average roughly 0.8mbit a month to get 250G 2008-09-16 02:40 34% 2008-09-16 02:40 er, 0.8mbit/s constantly 2008-09-16 02:40 cuz I have to write the rest of the recipe by the time you get it 2008-09-16 02:40 good 2008-09-16 02:40 gives me time to think 2008-09-16 02:40 39.5KB/s 2008-09-16 02:40 lol 2008-09-16 02:41 bleah 2008-09-16 02:41 modem 2008-09-16 02:41 fyi: 2008-09-16 02:41 maze@athina:~$ wget http://mirrors.kernel.org/centos/4.7/isos/x86_64/CentOS-4.7-x86_64-binDVD.iso 2008-09-16 02:41 --02:39:10-- http://mirrors.kernel.org/centos/4.7/isos/x86_64/CentOS-4.7-x86_64-binDVD.iso 2008-09-16 02:41 => `CentOS-4.7-x86_64-binDVD.iso' 2008-09-16 02:41 Resolving mirrors.kernel.org... 204.152.191.39, 204.152.191.7 2008-09-16 02:41 Connecting to mirrors.kernel.org|204.152.191.39|:80... connected. 2008-09-16 02:41 HTTP request sent, awaiting response... 200 OK 2008-09-16 02:41 Length: 2,699,399,168 (2.5G) [application/x-iso9660-image] 2008-09-16 02:41 100%[==================================>] 2,699,399,168 13.21M/s ETA 00:001 2008-09-16 02:41 02:41:15 (21.04 MB/s) - `CentOS-4.7-x86_64-binDVD.iso' saved [2699399168/2699399168] 2008-09-16 02:41 maze@athina:~$ 2008-09-16 02:42 38% 2008-09-16 02:42 m 2008-09-16 02:42 ah right 2008-09-16 02:42 ok, I live in santa monica 2008-09-16 02:42 give me a break 2008-09-16 02:42 ;-) 2008-09-16 02:43 I find kernel.org to be ridiculously fast though 2008-09-16 02:43 never a good benchmark 2008-09-16 02:43 not a coincidence 2008-09-16 02:43 wow 2008-09-16 02:43 21MB/s is impressive 2008-09-16 02:43 I don't think I can write to my harddrive that fast 2008-09-16 02:43 kernel.org is not far from the backbone 2008-09-16 02:44 I can 2008-09-16 02:44 yeah, few ms ping time 2008-09-16 02:44 I can do 60MB/s 2008-09-16 02:44 I can max out gigabit 2008-09-16 02:44 I actually know kernel.org does readahead buffering in 64mb chunks 2008-09-16 02:44 max out gigabit = 60 MB/sec 2008-09-16 02:44 before you hit chipset 2008-09-16 02:45 unless it's a servers chipset 2008-09-16 02:45 because I can see 64MB fly in in 0.7 seconds, then 1-2 second wait as kernel.org reads in the next 64mb 2008-09-16 02:45 nah, my laptop does 117 MB/s tcp 2008-09-16 02:45 assuming there's no disk IO involved 2008-09-16 02:45 no it doesn't 2008-09-16 02:45 the disk is much slower of course 2008-09-16 02:45 tested - it does 2008-09-16 02:45 well 2008-09-16 02:46 true 2008-09-16 02:46 that's the max 2008-09-16 02:46 unbellievable 2008-09-16 02:47 ok, the rest of the recipe: 2008-09-16 02:47 [maze@nike ~]$ time dd if=/dev/zero bs=65536 count=20480 | ssh -c arcfour128 maze@athina cat \> /dev/null 2008-09-16 02:47 20480+0 records in 2008-09-16 02:47 20480+0 records out 2008-09-16 02:47 1342177280 bytes (1.3 GB) copied, 17.1915 s, 78.1 MB/s 2008-09-16 02:47 real 0m17.202s 2008-09-16 02:47 user 0m11.025s 2008-09-16 02:47 sys 0m5.620s 2008-09-16 02:47 that's with both systems actually doing work 2008-09-16 02:47 make defconfig ARCH=um && make lines ARCH=um && ./linus ubdo=root_fs 2008-09-16 02:48 and notice with ssh 2008-09-16 02:48 (spot the typo) 2008-09-16 02:48 lines? 2008-09-16 02:48 typo #1 2008-09-16 02:49 ubd or ubdo - not sure 2008-09-16 02:49 ./linus - weird 2008-09-16 02:49 make defconfig ARCH=um && make linux ARCH=um && ./linux ubd0=root_fs 2008-09-16 02:49 but I really have never used this so I'm guessing 2008-09-16 02:49 ah 2008-09-16 02:50 55% 2008-09-16 02:50 I told you I was totally drunk 2008-09-16 02:50 later you will realize you could have created your own root_fs 5x faster than downloading from me 2008-09-16 02:51 only thing is, it might not have nano in it 2008-09-16 02:51 and it might now be 105 MB 2008-09-16 02:51 well, I'm actually writing the code now, so it parallelizes 2008-09-16 02:51 besides I actually have a rootfs somewhere around here 2008-09-16 02:51 it's also 100mb or so 2008-09-16 02:51 mine is better 2008-09-16 02:51 includes ssh/mc a few other things 2008-09-16 02:51 sshd of course 2008-09-16 02:51 reboot time! 2008-09-16 02:51 that's good 2008-09-16 02:51 reboot konrad 2008-09-16 02:52 new kernel yay 2008-09-16 02:52 i can get > 1 reboot second with uml 2008-09-16 02:53 well my move in 2 days gets me a little closer to the backbone 2008-09-16 02:53 I am happy 2008-09-16 02:53 I would be too 2008-09-16 02:53 my connection sucks 2008-09-16 02:54 alright, reboot for real this time 2008-09-16 02:54 I might blog about speakeasy 2008-09-16 02:54 see if that gets it upgraded 2008-09-16 02:55 we are signed up for FAST by the way 2008-09-16 02:55 in advance 2008-09-16 02:55 poseter seeion, WIP report and BOF 2008-09-16 02:56 session 2008-09-16 02:57 konrad's not back 2008-09-16 02:57 seem, reboots take longer the faster cpus get 2008-09-16 02:57 bio_alloc(GFS_KERNEL, 1); 2008-09-16 02:57 wicked... 2008-09-16 02:57 72% 2008-09-16 02:57 pathetic 2008-09-16 02:58 yea! 2008-09-16 02:58 I have a race in my code 2008-09-16 02:58 getting a race on sleep is easy 2008-09-16 02:59 that race? 2008-09-16 03:00 nah 2008-09-16 03:00 possibility to remove module, before bio comes back 2008-09-16 03:00 true 2008-09-16 03:00 don't worry about it 2008-09-16 03:00 just don't have twitchy fingers 2008-09-16 03:01 if you want to fix the race 2008-09-16 03:01 flips: ok 2008-09-16 03:01 see module_inc 2008-09-16 03:01 or whatever it's called 2008-09-16 03:01 just wanted to know if you knew about that news 2008-09-16 03:01 forget 2008-09-16 03:01 always 2008-09-16 03:01 lived and breathed it 2008-09-16 03:03 news? 2008-09-16 03:03 -!- konrad(~konrad@c-24-16-74-109.hsd1.mn.comcast.net) has joined #tux3 2008-09-16 03:04 new kernel, new kmod-nvidia breakage 2008-09-16 03:04 bh, when zfs stop panicking on boot it might matter ;) 2008-09-16 03:06 sha256, leet 2008-09-16 03:08 -!- Kirantpatil(~kiran@122.167.182.147) has joined #tux3 2008-09-16 03:10 AH! 2008-09-16 03:10 what do you know, someone already wrote all that code, and I don't need to reimplement it... 2008-09-16 03:10 lol 2008-09-16 03:10 what, sha256? 2008-09-16 03:10 ACTION boggles at the concept 2008-09-16 03:11 nah, get_sb_bdev and kill_block_super 2008-09-16 03:11 well, still worth having written half of it by myslef 2008-09-16 03:11 ah 2008-09-16 03:17 maze, true 2008-09-16 03:17 just have to put up with some minor oddities 2008-09-16 03:17 you will still have to reimplement it 2008-09-16 03:17 but not yet 2008-09-16 03:17 probably 2008-09-16 03:18 still try to figure out what it actually accomplishes 2008-09-16 03:18 does it work? 2008-09-16 03:18 ask away 2008-09-16 03:18 not done yet, so no 2008-09-16 03:18 doesn't compile 2008-09-16 03:19 the kernel is in bad need of documentation 2008-09-16 03:20 flips: I got into a disagreement with some zfs fanboys about their file system 2008-09-16 03:20 I don't like this 2008-09-16 03:20 it's doing something and I don't know what 2008-09-16 03:20 ugh 2008-09-16 03:21 told them that they can't do much other than reformat their volume(s) if there's a corruption since they don't have an integrity checker 2008-09-16 03:21 they didn't get it, oh well 2008-09-16 03:22 lol 2008-09-16 03:22 bh, understandable 2008-09-16 03:23 the more I know about it, the more I'm glad it's not on linux 2008-09-16 03:23 they're kind of stupid and they weren't listening, no sense in arguing with folks like that 2008-09-16 03:23 they think that checksums will save the entire fucking world 2008-09-16 03:24 it'll help, but it's not the full story 2008-09-16 03:24 they need to add some metamagical themas 2008-09-16 03:24 that, and only that will save the world 2008-09-16 03:24 what's that ? 2008-09-16 03:24 the worlds already been saved - over two thousand years ago 2008-09-16 03:24 special form of checksum 2008-09-16 03:24 ... 2008-09-16 03:24 requires qubit processor 2008-09-16 03:24 uh 2008-09-16 03:25 bear in mind there was some drinking involved tonight 2008-09-16 03:25 celebrating tim's tiwn 2008-09-16 03:25 just get your file system working dude so that folks will stop trash talking behind your back and stuff 2008-09-16 03:25 tim's twins 2008-09-16 03:25 heh 2008-09-16 03:25 let them trash talk 2008-09-16 03:26 only makes them trash talkers 2008-09-16 03:26 and trash talkers always to it behind one's back 2008-09-16 03:26 nothing changes 2008-09-16 03:26 true 2008-09-16 03:26 besides, I know who they are ;) 2008-09-16 03:27 funny how those reports get around 2008-09-16 03:27 anybodny who would be trash talking now is simply somebody who can't read code 2008-09-16 03:30 maze, you must have it by now 2008-09-16 03:30 boot uml and change your life 2008-09-16 03:30 nah, I'm slow 2008-09-16 03:30 oh I have the rootfs 2008-09-16 03:30 the commands are elementary 2008-09-16 03:30 I don't have runnable (or even compileable) code 2008-09-16 03:30 doesn't matter 2008-09-16 03:30 just boot a defconfig 2008-09-16 03:30 addiction is instant 2008-09-16 03:30 faster than crack 2008-09-16 03:31 I ran out of disk space during kernel compile. 2008-09-16 03:31 :P 2008-09-16 03:31 delete gnome 2008-09-16 03:32 ow. 2008-09-16 03:32 get rid of that centos image MaZe 2008-09-16 03:32 it's on another machine 2008-09-16 03:32 oh :( 2008-09-16 03:32 get out your credit card and order a new hd 2008-09-16 03:32 660GB/$85 newegg 2008-09-16 03:32 rush 2008-09-16 03:32 overnight 2008-09-16 03:33 pay 50% of the cost of the disk ;) 2008-09-16 03:33 lol 2008-09-16 03:33 it's a laptop drive 2008-09-16 03:33 oh 2008-09-16 03:33 pay $150 2008-09-16 03:33 then 2008-09-16 03:33 better idea 2008-09-16 03:33 throw in dvd 2008-09-16 03:33 and burn 2008-09-16 03:34 delete the windows partition 2008-09-16 03:34 you know you don't use it 2008-09-16 03:34 it's only 8gb 2008-09-16 03:34 but I have a compressed fast install dump, that I'll burn 2008-09-16 03:35 nothing installs windows xp quite as fast as bzcat winxp.img.bz2 > /dev/win 2008-09-16 03:36 err, re-installs 2008-09-16 03:36 grab the image after activating? :D 2008-09-16 03:36 of course 2008-09-16 03:36 and updating 2008-09-16 03:36 nice 2008-09-16 03:36 fully patched sp3 2008-09-16 03:38 8g is about 50 compiled kernels 2008-09-16 03:38 delete and be happy 2008-09-16 03:39 well, maybe only 25 2008-09-16 03:39 objs got bloaty 2008-09-16 03:40 actually I had 2G free 2008-09-16 03:40 the build took it all up 2008-09-16 03:40 gross 2008-09-16 03:41 centos feature? 2008-09-16 03:41 ACTION couldn't reisist 2008-09-16 03:41 rather kernel build bloat 2008-09-16 03:41 sure 2008-09-16 03:41 didn't realize it was that bad 2008-09-16 03:41 although maybe because I was doing a test build of a patch 2008-09-16 03:41 there was a decent kernel build once... 2008-09-16 03:42 build with -g bloats it 2008-09-16 03:42 make allmodconfig; make bzImage 2008-09-16 03:42 oh now 2008-09-16 03:42 just don't 2008-09-16 03:42 was testing a patch 2008-09-16 03:42 make defconfig 2008-09-16 03:43 even defconfig is bloated 2008-09-16 03:43 but not even in the ballpark of what you did 2008-09-16 03:46 hehe 2008-09-16 03:46 I wonder where your kernel pulls modules from - or indeed even if it is modular 2008-09-16 03:48 do you realize your root_fs, compresses down to 24MB with bzip? 2008-09-16 03:48 you should switch to using an initramfs.cpio.gz 2008-09-16 03:48 oh yeah 2008-09-16 03:48 :-/ 2008-09-16 03:48 forgot 2008-09-16 03:48 about my lame uplink 2008-09-16 03:48 WARNING: vmlinux: 'memcpy' exported twice. Previous export was in vmlinux 2008-09-16 03:49 huh? 2008-09-16 03:49 what kernel? 2008-09-16 03:49 2.6.27-rc6 2008-09-16 03:49 make mrproper 2008-09-16 03:49 yeah! 2008-09-16 03:49 panic 2008-09-16 03:49 was 2008-09-16 03:49 ok 2008-09-16 03:49 let's go back to 2.6.26.5 2008-09-16 03:49 good idea 2008-09-16 03:50 dvd burned 2008-09-16 03:50 did windoze 2008-09-16 03:50 die 2008-09-16 03:50 ? 2008-09-16 03:50 hmm? why? 2008-09-16 03:51 oh, not yet 2008-09-16 03:51 just wondering 2008-09-16 03:51 verify 2008-09-16 03:52 I'll rzip my root_fs 2008-09-16 03:52 see how small it gets 2008-09-16 03:52 ok building 2.6.26.5 2008-09-16 03:53 it's trying to rzip 2008-09-16 03:53 kind of dimming the lights here 2008-09-16 03:53 memory wise 2008-09-16 03:53 hmm, wonder if one of the two patches I was testing was what broke rc6 2008-09-16 03:53 probably 2008-09-16 03:53 better exit firefox 2008-09-16 03:54 what the hell is rzip? 2008-09-16 03:54 tridge's zip 2008-09-16 03:54 besides sounding powerfull 2008-09-16 03:54 beats pretty much anything 2008-09-16 03:54 like a chainsaw 2008-09-16 03:54 also author of rsync 2008-09-16 03:55 ls -l root_fs* 2008-09-16 03:55 -rwxr-xr-x 1 root root 18067032 Sep 16 02:24 root_fs.rz 2008-09-16 03:55 ok? 2008-09-16 03:57 yum install rzip 2008-09-16 03:57 good taste 2008-09-16 03:58 Kernel panic - not syncing: Out of memory and no killable processes... 2008-09-16 03:58 wtf 2008-09-16 03:58 host or guest? 2008-09-16 03:58 console [mc-1] enabled 2008-09-16 03:58 ubda: unknown partition table 2008-09-16 03:58 VFS: Mounted root (ext2 filesystem) readonly. 2008-09-16 03:58 request_module: runaway loop modprobe binfmt-464c 2008-09-16 03:58 request_module: runaway loop modprobe binfmt-464c 2008-09-16 03:58 request_module: runaway loop modprobe binfmt-464c 2008-09-16 03:58 request_module: runaway loop modprobe binfmt-464c 2008-09-16 03:58 request_module: runaway loop modprobe binfmt-464c 2008-09-16 03:58 Kernel panic - not syncing: Out of memory and no killable processes... 2008-09-16 03:58 guest, after all - I'm still here 2008-09-16 03:59 you did the commands above? 2008-09-16 03:59 ah 2008-09-16 03:59 you sure that's ubd0 2008-09-16 03:59 yes 2008-09-16 03:59 cause $ file ../root_fs 2008-09-16 03:59 ../root_fs: Linux rev 0.0 ext2 filesystem data 2008-09-16 03:59 try fsck on the root_fs 2008-09-16 03:59 ah, no nevermind, that runs 2008-09-16 04:00 does um have to run as root? 2008-09-16 04:00 no 2008-09-16 04:00 wonder if it's a 64 bit bug 2008-09-16 04:00 email jeff 2008-09-16 04:00 jdike 2008-09-16 04:01 I would expect it to work though 2008-09-16 04:01 I think somebody at intel must have a 64 bit workstation 2008-09-16 04:01 $ gcc --version 2008-09-16 04:01 gcc (GCC) 4.3.0 20080428 (Red Hat 4.3.0-8) 2008-09-16 04:01 ight 2008-09-16 04:01 night 2008-09-16 04:01 red hat... that's always scary 2008-09-16 04:01 bye bye 2008-09-16 04:01 lol 2008-09-16 04:01 bye 2008-09-16 04:02 oh 2008-09-16 04:02 I know 2008-09-16 04:02 your image is 32-bit 2008-09-16 04:02 my kernel is 64-bit 2008-09-16 04:02 right 2008-09-16 04:02 it can't handle the 32-bit binaries 2008-09-16 04:02 it's supposed to work 2008-09-16 04:02 ah, but is the support code compiled in? 2008-09-16 04:02 or is it trying to modprobe 2008-09-16 04:02 seeing a 32-bit modprobe 2008-09-16 04:03 it should be? 2008-09-16 04:03 and trying to modprobe 2008-09-16 04:03 should not be modprobing 2008-09-16 04:03 anything 2008-09-16 04:03 not, it's not 2008-09-16 04:03 request_module: runaway loop modprobe binfmt-464c 2008-09-16 04:03 but you're probalby right 2008-09-16 04:03 ;-) 2008-09-16 04:03 it's supposed to work and doesn't 2008-09-16 04:03 kernel bugz 2008-09-16 04:03 ahah 2008-09-16 04:03 turn off module loading 2008-09-16 04:03 in the kernel config 2008-09-16 04:04 rusty's code 2008-09-16 04:04 I take no responsibility 2008-09-16 04:04 except module loading is precisely what I want to debug my module... 2008-09-16 04:05 CONFIG_IA32_EMULATION defaults to no 2008-09-16 04:08 forget modules in uml 2008-09-16 04:08 not the point 2008-09-16 04:08 your whole kernel is a module 2008-09-16 04:08 yeah, will this doesn't work at all 2008-09-16 04:08 modules ain't the problems 2008-09-16 04:08 modules and uml don't work that great 2008-09-16 04:08 for debugging 2008-09-16 04:09 the problem is 64-bit kernel, 32-bit userspace, no 32bit emulation 2008-09-16 04:09 well 2008-09-16 04:09 grab a rootfs 2008-09-16 04:09 yougot another bootable partition? 2008-09-16 04:09 or 2008-09-16 04:09 _compile a 32 bit kernel_ 2008-09-16 04:09 remember this is uml 2008-09-16 04:09 yeah, but how to compile a 32-bit uml 2008-09-16 04:09 ARCH=um32? 2008-09-16 04:09 hmm 2008-09-16 04:09 yah 2008-09-16 04:09 busted isn't it 2008-09-16 04:10 bummer 2008-09-16 04:10 well 2008-09-16 04:10 hmm 2008-09-16 04:10 sure, just set the config option 2008-09-16 04:10 well I do happen to have a handy setarch 2008-09-16 04:10 nope 2008-09-16 04:10 that doesn't work 2008-09-16 04:11 I guess you're right 2008-09-16 04:11 it's lamer than that 2008-09-16 04:11 well 2008-09-16 04:11 you need a 64 bit rootfs 2008-09-16 04:11 you got any other bootable partitions? 2008-09-16 04:12 mac os x ;-) 2008-09-16 04:12 that's why running under kvm would be easier 2008-09-16 04:12 I've now attempted: 2008-09-16 04:12 make defconfig ARCH=um 2008-09-16 04:13 make menuconfig ARCH=um 2008-09-16 04:13 turned on IA32_EMULATION 2008-09-16 04:13 now 2008-09-16 04:13 make oldconfig ARCH=um 2008-09-16 04:13 lots of enters 2008-09-16 04:13 make linux ARCH=um 2008-09-16 04:13 I really should get home and to bed 2008-09-16 04:14 wow, still at the plex 2008-09-16 04:14 you should 2008-09-16 04:14 yeah 2008-09-16 04:14 was playing cards till 11 2008-09-16 04:14 I apologize on behalf of all lame linux hackers 2008-09-16 04:14 about the 64/32 bit thing 2008-09-16 04:15 WARNING: vmlinux: 'memcpy' exported twice. Previous export was in vmlinux 2008-09-16 04:15 but it built... 2008-09-16 04:15 thank god for small meries 2008-09-16 04:15 mercies 2008-09-16 04:16 VFS: Cannot open root device "98:0" or unknown-block(98,0) 2008-09-16 04:16 Please append a correct "root=" boot option; here are the available partitions: 2008-09-16 04:16 Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(98,0) 2008-09-16 04:16 yeah 2008-09-16 04:16 awesome 2008-09-16 04:16 progress 2008-09-16 04:16 not really 2008-09-16 04:16 this time panic was before mount 2008-09-16 04:16 you just need to get the path to your root_fs right now 2008-09-16 04:16 no, it didn't find your rootfs 2008-09-16 04:16 lame error 2008-09-16 04:16 path was right 2008-09-16 04:17 tab completed 2008-09-16 04:17 see your command? 2008-09-16 04:17 $ linux-2.6.26.5/linux ubd0=root_fs 2008-09-16 04:17 [maze@nike l]$ ls -al root_fs 2008-09-16 04:17 -rw-r--r-- 1 maze eng 104857600 2008-09-16 02:24 root_fs 2008-09-16 04:17 ubd0 most not be compiled into the kernel 2008-09-16 04:18 must somehow have gotten unselected 2008-09-16 04:18 true 2008-09-16 04:18 if you didn't use make defconfig, probable 2008-09-16 04:18 you can strace uml 2008-09-16 04:19 I think... 2008-09-16 04:21 I think problem is 2008-09-16 04:21 make menuconfig was without ARCH=um 2008-09-16 04:21 looks like 64-bit um doesn't have an emulate 32 option 2008-09-16 04:21 that will do you 2008-09-16 04:22 64 bit kernel is supposed to run 32 bit binaries 2008-09-16 04:22 thunking is build into the kernel 2008-09-16 04:25 I don't think it knows how to parse a 32-bit elf header though 2008-09-16 04:26 you might think about that go home and crash option 2008-09-16 04:26 tomorrow get a 64 bit rootfs from somewhere, including copying it from yourself 2008-09-16 04:26 just copy your root onto another disk 2008-09-16 04:26 and plug it in 2008-09-16 04:26 beside your good old root 2008-09-16 04:30 hmm 2008-09-16 04:35 last attempt 2008-09-16 04:35 I should probably make -j2 2008-09-16 04:35 oh well 2008-09-16 04:36 don't make many modules 2008-09-16 04:36 j4, for dual intel 2008-09-16 04:36 really? 2008-09-16 04:36 just make 2008-09-16 04:36 seems to keep 1 cpu pegged 2008-09-16 04:36 two x smt 2008-09-16 04:36 lame smt 2008-09-16 04:36 oh, this is one core duo 2008-09-16 04:36 not double dual 2008-09-16 04:37 right, they kinda dropped smt 2008-09-16 04:37 ddin't they 2008-09-16 04:37 mixed bag 2008-09-16 04:37 now if we actually had a decent migrating os, It could migrate to my desktop 2008-09-16 04:37 seemedlike a good idea 2008-09-16 04:37 not really 2008-09-16 04:37 smt is still coming back 2008-09-16 04:37 dec made it work, intel not so much 2008-09-16 04:37 ht = smt lite 2008-09-16 04:37 migration is another pet peeve of mine - it shouldn't be that frickin hard 2008-09-16 04:38 of course - a decent fs is the first step ;-) 2008-09-16 04:38 it's hard because we like it hard 2008-09-16 04:38 I like reaching not only for the moon, but for the sun and alpha centauri at the same time ;-) 2008-09-16 04:38 that's we we keep getting in our own way 2008-09-16 04:39 they already had it mostly working in 2.4 2008-09-16 04:39 and then they had a beta for 2.6 2008-09-16 04:39 but I think part of the problem is the overblown syscall interface 2008-09-16 04:39 and its small compared to windows 2008-09-16 04:39 linux should be stripped down, and the linux syscall interface should be a lodable module 2008-09-16 04:40 given multiple enemas 2008-09-16 04:40 from both ends 2008-09-16 04:40 agreed 2008-09-16 04:40 it won't happen in our lifetimes 2008-09-16 04:40 that way you could replace it with whatever 2008-09-16 04:40 heh 2008-09-16 04:40 email linus 2008-09-16 04:40 and experiment with a set of syscalls which would be inherently migratable 2008-09-16 04:40 tell him it's time to make the syscall table loadable 2008-09-16 04:40 and have it per - process selectable 2008-09-16 04:41 is he going to make a laughing stock of me? 2008-09-16 04:41 he's going to say something memorable anyway 2008-09-16 04:41 might be nice to you if he's having a good day 2008-09-16 04:41 and I don't email him first ;) 2008-09-16 04:43 well, balloc_extent_from_range looks ready to try 2008-09-16 04:43 not pretty 2008-09-16 04:43 far from it 2008-09-16 04:43 qemu-kvm -M pc -cpu qemu64 -m 256 -smp 2 -net none -kernel linux-2.6.26.5/arch/x86_64/boot/bzImage -drive file=root_fs,boot=on -append 'ro root=/dev/hda' 2008-09-16 04:43 works 2008-09-16 04:43 :) 2008-09-16 04:43 amazing 2008-09-16 04:43 make mrproper && make clean && make defconfig && make bzImage 2008-09-16 04:43 what about the ARCH=um? 2008-09-16 04:43 that's not uml I guess 2008-09-16 04:44 normal 64-bit kernel 2008-09-16 04:44 yah, and a real boot 2008-09-16 04:44 me and uml send our regrets 2008-09-16 04:44 but... 2008-09-16 04:44 didn't see you boot 2008-09-16 04:44 huh? 2008-09-16 04:44 ah... 2008-09-16 04:45 oh 2008-09-16 04:45 trying to root me remotely? 2008-09-16 04:45 qemu 2008-09-16 04:45 point taken 2008-09-16 04:45 ;-) 2008-09-16 04:45 I'll leave that to shapor 2008-09-16 04:45 I thought you had some sort of ping in the image 2008-09-16 04:45 ok, you are qemu and I am uml 2008-09-16 04:45 yeah, looks like I'll stick to qemu 2008-09-16 04:45 seems to work fine 2008-09-16 04:45 somebody needs to findout why 32 bit root_fs doesn't work on 64 bit kernel 2008-09-16 04:46 I'm sure jdike will be fascinated 2008-09-16 04:46 there's some mongo dir and stuff in their 2008-09-16 04:46 I'm guessing nobody's even tried 2008-09-16 04:46 balloc_extent_from_range is ready to try 2008-09-16 04:46 not tonight 2008-09-16 04:46 or rather 2008-09-16 04:46 not now 2008-09-16 04:46 I've got a meeting at 9:30 2008-09-16 04:47 argh 2008-09-16 04:47 what rootfs did you use with qemu? 2008-09-16 04:47 yours 2008-09-16 04:47 don't go hom 2008-09-16 04:47 64-bit kernel, 32-bit rootfs - works fine 2008-09-16 04:47 sleep on the massage chair 2008-09-16 04:47 good, like it's supposed to 2008-09-16 04:47 sounds like a jdike issue 2008-09-16 04:47 yeah, I think I'll do that 2008-09-16 04:48 set it on repeat 2008-09-16 04:49 so there probably wasn't a problem with 2.6.27-rc6 after all 2008-09-16 04:49 nice to have a stable point to assign blame from 2008-09-16 04:50 7875 flips 2008-09-16 04:50 1715 MaZe 2008-09-16 04:50 1289 shapor 2008-09-16 04:50 882 bh 2008-09-16 04:50 668 konrad 2008-09-16 04:50 380 tim_dimm 2008-09-16 04:50 128 RazvanM 2008-09-16 04:50 113 vandenoever 2008-09-16 04:50 96 flipz 2008-09-16 04:50 lol 2008-09-16 04:50 irc? 2008-09-16 04:50 yeah 2008-09-16 04:50 as if I don't get enough typing 2008-09-16 04:50 maze is rising 2008-09-16 04:50 am I? 2008-09-16 04:51 think so 2008-09-16 04:51 I thought you were going up much much faster 2008-09-16 04:51 race for 2nd 2008-09-16 04:51 what do you mean race for 2nd? 2008-09-16 04:51 flipz is a real lame 2008-09-16 04:51 don't you tink? 2008-09-16 04:51 heh 2008-09-16 04:52 better get summa that sleep 2008-09-16 04:52 yeah, that's probably because he does the coding, while you sit around on irc 2008-09-16 04:52 I could be accused of contributing to the delinquency of a googler 2008-09-16 04:52 you could 2008-09-16 04:53 return found - contig + 1; <- tomorrow we see if it works 2008-09-16 04:53 new extent balloc 2008-09-16 04:53 anyway - I'm gone 2008-09-16 04:53 bye 2008-09-16 04:53 me 2 2008-09-16 07:11 -!- kushal(~kushal@121.246.32.210) has joined #tux3 2008-09-16 08:01 -!- Kirantpatil(~kiran@122.167.215.81) has joined #tux3 2008-09-16 08:01 hello list 2008-09-16 08:02 how many hours to go for the Part-3 of tux3 university ? 2008-09-16 09:53 -!- MaZe(~MaZe@216-239-45-4.google.com) has joined #tux3 2008-09-16 10:25 -!- RazvanM(~RazvanM@dazzler.isi.jhu.edu) has joined #tux3 2008-09-16 10:45 -!- kushal(~kushal@121.246.33.21) has joined #tux3 2008-09-16 10:51 -!- MaZe(~MaZe@216-239-45-4.google.com) has joined #tux3 2008-09-16 10:55 -!- tim_dimm(~timothyhu@cpe-76-90-98-247.socal.res.rr.com) has joined #tux3 2008-09-16 10:58 howdy 2008-09-16 10:58 when's the next tux3 university scheduled? 2008-09-16 11:37 -!- MaZe(~MaZe@216-239-45-4.google.com) has joined #tux3 2008-09-16 11:50 -!- Kirantpatil(~kiran@122.167.176.249) has joined #tux3 2008-09-16 11:52 -!- Kirantpatil(~kiran@122.167.176.249) has left #tux3 2008-09-16 12:00 -!- shapor(~shapor@yzf.shapor.com) has joined #tux3 2008-09-16 12:00 ACTION is back 2008-09-16 12:00 hrm thats weird i got banned from oftc.net 2008-09-16 12:00 maybe my bot went crazy 2008-09-16 12:03 ah no i guess it was everyone 2008-09-16 12:03 heh 2008-09-16 12:52 -!- MaZe(~MaZe@216-239-45-4.google.com) has joined #tux3 2008-09-16 13:17 folks 2008-09-16 13:58 -!- shapor(~shapor@yzf.shapor.com) has joined #tux3 2008-09-16 14:06 morning 2008-09-16 14:07 it's an extent morning for #tux3 2008-09-16 14:38 hey 2008-09-16 14:38 hi bh 2008-09-16 14:39 how's it going ? 2008-09-16 14:41 coding bitops 2008-09-16 14:41 fun 2008-09-16 14:41 extents are fun 2008-09-16 14:41 been researching tree locking? 2008-09-16 14:41 there's a lot written on the subject 2008-09-16 14:55 -!- MaZe(~MaZe@216-239-45-4.google.com) has joined #tux3 2008-09-16 14:57 ok, looks like we have extent enabled balloc now 2008-09-16 14:57 but 2008-09-16 14:57 lots still to do 2008-09-16 14:57 on extents 2008-09-16 14:58 messy messy 2008-09-16 16:02 tux3 noses over 7K lines 2008-09-16 16:02 decimal K 2008-09-16 16:05 Sun is using mercurial for its new project site 2008-09-16 16:06 I think that means mercurial wins 2008-09-16 16:06 big props to matt 2008-09-16 16:06 http://projectkenai.com/projects/xvmserver/sources/earlyaccess/show 2008-09-16 16:06 clueful of Sun 2008-09-16 16:06 I'm shocked ;) 2008-09-16 16:18 projectkenai is new and doesn't have git yet, but they plan to 2008-09-16 16:18 if it's the same site I'm remembering 2008-09-16 16:19 yep, it is 2008-09-16 16:58 flips: nice 2008-09-16 17:02 -!- kbingham(~kbingham@92.9.62.202) has joined #tux3 2008-09-16 17:17 I'm thinking back on a design decision I made pretty early for the prototype - to depart from the usual kernel get_block model and have tux3 actually initiate the IO at that point, unlike get_block where the fs just tells the VFS where a particular logical block is supposed to be read/written physically 2008-09-16 17:17 I am increasingly getting the feeling that that decision was right 2008-09-16 17:17 especially as I get working on extents 2008-09-16 17:18 and took a look at how the btrfs guys do extents 2008-09-16 17:18 that is scary 2008-09-16 17:18 looks like they want to go make big changes to the vfs 2008-09-16 17:18 without really considering the alternatives 2008-09-16 17:18 I might not have looked close enough, but that's what it looks like on first blush 2008-09-16 17:28 when are atomic commits going to work ? 2008-09-16 17:28 after extents 2008-09-16 17:29 or sooner if you want to code it 2008-09-16 17:29 fun 2008-09-16 17:31 flips: what was that disk failure article you were mentioning last night? 2008-09-16 17:32 got a link? 2008-09-16 17:32 just a sec 2008-09-16 17:32 http://alumnit.ca/~apenwarr/log/?m=200809#08 2008-09-16 17:40 interesting 2008-09-16 17:41 nearly sk8 oclock 2008-09-16 17:42 ACTION is getting tired of checking in extent bits 2008-09-16 17:43 wow i'd never heard of ionice 2008-09-16 17:43 awesome! 2008-09-16 17:43 "Linux supports io scheduling priorities and classes since 2.6.13 with the CFQ io scheduler." 2008-09-16 17:43 !! 2008-09-16 17:44 well 2008-09-16 17:44 have i been living under a rock? 2008-09-16 17:44 don't get _too_ excited 2008-09-16 17:44 cfq is, um 2008-09-16 17:44 you know 2008-09-16 17:44 there's a reason it's not the default 2008-09-16 17:44 just the fact there is such an interface is reassuring 2008-09-16 17:44 yes 2008-09-16 17:45 pluggable disk elevators 2008-09-16 17:45 if it doesn't work as advertised thats simply a bug to file 2008-09-16 17:45 been in for 4-5 years 2008-09-16 17:45 then someone smarter than me can fix it ;) 2008-09-16 17:45 danger is when somebody less smart than you fixes it 2008-09-16 17:47 ok, we have extent allocate and extent free now 2008-09-16 17:47 not really great versions of, but simple and serviceable for now 2008-09-16 17:47 that was the easy part 2008-09-16 18:06 -!- cdk(~chinmay@121.246.33.227) has joined #tux3 2008-09-16 18:29 -!- RalucaM(~ral@londo.cnds.jhu.edu) has joined #tux3 2008-09-16 18:33 -!- Aks(~ankitsriv@123.239.79.30) has joined #tux3 2008-09-16 18:34 -!- Aks(~ankitsriv@123.239.79.30) has left #tux3 2008-09-16 18:53 -!- kbingham(~kbingham@92.8.19.189) has joined #tux3 2008-09-16 19:03 -!- tim_dimm(~timothyhu@cpe-76-90-98-247.socal.res.rr.com) has joined #tux3 2008-09-16 19:09 -!- kbingham(~kbingham@92.8.3.46) has joined #tux3 2008-09-16 19:13 -!- stargazr5(~gauravstt@59.95.18.36) has joined #tux3 2008-09-16 19:20 -!- Kirantpatil(~kiran@122.167.218.72) has joined #tux3 2008-09-16 19:20 -!- Kirantpatil(~kiran@122.167.218.72) has left #tux3 2008-09-16 19:43 -!- RazvanM(~RazvanM@pool-151-196-118-156.balt.east.verizon.net) has joined #tux3 2008-09-16 19:45 15 minutes and counting 2008-09-16 19:54 OT: http://www.noodleson.com/store/images/nongshim/vegetal.jpg 2008-09-16 19:57 -!- RalucaM(~ral@pool-151-196-118-156.balt.east.verizon.net) has joined #tux3 2008-09-16 19:57 seems on topic to me 2008-09-16 19:57 :-) 2008-09-16 19:57 hi ralucam 2008-09-16 19:57 OT but important 2008-09-16 19:57 my new chair is comfy 2008-09-16 19:57 hey tim 2008-09-16 19:58 yes 2008-09-16 19:58 online 2008-09-16 19:58 that's important 2008-09-16 19:58 and this watermellon is delicious 2008-09-16 19:58 hi everybody 2008-09-16 19:58 everybody warming up their browers? 2008-09-16 19:59 ACTION is trying to do at least a modest part of the homework... 2008-09-16 19:59 standard precaution is to restart firefox 2008-09-16 19:59 so it doesn't go oom when I'm trying to talk ;) 2008-09-16 19:59 ugh, oh right, what was the homework? 2008-09-16 20:00 read the superblock? ;-) 2008-09-16 20:00 flips: homework is: know how the root dir is loaded and initialized, and now that differs from how any other inode is opened 2008-09-16 20:00 it was about loading the root directory 2008-09-16 20:00 -!- pranith(7aa040b1@webchat.mibbit.com) has joined #tux3 2008-09-16 20:00 and what did we find? 2008-09-16 20:01 that it gets loaded explicitely 2008-09-16 20:01 because... 2008-09-16 20:01 because dir lookup doesn't work 2008-09-16 20:01 well it's the mount point 2008-09-16 20:02 because there is no dir to look up in 2008-09-16 20:02 root of the tree and all that 2008-09-16 20:02 ACTION is searching for s_root... 2008-09-16 20:02 so we have to open the root dir "manually", using functionality that normally gets called by something like ext2_lookup 2008-09-16 20:02 not quite that function 2008-09-16 20:02 anyway 2008-09-16 20:03 we're starting somewhere different today 2008-09-16 20:03 because maze wants to go faster ;) 2008-09-16 20:03 so let's go to sys_write 2008-09-16 20:03 I'm guiltless - I tell you... 2008-09-16 20:03 http://lxr.linux.no/linux+v2.6.26.5/fs/dcache.c#L1062 2008-09-16 20:03 ok ok ok ok 2008-09-16 20:03 I think we killed lxr 2008-09-16 20:04 seems 2008-09-16 20:04 next time I'll go there before I announce the destination ;) 2008-09-16 20:04 http://lxr.linux.no/linux+v2.6.26.5/fs/read_write.c#L370 2008-09-16 20:04 http://lxr.linux.no/linux+v2.6.26.5/fs/read_write.c#L370 2008-09-16 20:04 it works from here 2008-09-16 20:04 works here too 2008-09-16 20:04 Razvan's always faster ;-) 2008-09-16 20:04 ok, who wants to walk down into it? 2008-09-16 20:04 instead of me this time? 2008-09-16 20:05 seems to me, razvanm does that pretty well 2008-09-16 20:05 you know the first few layers 2008-09-16 20:05 it's just the same idea as sys_open 2008-09-16 20:05 ACTION is doesn't too much about fs yet :( 2008-09-16 20:05 you know how to poke down into a syscall though 2008-09-16 20:05 file_pos_read and file_pos_write are probably to fetch and store the current file offset 2008-09-16 20:05 just keep clicking until you see something that isn't obvious 2008-09-16 20:06 let's look at those 2008-09-16 20:06 fget_light and fput_light must be fd to struct file lookup with locking 2008-09-16 20:06 so all that's left is vfs_write 2008-09-16 20:06 pretty simple (file_pos_read/write) 2008-09-16 20:06 which was kind of obvious to begin with ;-) 2008-09-16 20:06 I don't know why they're even abstracted 2008-09-16 20:07 fget/put_light are demented 2008-09-16 20:07 two of the most subtle and demented functions in the entire kernel 2008-09-16 20:07 don't worry about them today ;) 2008-09-16 20:07 they were conceived by a vile an twisted mind, and get to live because they are fast 2008-09-16 20:07 what's demented about them? 2008-09-16 20:07 heh 2008-09-16 20:07 later 2008-09-16 20:07 really 2008-09-16 20:08 google if you must 2008-09-16 20:08 http://lxr.linux.no/linux+v2.6.26.5/fs/read_write.c#L313 2008-09-16 20:08 ok, that's vfs_write 2008-09-16 20:08 suffice to say that they keep our file from disappearing while we are writing to it 2008-09-16 20:08 it would be bad otherwise 2008-09-16 20:08 right - locking 2008-09-16 20:08 razvanm, good, and what do you see there? 2008-09-16 20:09 a bunch of permission checks 2008-09-16 20:09 and then a f_op->write call 2008-09-16 20:09 f_op->write if exists 2008-09-16 20:09 typical, right? 2008-09-16 20:09 provided it's available 2008-09-16 20:09 what you don't see is any locks being taken 2008-09-16 20:09 ot do_sync_write otherwise 2008-09-16 20:09 ot = or 2008-09-16 20:09 there is _very little locking_ in this path 2008-09-16 20:09 helping make it fast 2008-09-16 20:09 and a cute inc_syscw 2008-09-16 20:09 -!- kbingham(~kbingham@92.8.217.48) has joined #tux3 2008-09-16 20:10 the consequence of that is, the filesystem can be hit in a very parallel way 2008-09-16 20:10 what is rw_verify_area? 2008-09-16 20:10 probably locking 2008-09-16 20:10 sometimes in ways that don't make sense, or are from buggy, racy applications, and the filesystem has to do something reasonable 2008-09-16 20:10 i.e., not crash and not corrupt 2008-09-16 20:10 rw_verify_area... hmm 2008-09-16 20:10 as in byte-range locks 2008-09-16 20:10 newish thing 2008-09-16 20:11 no sorry 2008-09-16 20:11 it's implementing flock 2008-09-16 20:11 bad name 2008-09-16 20:11 very 2008-09-16 20:11 http://lxr.linux.no/linux+v2.6.26.5/fs/read_write.c#L196 2008-09-16 20:11 we don't care about it really 2008-09-16 20:11 I'd guess it checks no-one else has locked the area we're about to write to 2008-09-16 20:11 normally nobody uses flock 2008-09-16 20:12 crufty old baggage 2008-09-16 20:12 more interesting that selinux has a hook there 2008-09-16 20:12 the "security_*" <- typical selinux hook 2008-09-16 20:12 flips: inc_syscw.. tsk->syscw++ 2008-09-16 20:12 but this is not really interesting, let's pop back out and go deeper 2008-09-16 20:12 that's a generic security hook though right? 2008-09-16 20:12 yes 2008-09-16 20:13 I forget what we call the generic harness 2008-09-16 20:13 http://lxr.linux.no/linux+v2.6.26.5/fs/read_write.c#L313 <- back here 2008-09-16 20:13 next we see that meme again 2008-09-16 20:14 our fs can either completely replace the write logic with its own, or the vfs will supply a basic framework and call lower level methods in the fs 2008-09-16 20:14 327 if (file->f_op->write) 2008-09-16 20:14 328 ret = file->f_op->write(file, buf, count, pos); 2008-09-16 20:14 very few fs's will use this hook 2008-09-16 20:15 i thought we were supposed to use the vfs framework... 2008-09-16 20:15 http://lxr.linux.no/linux+v2.6.26.5/fs/read_write.c#L288 2008-09-16 20:15 almost all continue on down into do_sync_write 2008-09-16 20:15 which is still the vfs 2008-09-16 20:15 most filesystems don't want to have the responsibility of doing all the things the vfs is about to do now 2008-09-16 20:16 -!- amey(~amey@116.73.35.180) has joined #tux3 2008-09-16 20:16 http://lxr.linux.no/linux+v2.6.26.5/fs/read_write.c#L288 <- do_sync_write 2008-09-16 20:16 so, internally the kernel is kind of aio oriented 2008-09-16 20:16 asynchronous IO 2008-09-16 20:17 and synchronous IO is just a shell around it of the form "start and IO op; wait on a wait queue until its done" 2008-09-16 20:17 we see that here 2008-09-16 20:17 very simple... if you don't poke into the details 2008-09-16 20:17 we will, but later 2008-09-16 20:17 http://lxr.linux.no/linux+v2.6.26.5/fs/ext2/file.c#L50 2008-09-16 20:17 http://lxr.linux.no/linux+v2.6.26.5/mm/filemap.c#L2487 2008-09-16 20:17 so now... we lose the trail 2008-09-16 20:18 because the vfs calls the real write action through a variable 2008-09-16 20:18 any suggestions how we can pick up that trail again? 2008-09-16 20:18 aio_write :P 2008-09-16 20:18 filp->f_op->aio_write 2008-09-16 20:18 right 2008-09-16 20:18 we can grep the entire kernel for it 2008-09-16 20:19 or we can go back to ext2/inode.c 2008-09-16 20:19 where I know it is ;) 2008-09-16 20:19 let's do that 2008-09-16 20:19 http://lxr.linux.no/linux+v2.6.26.5/mm/filemap.c#L2364 2008-09-16 20:19 you're getting ahead ;) 2008-09-16 20:19 let's see how we get there 2008-09-16 20:20 and I was wrong about the file 2008-09-16 20:20 http://lxr.linux.no/linux+v2.6.26.5/fs/ext2/file.c#L50 2008-09-16 20:20 interesting 2008-09-16 20:21 ? 2008-09-16 20:21 now we see that ext2 just fills that in with a generic function 2008-09-16 20:21 that maze already found 2008-09-16 20:21 so lets clikc on it and go to filemap 2008-09-16 20:21 even this a fs is not interesting in implementing it :D 2008-09-16 20:21 that's right 2008-09-16 20:21 ext2 mostly lets the vfs do everything for it 2008-09-16 20:21 and its still 7,500 lines long 2008-09-16 20:21 worth considering what's in those 7,500 lines 2008-09-16 20:22 keep in mind that the VFS was essentially created just by taking a functioning filesystem and chopping it in half 2008-09-16 20:22 the top half, which became the vfs 2008-09-16 20:23 and the bottom half, which is a bunch of specific methods for doing things like figuring out the position of a block on disk 2008-09-16 20:23 and the bottom half which became the fs drivers 2008-09-16 20:23 ext2 should still have something to say about the write... 2008-09-16 20:23 which because ext2 and all its friends 2008-09-16 20:23 might not 2008-09-16 20:23 ext2 is not journaled 2008-09-16 20:23 might just have a get_disk_block(file, offset) 2008-09-16 20:23 ext2 is happy to let the vfs take over completely here, but of course, the vfs will come back to ext2 at some point 2008-09-16 20:23 why not ext3? 2008-09-16 20:23 and allocate/free_disk_block 2008-09-16 20:23 we will get there in about 5-10 minutes 2008-09-16 20:24 ok 2008-09-16 20:24 for comparison, you could look at ext3/file.c 2008-09-16 20:24 let's do that later 2008-09-16 20:24 http://lxr.linux.no/linux+v2.6.26.5/+code=generic_file_aio_write 2008-09-16 20:24 http://lxr.linux.no/linux+v2.6.26.5/fs/ext2/file.c#L50 2008-09-16 20:24 ext2 is not journaled - so each file is just a read/write collection of blocks on disk 2008-09-16 20:25 even ext3 doesn't normally journal data 2008-09-16 20:25 so all you need is the ability to lookup a given files/offsets block location on disk and you can read/write just fine 2008-09-16 20:25 but it can... 2008-09-16 20:25 next step: http://lxr.linux.no/linux+v2.6.26.5/mm/filemap.c#L2364 2008-09-16 20:25 yes, and so it must supply different methods for its different journalling options 2008-09-16 20:26 http://lxr.linux.no/linux+v2.6.26.5/fs/ext3/file.c#L113 2008-09-16 20:26 not *must*, but that is what it does 2008-09-16 20:26 113 .aio_read = generic_file_aio_read, 2008-09-16 20:26 114 .aio_write = ext3_file_write, 2008-09-16 20:26 so ext3 has it's own write, but uses the generic read 2008-09-16 20:26 thanks razvanm 2008-09-16 20:26 notice that generic_file_aio_write didn't really do much 2008-09-16 20:27 generic read but custom write... interesting 2008-09-16 20:27 jsut took care of some options 2008-09-16 20:27 optional unix semantics 2008-09-16 20:27 razvanm, sure, no journal needed on read 2008-09-16 20:28 finally, __generic_file_aio_write_nolock is doing something 2008-09-16 20:28 not much... but more than the others 2008-09-16 20:28 aaaa... ext3 :D 2008-09-16 20:28 since on read you can just let the generic file/offset block lookup code handle it, but on write - you might need to go through the journal if the right mount optiones (data=ordered I think) were used 2008-09-16 20:28 or data=journaled - never sure 2008-09-16 20:28 here we see readv being implemented 2008-09-16 20:28 um 2008-09-16 20:28 writev 2008-09-16 20:29 where? 2008-09-16 20:29 generic_segment_checks(iov, &nr_segs, &ocount, VERIFY_READ); 2008-09-16 20:29 nr_segs... writev segs 2008-09-16 20:29 not important 2008-09-16 20:29 easy enough to understand 2008-09-16 20:30 is that verifying we can read the ram the user passed us? 2008-09-16 20:30 probably 2008-09-16 20:30 let's find out 2008-09-16 20:30 1149 /* 2008-09-16 20:30 1150 * If any segment has a negative length, or the cumulative 2008-09-16 20:30 1151 * length ever wraps negative then return -EINVAL. 2008-09-16 20:30 1152 */ 2008-09-16 20:31 no, just checking for properly formed structs 2008-09-16 20:31 if (access_ok(access_flags, iv->iov_base, iv->iov_len)) 2008-09-16 20:31 I htink it does full access checks 2008-09-16 20:31 security 2008-09-16 20:31 note the return -EFAULT 2008-09-16 20:32 so we will rely on the mmu 2008-09-16 20:32 to fault 2008-09-16 20:32 and sometimes check for faulting contitions by hand 2008-09-16 20:32 http://lxr.linux.no/linux+v2.6.26.5/include/asm-m32r/uaccess.h#L108 <- access_ok just within memory or not 2008-09-16 20:32 no I think it checks by hand, but only returns EFAULT if first part is bad, otherwise it marks how many are good, and ignore the rest 2008-09-16 20:33 vfs_check_frozen implements the filesystem "freeze" feature... which is used for snapshotting 2008-09-16 20:33 kind of misconceived 2008-09-16 20:33 so you'll get a partial write instead of an EFAULT if you have a bad mapping in the middle of a writev 2008-09-16 20:33 sounds reasonable 2008-09-16 20:33 can't realy on mmu since we probably will use dma 2008-09-16 20:34 then we have a bunch of code associated with direct IO 2008-09-16 20:34 which we are going to skip 2008-09-16 20:34 http://lxr.linux.no/linux+v2.6.26.5/mm/filemap.c#L2319 2008-09-16 20:34 maze, true 2008-09-16 20:34 so we're going to check access somewhere 2008-09-16 20:34 but not here 2008-09-16 20:35 notice, no real work got done 2008-09-16 20:35 we're still just deepening the call chain and allowing for various options and whatnot 2008-09-16 20:35 at this point, we're seriously not expecting any real work to get done ;-) 2008-09-16 20:35 then we get to generic_file_buffered_write 2008-09-16 20:35 ACTION does! :D 2008-09-16 20:35 think that's going to do work? 2008-09-16 20:36 nope 2008-09-16 20:36 you'd be right 2008-09-16 20:36 short break 2008-09-16 20:36 while I fill the wine glass 2008-09-16 20:37 wine? i thought u wanted beer 2008-09-16 20:37 ;) 2008-09-16 20:37 nobody sent any 2008-09-16 20:37 aww 2008-09-16 20:37 ok here we go again 2008-09-16 20:38 ACTION thinks a_ops->write_begin must be the key... 2008-09-16 20:38 we have a ->write_begin option 2008-09-16 20:38 which is new for me 2008-09-16 20:38 the two functions are right next to each other 2008-09-16 20:38 and look similat 2008-09-16 20:38 and that 2copy thing, likewise 2008-09-16 20:38 probably something aio related 2008-09-16 20:38 looks like braindamange 2008-09-16 20:39 the 2copy is also using some a_ops 2008-09-16 20:39 notice a_ops 2008-09-16 20:39 is struct addres_space_operations 2008-09-16 20:40 http://lxr.linux.no/linux+v2.6.26.5/include/linux/fs.h#L444 2008-09-16 20:40 lost the scent for a moment 2008-09-16 20:40 ACTION knows readpage from romfs... 2008-09-16 20:40 sounds mmap-ish 2008-09-16 20:42 ACTION has to go to work :( 2008-09-16 20:42 ACTION says bbyee, do post the logs ... 2008-09-16 20:42 guessing a_ops are operations that can be performed on mmaped fs pages 2008-09-16 20:42 with ability for fs to override it to trigger journaling etc 2008-09-16 20:42 bye bye 2008-09-16 20:42 ok, this code has bben "worked on" 2008-09-16 20:42 rearranged hopefully for a good reason 2008-09-16 20:43 readpage is the only 'read' the romfs is doing 2008-09-16 20:43 http://lxr.linux.no/linux+v2.6.26.5/mm/filemap.c#L2231 2008-09-16 20:43 so its called not only for mmap stuff 2008-09-16 20:43 generic_perform_write 2008-09-16 20:43 that may be an optimization though 2008-09-16 20:43 this is where the real action happens 2008-09-16 20:43 who knows... 2008-09-16 20:43 or one form of real action 2008-09-16 20:43 http://lxr.linux.no/linux+v2.6.26.5/mm/filemap.c#L2231 2008-09-16 20:43 we're going to talk about a_ops 2008-09-16 20:44 this is the key to most filesystem io in linux 2008-09-16 20:45 ok, so here is a typical write mem 2008-09-16 20:45 write_begin, write_end 2008-09-16 20:45 right 2008-09-16 20:45 and in between we copy data from userspace 2008-09-16 20:45 onto a page 2008-09-16 20:45 copied = iov_iter_copy_from_user_atomic(page, i, offset, bytes); 2008-09-16 20:45 so what is in write_beging? probably get a page into the page cache of an inode 2008-09-16 20:46 and write_end will send that page down to the hardware 2008-09-16 20:46 looks like the kernel basically mmaps in the page and then mmaps it out 2008-09-16 20:46 copy_from_user gets the data, and generates EFAULT if necessary 2008-09-16 20:46 either because of illegal access, or page swapped out 2008-09-16 20:47 pagefault_disable(); 2008-09-16 20:47 uhm? 2008-09-16 20:47 things get interested in the page was swapped out to a swapfile onthe same filesystem 2008-09-16 20:47 interesting 2008-09-16 20:47 swapfile on the same filesystem?? 2008-09-16 20:47 right 2008-09-16 20:47 swapfile is not a separate fs? 2008-09-16 20:47 trying to prevent recursive fault 2008-09-16 20:47 sounds like that just turned off page-in 2008-09-16 20:47 I don't have the details at hand just now 2008-09-16 20:48 razvanm, swap can be separate, or it can be on a filesystem 2008-09-16 20:48 there are some nasty possible recursions when its on a filesystem 2008-09-16 20:48 very nasty 2008-09-16 20:48 ACTION doesn't know how to create a swap on a fs :| 2008-09-16 20:48 2 minutes until question time 2008-09-16 20:49 it's going to be another "cliffhanger" ending 2008-09-16 20:49 :-) 2008-09-16 20:49 lol 2008-09-16 20:49 now this function is not very instructive 2008-09-16 20:49 because it doesn't directly use the page cache ops 2008-09-16 20:49 it provides hooks for them 2008-09-16 20:49 are you sure we went into the right function? not the 2copy one? 2008-09-16 20:49 let's see if we can pop out and find a variant that does use the page cache ops 2008-09-16 20:50 I'm sure we didn't 2008-09-16 20:50 somebody has been messing with names 2008-09-16 20:50 I hope it was for a good reason 2008-09-16 20:50 it isn't always 2008-09-16 20:50 http://lxr.linux.no/linux+v2.6.26.5/mm/filemap.c#L2063 2008-09-16 20:50 and as you can see, the call chain is kind of unreasonably deep 2008-09-16 20:50 this all seems extremely complex 2008-09-16 20:51 for now I can't say unnecessarily... but... 2008-09-16 20:51 what does the 2copy mean? 2008-09-16 20:51 yes, this looks like what remains of good old generic_write 2008-09-16 20:51 it means brain-dead original 1st copy apparently 2008-09-16 20:51 maze, I am happy to have reached your "complex" threshold 2008-09-16 20:51 it gets more complex 2008-09-16 20:52 in _2copy, we will alloc pages, map them into a page cache, copy data onto them, and submit them to disk 2008-09-16 20:52 we will call the fs's ->write_page method to do the latter 2008-09-16 20:53 and that method will figure out _where_ on disk the page should go 2008-09-16 20:53 I don't know wyat 2copy means 2008-09-16 20:53 why do we have to copy_from_user 2008-09-16 20:53 can't we write directly from userspace data? 2008-09-16 20:53 feels like... wanking... but I will know for sure for thursdays's session 2008-09-16 20:54 maze, because this is _buffered_ write 2008-09-16 20:54 we are placing the data in cache 2008-09-16 20:54 oh, right 2008-09-16 20:54 we can't just place references to pages in cache 2008-09-16 20:54 because the user data is not necessarily properly aligned 2008-09-16 20:54 couldn't we just rip the page out from under the user, and give him a r/o cow page? 2008-09-16 20:54 linus does want to attempt something like that 2008-09-16 20:54 but it's too hard, even for him 2008-09-16 20:55 ACTION doesn't see the write_page.... 2008-09-16 20:55 me neither 2008-09-16 20:55 there is prepare_write 2008-09-16 20:55 http://lxr.linux.no/linux+v2.6.26.5/mm/filemap.c#L2192 2008-09-16 20:55 home is: see the writepage 2008-09-16 20:55 ;-) 2008-09-16 20:55 and commit_write 2008-09-16 20:55 on thursday we will pick up at the writepage 2008-09-16 20:56 I'm not sure why there would need to be a write page 2008-09-16 20:56 yep, it looks like _2copy really is the new incarnation of generic_write 2008-09-16 20:56 it used to just be generic_write 2008-09-16 20:56 but then it started getting more and more "wrapped" 2008-09-16 20:56 until we see this thing 2008-09-16 20:56 unreadable thing you could say 2008-09-16 20:56 :-) 2008-09-16 20:57 maze, the purpose of the ->writepages in there is to get dirty, buffered pages onto disk 2008-09-16 20:57 -!- kbingham(~kbingham@92.20.210.138) has joined #tux3 2008-09-16 20:57 won't commit_write do that? 2008-09-16 20:57 ah, that's what you asked 2008-09-16 20:57 why two 2008-09-16 20:57 no good reason actually 2008-09-16 20:58 there's usually a "prepare_write" and a "commit_write" 2008-09-16 20:58 http://lxr.linux.no/linux+v2.6.26.5/include/linux/fs.h#L458 2008-09-16 20:58 one or the other generally doesn't do much 2008-09-16 20:59 there's a writeage, writepages, prepatre_write,commit_write,write_begin,write_end ... 2008-09-16 20:59 pick'n'choose 2008-09-16 20:59 yes 2008-09-16 20:59 big mess 2008-09-16 20:59 linux IO is trying to find its identity 2008-09-16 20:59 lol 2008-09-16 21:00 it was simpler and nicer in the past? 2008-09-16 21:00 beginning of 2.6 was simpler, yes 2008-09-16 21:00 o_direct is a very good thing, but it added considerable complexity 2008-09-16 21:00 it looks like different file systems use different interfaces 2008-09-16 21:00 likewise aio 2008-09-16 21:01 maze, somewhat true 2008-09-16 21:01 almost everybody uses generic_write 2008-09-16 21:01 and thus we have a lot 2008-09-16 21:01 not much global structural analysis goes on 2008-09-16 21:01 so that the structure can be simplified 2008-09-16 21:01 because that doesn't add new features 2008-09-16 21:01 or fix bugs 2008-09-16 21:02 are the address_space_operations fs internal? 2008-09-16 21:02 introduces them more likely 2008-09-16 21:02 or are they more global mm? 2008-09-16 21:02 but it makes the code messy 2008-09-16 21:02 like many such things in linux, they are usually library methods 2008-09-16 21:02 kernel library 2008-09-16 21:02 which the fs can lightly wrap 2008-09-16 21:02 or use directly 2008-09-16 21:03 the ->writepages thing is a relatively new invention 2008-09-16 21:03 that allows the filesystem to map more than one page at a time for IO 2008-09-16 21:03 lead to nice benchmark improvements 2008-09-16 21:03 and more mess in filemap.c 2008-09-16 21:03 and this is where variable page sizes will get interesting 2008-09-16 21:04 filemap.c is where most of the impact is, yes 2008-09-16 21:04 insightful 2008-09-16 21:04 4 minutes over ;) 2008-09-16 21:04 how did we do for pacing today? 2008-09-16 21:04 i try 2008-09-16 21:04 nice pace 2008-09-16 21:04 pretty decent I think 2008-09-16 21:05 sorry I asked so many questions 2008-09-16 21:05 ok, we will be back into write on thursday 2008-09-16 21:05 ;-) 2008-09-16 21:05 tim_dimm: ask questions - it's the only way to learn anything 2008-09-16 21:05 ACTION is not happy with the length though ;-) 2008-09-16 21:05 homework is: find the implementations of the ->writepage calls in ext2 2008-09-16 21:05 I was just trying to figure out what / where to read 2008-09-16 21:05 never been inside the kernel like that before 2008-09-16 21:06 it's bizarre, isn't it 2008-09-16 21:06 yeah 2008-09-16 21:06 so here's a question: buffered, aio, o_direct - what are the permutations/combinations, what do they mean, and how do they interact with each other if the same spot is being accessed via different means 2008-09-16 21:06 maze, very good question, and the answer is: with considerable complexity 2008-09-16 21:06 lovely answer 2008-09-16 21:06 it is necessary to maintain cache consistency with all possible combinations 2008-09-16 21:07 that's like my friend at work, who sits next to me and regularly answers either/or questions with a 'yes' spoken in a deadpan voice 2008-09-16 21:07 are there hooks for cache consistency or is it handle another way? 2008-09-16 21:07 that is why that section handling o_direct that we skipped is so... um... interesting 2008-09-16 21:07 tim_dimm, the vfs handles it 2008-09-16 21:07 and there are rules that the fs has to follow 2008-09-16 21:07 O_DIRECT means unbuffered straight to disk, right? 2008-09-16 21:08 basically "do not skate over that cliff" 2008-09-16 21:08 and is pretty meaningless for read... 2008-09-16 21:08 maze, right 2008-09-16 21:08 o_direct write has to invalidate any buffer data at that point 2008-09-16 21:08 all synchronous io should be easily implementable via aio 2008-09-16 21:08 also flush out dirty buffered data in that range 2008-09-16 21:08 did you guys cover vfs on another tux3 night? 2008-09-16 21:08 maze, it is 2008-09-16 21:09 tim_dimm, partly 2008-09-16 21:09 this is part of the vfs we're doing now 2008-09-16 21:09 so you basically need to support {buffered | direct } asynchronous io 2008-09-16 21:09 would it be worthwhile to have an entire session on it?' 2008-09-16 21:09 we did an easy one first 2008-09-16 21:09 maze, yes 2008-09-16 21:09 in fact we already looked at the functions that support it 2008-09-16 21:10 tim_dimm, that was essentially the first session 2008-09-16 21:10 o_direct write has to invalidate any buffered data at that point - uh? 2008-09-16 21:10 k, I'll revisit in the logs 2008-09-16 21:10 maze, yes 2008-09-16 21:10 buffered data for what? 2008-09-16 21:10 somebody might have been reading/writing the device with buffered ops at the same time 2008-09-16 21:11 this is not uncommon 2008-09-16 21:11 oh, the buffered but not yet written stuff gets dropped? 2008-09-16 21:11 flushed to disk 2008-09-16 21:11 or overwritten with the - so flushed, not invalidated 2008-09-16 21:11 what gets invalidateD? 2008-09-16 21:11 you're right, fully replaced pages get dropped 2008-09-16 21:11 partially replaced pages have to be flushed 2008-09-16 21:12 so it's not so much invalidated, as overwritten and thus dropped/replaced with the new data 2008-09-16 21:12 right 2008-09-16 21:12 haven't spent a lot of time in that code myself 2008-09-16 21:12 but that's correct 2008-09-16 21:12 does O_DIRECT mean anything on read? 2008-09-16 21:12 yes 2008-09-16 21:13 will not read from buffer afaic 2008-09-16 21:13 Try to minimize cache effects of the I/O to and from this file 2008-09-16 21:13 but I could be wrong 2008-09-16 21:13 according to man open, basically skip buffer cache populating 2008-09-16 21:13 anything not buffered is read directly from disk and not added to the page cache 2008-09-16 21:13 unless already there 2008-09-16 21:13 so o_direct read avoids double buffering 2008-09-16 21:14 O_DIRECT (Since Linux 2.4.10) 2008-09-16 21:14 Try to minimize cache effects of the I/O to and from this file. In general this will degrade performance, but it is useful in special 2008-09-16 21:14 situations, such as when applications do their own caching. File I/O is done directly to/from user space buffers. The I/O is syn- 2008-09-16 21:14 chronous, that is, at the completion of a read(2) or write(2), data is guaranteed to have been transferred. See NOTES below for further 2008-09-16 21:14 discussion. 2008-09-16 21:14 A semantically similar (but deprecated) interface for block devices is described in raw(8). 2008-09-16 21:14 I'm not sure what it does with already-buffered data 2008-09-16 21:14 if dirty then it _must_ use the dirty version 2008-09-16 21:14 so, how expensive is a write to read only page fault? 2008-09-16 21:14 from man 2 open, sorry for the long lines 2008-09-16 21:14 but I don't know if it does that by flushing it first, then reading it back, or doing buffered read just for that bit 2008-09-16 21:14 yeah, found it 2008-09-16 21:14 doesn't look like there's any requirement to flush 2008-09-16 21:15 seems like O_DIRECT read is meant for access once - not worth caching - data 2008-09-16 21:15 yes 2008-09-16 21:15 still leaves the question about what it does with pages already in cache, or dirty in cache 2008-09-16 21:15 it says minimize 2008-09-16 21:15 shall we leave that as your homework? 2008-09-16 21:16 not ignore cache 2008-09-16 21:16 can't rely on the man page 2008-09-16 21:16 the pages should not be dirty for too long 2008-09-16 21:16 have to read the code 2008-09-16 21:16 :D 2008-09-16 21:17 from NOTES 2008-09-16 21:17 Applications should avoid mixing O_DIRECT and normal I/O to the same 2008-09-16 21:17 file, and especially to overlapping byte regions in the same file. 2008-09-16 21:17 Even when the filesystem correctly handles the coherency issues in this 2008-09-16 21:17 situation, overall I/O throughput is likely to be slower than using 2008-09-16 21:17 either mode alone. Likewise, applications should avoid mixing mmap(2) 2008-09-16 21:17 of files with direct I/O to the same files. 2008-09-16 21:17 one thing you see is that o_direct has to be constantly checking the page cache to be sure nothing is aliased there 2008-09-16 21:17 "The thing that has always disturbed me about O_DIRECT is that 2008-09-16 21:17 the whole interface is just stupid, and was probably designed by 2008-09-16 21:17 a deranged monkey on some serious mind-controlling substances." 2008-09-16 21:17 — Linus 2008-09-16 21:17 maze, the advice is often ignored 2008-09-16 21:18 linux is not absolved from responsibiltiy for keeping the cache consistent 2008-09-16 21:18 right 2008-09-16 21:18 linus doesn't run a database company 2008-09-16 21:18 lol 2008-09-16 21:18 which is why he thinks that 2008-09-16 21:18 the interface is quite simple 2008-09-16 21:19 open with o_direct, make sure your data is aligned 2008-09-16 21:20 hi all 2008-09-16 21:20 maze, how'd you do with reading your superblock 2008-09-16 21:20 hey 2008-09-16 21:20 shapor, right on time ;) 2008-09-16 21:20 I slept well, thank you ;-) 2008-09-16 21:20 good thing we have logs 2008-09-16 21:20 yeah 2008-09-16 21:20 reading now 2008-09-16 21:20 I'm going to be working on it now 2008-09-16 21:20 maze, that little subproject will be highly instructive 2008-09-16 21:21 agreed 2008-09-16 21:21 it already has been 2008-09-16 21:21 especially if you write your own custom endio 2008-09-16 21:21 and figure out how to have your task (which is "mount") wait on a wait queue for the io to complete 2008-09-16 21:21 exactly 2008-09-16 21:22 well, it's the in-kernel portion of mount 2008-09-16 21:22 it's all not very much code, but each line takes about 15 minutes of study 2008-09-16 21:22 or maybe an hour the first time 2008-09-16 21:22 I expect I need something, sleep on something, wake something from endio 2008-09-16 21:22 precisely 2008-09-16 21:22 apparently something called a waitqueue 2008-09-16 21:23 the waiting bits are covered in a nice tutorial manner on lwn 2008-09-16 21:23 so probably something like a dynamic init of a waitqueue 2008-09-16 21:23 ACTION is off to bed. Tomorrow he needs to be early at school. 2008-09-16 21:23 then submit io 2008-09-16 21:23 bio is... an acquired taste 2008-09-16 21:23 then sleep on wq 2008-09-16 21:23 acquired ore 2008-09-16 21:23 acquired lore 2008-09-16 21:23 in endio wake wq 2008-09-16 21:23 more like acquired love 2008-09-16 21:23 exactly 2008-09-16 21:23 probably using the "wake" function 2008-09-16 21:24 that sounds awesome 2008-09-16 21:24 and either wake or wakeall likely 2008-09-16 21:24 here wakeall being more appropriate 2008-09-16 21:24 usually wake 2008-09-16 21:24 no need for a thundering herd 2008-09-16 21:24 of course you know there is only one waiter 2008-09-16 21:25 there better not be more, or something else broke 2008-09-16 21:25 well, but in general, since the op is complete - I should wake all 2008-09-16 21:25 interesting question then is how to dealloc the wq 2008-09-16 21:25 must be some put_wq in the waiters 2008-09-16 21:25 which on last dec to zero does free 2008-09-16 21:25 next move for me is to drop over to whole foods to pick up some munchies 2008-09-16 21:26 I only have a few more days left as a bachelor 2008-09-16 21:26 before the girls get back ;) 2008-09-16 21:26 flips: hah thats where i was instead of class 2008-09-16 21:26 at which time I'm afraid my checking rate will drop somewhat 2008-09-16 21:26 linux/wait.h 2008-09-16 21:26 didn't think it'd be so early 2008-09-16 21:26 checkin 2008-09-16 21:26 shapor, 8 pm tue and thur 2008-09-16 21:28 hmm 2008-09-16 21:28 looks like it's too late for whole food 2008-09-16 21:28 unless I really run 2008-09-16 21:28 don't feel like really running 2008-09-16 21:28 maybe it's 3rd street for dinner tonight 2008-09-16 21:28 so i need to make a dynamic wq, init with init_waitqueue_head() 2008-09-16 21:28 yes, and there are various convenience wrappers 2008-09-16 21:29 best is to write it on the metal the first time 2008-09-16 21:30 #define wake_up_all(x) __wake_up(x, TASK_NORMAL, 0, NULL) 2008-09-16 21:30 well if I don't go shopping there will be no coffee for breakfast 2008-09-16 21:30 seems to be the way to wake 2008-09-16 21:30 so I'm gone... 2008-09-16 21:30 folks 2008-09-16 21:31 hi bh 2008-09-16 21:32 -!- RalucaM(~ral@pool-151-196-118-156.balt.east.verizon.net) has left #tux3 2008-09-16 21:32 -!- cdk(~chinmay@121.246.33.227) has joined #tux3 2008-09-16 21:34 interesting 2008-09-16 21:34 how did I become a contributor on zumastor? 2008-09-16 21:35 aposter 2008-09-16 21:35 ah 2008-09-16 21:35 u do that? 2008-09-16 21:37 flips:are the latest tuxfs binaries working fine for everyone? 2008-09-16 21:38 i am getting segfaults for each file that i copy 2008-09-16 21:38 sync rootdir 2008-09-16 21:38 filemap_blockio: write 2008-09-16 21:38 devmap_blockio: read [8] 2008-09-16 21:38 devmap_blockio: read [9] 2008-09-16 21:38 balloc -> [10] 2008-09-16 21:38 new group at 0 2008-09-16 21:38 insert 0x0 at 0 in group 0 2008-09-16 21:38 limit = 0, free = 4088 2008-09-16 21:38 save_inode: save inode 0xd 2008-09-16 21:39 lookup inode 0xd, 0 + d 2008-09-16 21:39 resize inum 0xd at 0x58 from 18 to 28 2008-09-16 21:39 sync atom table 2008-09-16 21:39 Segmentation fault 2008-09-16 21:41 thats the inode.c right? 2008-09-16 21:41 or is that tux3 fuse? 2008-09-16 21:42 tux3 fuse running in the foreground 2008-09-16 21:42 let me try to reproduce 2008-09-16 21:43 did you try running under gdb? 2008-09-16 21:43 no .. that i did not 2008-09-16 21:43 probably have to attach to it after you start it i haven't tried yet 2008-09-16 21:45 cdk: you're running tux3fs right? 2008-09-16 21:45 not tux3fuse 2008-09-16 21:45 yeah tux3fs 2008-09-16 21:46 ah yes, happens for me too 2008-09-16 21:46 i am sure it worked before... 2008-09-16 21:47 i mean two days ago 2008-09-16 21:48 yeah appears to be on write 2008-09-16 21:48 new bug 2008-09-16 21:49 not sure why its sync'ing atom table at all 2008-09-16 21:49 hrm 2008-09-16 21:50 btw...ls is yet to work for tux3fuse isnt it? 2008-09-16 21:50 yeah i think tux3fuse is very broken 2008-09-16 21:51 but perhaps a better approach 2008-09-16 21:51 using the "low level" api 2008-09-16 21:51 yes. 2008-09-16 21:54 anyways...i need to go...will keep track of the changes. 2008-09-16 21:54 hopefully we resolve this soon. 2008-09-16 21:54 cdk: thanks for the bug report... i'm on it 2008-09-16 21:54 i think it see whats wrong 2008-09-16 22:00 -!- amey(~amey@116.73.35.180) has left #tux3 2008-09-16 22:00 yes 2008-09-16 22:01 kernel locked ;-) 2008-09-16 22:09 heh 2008-09-16 22:09 fun 2008-09-16 22:09 whatd you do 2008-09-16 22:10 cdk: fixed :) 2008-09-16 22:11 oh hes gone 2008-09-16 22:11 cdk, no doubt it's my fault 2008-09-16 22:11 I didn't try it 2008-09-16 22:12 probably have to attach to it after you start it i haven't tried yet <- or just change the makefile 2008-09-16 22:13 segfault in atom stuff... no surprise 2008-09-16 22:13 -!- pranith(ca4bcee2@webchat.mibbit.com) has joined #tux3 2008-09-16 22:23 -!- MaZe(~MaZe@c-24-6-86-168.hsd1.ca.comcast.net) has joined #tux3 2008-09-16 22:24 back from kernel lala land 2008-09-16 22:24 hmm 2008-09-16 22:24 hello all 2008-09-16 22:25 maze, log of tux univ posted? 2008-09-16 22:25 yes 2008-09-16 22:26 http://shapor.com/tux3/irclogs/current.txt 2008-09-16 22:26 okay, looks like I definitely need to put a little effort into making my system more debuggable 2008-09-16 22:27 that was a totally harmless piece of code - one'd think 2008-09-16 22:29 uh 2008-09-16 22:29 ugh 2008-09-16 22:29 stupid thing 2008-09-16 22:29 this one takes an object, that one takes a pointer to an object... 2008-09-16 22:29 and they're all macros, so who'd guess 2008-09-16 22:30 okay, so that actually works 2008-09-16 22:30 waits the appropriate number of jiffies 2008-09-16 22:31 i'm going to split up those logs soon 2008-09-16 22:31 gotta make a cron job 2008-09-16 22:31 that way we can link to TuxU sessions 2008-09-16 22:31 by day? by week? by month? 2008-09-16 22:32 not sure yet 2008-09-16 22:32 i have this script http://zumastor.org/irclogs/ 2008-09-16 22:32 leave current the way it is 2008-09-16 22:32 yeah i like the one big long 2008-09-16 22:32 log 2008-09-16 22:32 easy to grep ;) 2008-09-16 22:32 would be nice to hit record and stop for tux3 U 2008-09-16 22:32 lol 2008-09-16 22:32 I love the most recent conversation 2008-09-16 22:33 #zumastor doesn't get a lot of traffic these days 2008-09-16 22:33 wonder why 2008-09-16 22:33 what's up with zumastor? 2008-09-16 22:33 not much these days 2008-09-16 22:34 no one really works on it anymore 2008-09-16 22:34 its waiting for tux3 goodness to be backported 2008-09-16 22:34 really? 2008-09-16 22:34 to increase performance 2008-09-16 22:34 yup 2008-09-16 22:35 I guess that's kind of sad 2008-09-16 23:55 -!- hirofumi(~hirofumi@210.171.168.39) has joined #tux3