2008-10-02 03:07 -!- kbingham(~kbingham@193.132.141.186) has joined #tux3 2008-10-02 04:19 -!- bh(~billh@ip68-107-26-122.sd.sd.cox.net) has joined #tux3 2008-10-02 07:08 -!- orgthingy(~orgthingy@62.150.55.188) has joined #tux3 2008-10-02 07:08 hello! 2008-10-02 08:55 -!- RazvanM(~RazvanM@dazzler.isi.jhu.edu) has joined #tux3 2008-10-02 09:35 -!- Kirantpatil(~kiran@122.166.93.80) has joined #tux3 2008-10-02 09:35 -!- Kirantpatil(~kiran@122.166.93.80) has left #tux3 2008-10-02 11:23 -!- tim_dimm(~timothyhu@cpe-76-90-98-247.socal.res.rr.com) has joined #tux3 2008-10-02 14:05 -!- kd(~kd@121.246.35.242) has joined #tux3 2008-10-02 14:09 -!- orgthingy_(~orgthingy@62.150.55.188) has joined #tux3 2008-10-02 15:47 well, extent read is a little harder than extent write in one respect 2008-10-02 15:47 for the write, we know to form up extents by searching for adjoining dirty regions 2008-10-02 15:47 dirty buffers I mean 2008-10-02 15:48 for read we don't 2008-10-02 15:48 I suppose I could implement readahead here 2008-10-02 15:48 and just go read a whole extent every time somebody asks for a buffer 2008-10-02 15:48 for now 2008-10-02 15:48 the problem is, the buffer at a time high level interface is lame 2008-10-02 15:49 but accurately models what we will get in kernel 2008-10-02 15:49 we need an extent at a time interface that comes from the sys_write level 2008-10-02 15:50 which there is a hook for 2008-10-02 15:50 but it means bypassing the whole generic_read/write mess 2008-10-02 15:50 which might be ok in that it means bypassing a big mess 2008-10-02 15:50 but it also means we will have to maintain essentially a forked version of the read/write library 2008-10-02 15:51 volunteers? 2008-10-02 16:13 -!- ChanServ changed mode/#tux3 -> +o flips 2008-10-02 16:15 -!- flips changed topic to "http://tux3.org ~ Tux3 U, right here Tuesdays and Thursdays at 8 pm Pacific Time ~ Next session: friends of grab_cache_page ~ Postponed till 9 pm tonight, thursday Oct 2" 2008-10-02 16:15 -!- flips changed mode/#tux3 -> -o flips 2008-10-02 16:15 nice 2008-10-02 16:15 flips : you should ask in other channels 2008-10-02 16:15 here all people try to help 2008-10-02 16:16 flips : ask in Linux and opensource channels 2008-10-02 16:16 or, in EFnet 2008-10-02 16:16 ? 2008-10-02 16:16 some may-be interested 2008-10-02 16:16 about what? 2008-10-02 16:16 in helping you 2008-10-02 16:16 oh 2008-10-02 16:16 feel free to ask 2008-10-02 16:16 well, i really dont know much about it? 2008-10-02 16:16 so, i dont really know if i can ask 2008-10-02 16:16 that's ok 2008-10-02 16:16 :P 2008-10-02 16:17 ACTION invites flips to #ubuntu-offtopic @ irc.freenode.net 2008-10-02 16:17 just tell people a filesystem project needs devs, is willing to help them learn 2008-10-02 16:17 sure 2008-10-02 16:18 :) 2008-10-02 16:20

doesn't sound too professional. :| 2008-10-02 16:20 * snuxoll knows nothing about filesystem design flips 2008-10-02 16:20 see? looks matter :P 2008-10-02 16:20 but, still, ask 2008-10-02 16:20 and explain 2008-10-02 16:20 there are lots of people there 2008-10-02 16:24 sure, but C coders? 2008-10-02 16:24 flips : common 2008-10-02 16:24 its linux channel 2008-10-02 16:24 its full of C coders :P 2008-10-02 16:26 you'd be surprised 2008-10-02 16:26 these days linux coding seems to be more about php than anything 2008-10-02 16:27 flips : php? 2008-10-02 16:27 nay 2008-10-02 16:27 Python and C 2008-10-02 16:27 C++ a bit 2008-10-02 16:27 << python 2008-10-02 16:28 orgthingy, we could use more people playing with the fuse stuff 2008-10-02 16:28 and just trying it and complaining about broken things 2008-10-02 16:28 that's one way to get shapor to code ;) 2008-10-02 16:28 flips : FreeNode is like a UNIX and Linux network 2008-10-02 16:28 lots of programmers there 2008-10-02 16:28 he's awesome when he does 2008-10-02 16:28 you *should* find someone there 2008-10-02 16:28 heh :) 2008-10-02 16:29 flips : and sourceforge would be good idea, so is stumble-upon and digg 2008-10-02 16:30 flips : if it stays small, it'd be "just another free software project" but if you "market" it (not business term) it'd be "just another great opensource project" 2008-10-02 16:30 ok, there's my troll 2008-10-02 16:30 anything else has to come from the grassroots 2008-10-02 16:30 that means you, orgthingy 2008-10-02 16:31 "troll" ? 2008-10-02 16:31 ACTION didnt understand what flips meant 2008-10-02 16:32 wikepedia that 2008-10-02 16:33 you mean troll as is in "annoying useless dude in IRC" ? 2008-10-02 16:33 orgthingy, my time is better spent making code happen, it's up to people who want to help to go spread the word 2008-10-02 16:33 flips : well, i think time is worth looking for people to *code* with you 2008-10-02 16:33 troll as in "saying something controversial in order to get a response" 2008-10-02 16:33 get what i mean? 2008-10-02 16:34 oh, common :( 2008-10-02 16:34 orgthingy, my time is also better spent encouraging people to go out and find coders than going out and hunting myself 2008-10-02 16:34 ok 2008-10-02 16:34 ACTION hides 2008-10-02 16:35 time being at a premium here 2008-10-02 16:35 sorry :| 2008-10-02 16:35 got to get extent reading working today according to me 2008-10-02 16:35 see the resonding lack of response on ubuntu channel 2008-10-02 16:35 prevailing attitude seems to be "work is somebody else's problem, we're here to hang and feel leet" 2008-10-02 16:36 maybe that's not accurate 2008-10-02 16:36 flips : maybe because it's offtopic channel 2008-10-02 16:36 and maybe because ubuntu users dont program 2008-10-02 16:36 I think the latter is the reason 2008-10-02 16:36 one of the reasons 2008-10-02 16:37 willingness to contribute could certainly be better 2008-10-02 16:37 being willing to always lose the early adopter race to gentoo is not a healthy attitude 2008-10-02 16:37 ok, im asking while you're coding 2008-10-02 16:37 :D 2008-10-02 16:38 seems fair 2008-10-02 16:38 best strategy is just for somebody like you to say there, "there's cool stuff going down on oftc #tux3, why not drop by for a visit" 2008-10-02 16:39 flips : well, thats called trolling in freenode :P 2008-10-02 16:40 or, spamming 2008-10-02 16:40 Id rather ask if someone is interested 2008-10-02 16:40 if they are, ill tell them to come by 2008-10-02 16:40 drop* 2008-10-02 16:40 orgthing, not in #offtopic 2008-10-02 16:40 ok 2008-10-02 16:40 im asking in many channels like #C 2008-10-02 16:40 if it worries you, then give a url instead of a channel 2008-10-02 16:40 #c would be good 2008-10-02 16:41 any c coder can become a kernel coder, or if they don't like kernel, fuse is entirely userspace 2008-10-02 16:41 flips : sorry, but i said "we" but i think suing "we" is better than "he" :P 2008-10-02 16:41 we is correct 2008-10-02 16:42 "we" as in "everybody who thinks fat baby penquins are cute" 2008-10-02 16:42 haha 2008-10-02 16:44 flips : i think all programmers are asleep now 2008-10-02 16:44 usually, all of them go like "i want to join!" 2008-10-02 16:44 meh, maybe they're asleep :P 2008-10-02 16:44 programmers are usually asleep 2008-10-02 16:44 just as shapor 2008-10-02 16:45 just ask shapor 2008-10-02 16:45 some are drunk :P (yes really xD) 2008-10-02 16:45 or drunk, right, when they're awake 2008-10-02 16:45 that's why tux3 project has a requirement for beer to be sent 2008-10-02 16:46 to keep our programmers "in the zone" 2008-10-02 16:47 hmm, some say they're already programming in other projects :P 2008-10-02 16:47 haha 2008-10-02 16:47 haha 2008-10-02 16:48 don't take that for an answer ;) 2008-10-02 16:48 flips : ill ask Eloxoph people (i was staff there once) 2008-10-02 16:48 got to have a better excuse than that for being lame 2008-10-02 16:48 its full of C programmers 2008-10-02 16:48 but they're already working on 2 projects 2008-10-02 16:48 sounds good 2008-10-02 16:48 but ill ask them anyway :P 2008-10-02 16:48 2 is not enough 2008-10-02 16:48 should be 3 2008-10-02 16:54 -!- FelipeS(~Felipe@r77h15.res.gatech.edu) has joined #tux3 2008-10-02 16:55 I'll be hanging on #freenode if any ubuntus want to chat, flipz, not on any channel 2008-10-02 16:55 heh 2008-10-02 16:55 FelipeS : hello 2008-10-02 16:55 orgthingy, hey 2008-10-02 16:55 so, finally got interested? 2008-10-02 16:56 friend of yours orgthingy? 2008-10-02 16:56 flips : from ##not-physics over there 2008-10-02 16:56 any dev with physics background tends to be interesting to me 2008-10-02 16:56 likewise music and math 2008-10-02 16:57 seem to be generally more aware design wise 2008-10-02 16:57 I'm just a young student. You got me there with the music background. I'm not into music at all. 2008-10-02 16:57 ok, let's see if the read extent generator works 2008-10-02 17:02 felipes, physics? 2008-10-02 17:02 or does #not-physics really mean not physics? 2008-10-02 17:02 flips : no, not-physics is offtopic channel of ##physics that i founded 2008-10-02 17:03 right, so it means "physics student" essentially? 2008-10-02 17:03 folks 2008-10-02 17:03 :P 2008-10-02 17:03 ok, physics prof then 2008-10-02 17:04 ACTION has to find his hotel receipts and stuff for reembursement 2008-10-02 17:04 mad scientist? 2008-10-02 17:04 flips : uuuumm? 2008-10-02 17:05 what is #physics about? 2008-10-02 17:05 flips : PHYSICS :P ? 2008-10-02 17:05 flips : how about going on topic with felipes? 2008-10-02 17:06 felipes, got c skillz? 2008-10-02 17:08 eh 2008-10-02 17:08 Honestly I'm in no position for being a dev or working on serious stuff 2008-10-02 17:08 at least I don't think so 2008-10-02 17:09 I just came here to maybe see some conversations on real work being done. 2008-10-02 17:09 sure, good place for that 2008-10-02 17:09 flips : he knows C++ most 2008-10-02 17:09 are you like Linus T. ? not allowing c++ code at all :P 2008-10-02 17:09 c++ has a certain influence over what we do 2008-10-02 17:10 I have nothing against c++, I would be ok with allow some files in kernel to be compiled that way, with appropriate care 2008-10-02 17:10 I'm a first year computer eng major at tech, programming is a hobby that got ahold of me about 4 years ago. I've never done anything impressing with it however. just learning here and there. 2008-10-02 17:10 but linus will not allow it so that ends that 2008-10-02 17:10 and it's all been with c++ 2008-10-02 17:11 computer eng is a good place to get a perspective on software efficiency 2008-10-02 17:11 c++ includes c, most of it 2008-10-02 17:11 yeah I know 2008-10-02 17:11 c++ lacks designated initializers, which we use extensivley, without them I'd be unwilling to do a kernel project in c++ even if it was ok with linus 2008-10-02 17:11 is it not 100% backwards compatible? 2008-10-02 17:11 'backwards' :P 2008-10-02 17:11 not 100% 2008-10-02 17:11 stupidly so 2008-10-02 17:15 "sure, good place for that"; was that sarcasm? flips 2008-10-02 17:16 not at all 2008-10-02 17:16 sarcasm always comes with a :p 2008-10-02 17:16 some of the best devs in the known universe hang here 2008-10-02 17:16 just have to catch them talking ;) 2008-10-02 17:18 oh well that's great. I'll be sure to add it to my favs then. 2008-10-02 17:18 filemap_extent_read: logical block 0x5 of inode 0x0 2008-10-02 17:18 ---- extent 0x5/1 ---- 2008-10-02 17:18 prior extents: 2008-10-02 17:18 ---- rewind to 0x0 => 0/1 ---- 2008-10-02 17:18 filemap_extent_read: index 5, limit 6 2008-10-02 17:19 filemap_extent_read: offset = 0, gap = 0 2008-10-02 17:19 filemap_extent_read: fill gap at 5/1 2008-10-02 17:19 balloc extent -> [2/1] 2008-10-02 17:19 segs (offset = 0): 5 => 2/1; (1) 2008-10-02 17:19 well things are starting to happen with extent read 2008-10-02 17:20 course it should not be allocating blocks on read 2008-10-02 17:20 that's because it started as a cut n paste of extent write 2008-10-02 17:20 needs to fill those buffers with zero instead 2008-10-02 17:20 hmm 2008-10-02 17:21 no, just the one buffer 2008-10-02 17:21 ...maybe 2008-10-02 17:21 I doubt "fill ahead" is a win 2008-10-02 17:29 getting closer... 2008-10-02 17:29 filemap_extent_read: logical block 0x5 of inode 0x0 2008-10-02 17:29 ---- extent 0x5/1 ---- 2008-10-02 17:29 prior extents: 2008-10-02 17:29 ---- rewind to 0x0 => 0/1 ---- 2008-10-02 17:29 filemap_extent_read: index 5, limit 6 2008-10-02 17:29 filemap_extent_read: offset = 0, next = 6, gap = 1 2008-10-02 17:29 filemap_extent_read: fill gap at 5/1 2008-10-02 17:29 balloc extent -> [2/1] 2008-10-02 17:29 segs (offset = 0): 5 => 2/1; (1) 2008-10-02 17:29 filemap_extent_read: extent 0x5/1 => 2 2008-10-02 17:29 filemap_extent_read: read block 0x5 => 2 2008-10-02 17:29 now need to get rid of that balloc/read and replace with fill for unmapped buffer 2008-10-02 18:08 seg[segs++] = *(struct extent *)(u64[]){ -1LL }; <- some nasty c 2008-10-02 18:08 thought I'd show that before throwing it away 2008-10-02 18:10 now does the right thing for unmapped buffers: 2008-10-02 18:10 filemap_extent_read: logical block 0x5 of inode 0x0 2008-10-02 18:10 ---- extent 0x5/1 ---- 2008-10-02 18:10 prior extents: 2008-10-02 18:10 ---- rewind to 0x0 => 0/1 ---- 2008-10-02 18:10 filemap_extent_read: index 5, limit 6 2008-10-02 18:10 filemap_extent_read: offset = 0, next = 6, gap = 1 2008-10-02 18:10 filemap_extent_read: fill gap at 5/1 2008-10-02 18:10 segs (offset = 0): 5 => ffffffffffff/1; (1) 2008-10-02 18:10 filemap_extent_read: extent 0x5/1 => ffffffffffff 2008-10-02 18:10 filemap_extent_read: read block 0x5 => ffffffffffff 2008-10-02 18:10 filemap_extent_read: zero fill buffer 2008-10-02 18:10 which brings us to sk8 oclock 2008-10-02 19:53 -!- RazvanM(~RazvanM@pool-151-196-118-156.balt.east.verizon.net) has joined #tux3 2008-10-02 19:55 oh... no class today? 2008-10-02 20:01 -!- RalucaM(~ral@pool-151-196-118-156.balt.east.verizon.net) has joined #tux3 2008-10-02 20:02 aaa... 9pm tonight :P 2008-10-02 20:17 really? 9? 2008-10-02 20:20 I have to be up in about 6h... :( 2008-10-02 20:28 I'm falling asleep already... 2008-10-02 20:28 -!- FelipeS(~Felipe@r77h15.res.gatech.edu) has joined #tux3 2008-10-02 20:28 me too 2008-10-02 20:28 http://lxr.linux.no/linux+v2.6.26.5/fs/inode.c#L124 2008-10-02 20:29 about the first Q from the homework... 2008-10-02 20:29 what was the second one? 2008-10-02 20:31 aaa... the locks when a file is closed 2008-10-02 20:34 hmm 2008-10-02 20:36 I've already answered both. 2008-10-02 20:36 http://lxr.linux.no/linux+v2.6.26.5/fs/open.c#L1175 files->file_lock cannot be the lock we were talking about... 2008-10-02 20:36 let me check my logs 2008-10-02 20:37 ok, so let's pick it up again next thursday 2008-10-02 20:37 ok, first home work was why both ptr and struct address_space (*i_mapping and i_data) in struct inode 2008-10-02 20:37 http://lxr.linux.no/linux+v2.6.26.5/fs/locks.c#L1567 so the locks are tided to filp 2008-10-02 20:37 I will be offline for a few days 2008-10-02 20:37 ah 2008-10-02 20:37 it goes on with out me ;) 2008-10-02 20:37 (the ideal situation) 2008-10-02 20:38 :-) 2008-10-02 20:38 and the above L124 is not quite the answer 2008-10-02 20:38 ralucam, you following ok? 2008-10-02 20:38 MaZe: true, it's the point where are made the same... 2008-10-02 20:38 that's were it gets set to the default value, but why do you need a pointer, couldn't u always use &i_data 2008-10-02 20:38 the i_data doesn't seem to be used much 2008-10-02 20:39 inode->mapping is defined to be 2008-10-02 20:39 always valid 2008-10-02 20:39 re 1175 - not sure what you mean 2008-10-02 20:39 sorry... I was wrong about L124 2008-10-02 20:40 the locks in L1175 and L1567 are not quite the ones we were talking about re fget_light/fput_light 2008-10-02 20:40 so the thing from L124 is put in the structure here: http://lxr.linux.no/linux+v2.6.26.5/fs/inode.c#L184 2008-10-02 20:40 MaZe: aaaa... 2008-10-02 20:40 right 2008-10-02 20:40 but that's the default path 2008-10-02 20:41 -!- RalucaM(~ral@pool-151-196-118-156.balt.east.verizon.net) has joined #tux3 2008-10-02 20:41 now I'm searching for the places where i_mapping is changed :P 2008-10-02 20:41 the one which could have sed / "->i_mapping->" "->i_data." / 2008-10-02 20:41 killing lxr in the process ;-) 2008-10-02 20:42 maze, not quite 2008-10-02 20:42 hmm? 2008-10-02 20:42 i_mapping is a pointer, i_data is an object 2008-10-02 20:42 hence -> to . 2008-10-02 20:42 I'm searching for i_mapping only ;-) 2008-10-02 20:42 right 2008-10-02 20:43 I don't expect the name to be used for anything else 2008-10-02 20:43 sorry, my eyes got crossed with the sed ;) 2008-10-02 20:43 ok, searching logs for the second homework question 2008-10-02 20:43 there was a bonus about why fget_light is demented 2008-10-02 20:45 a: breaks refcounting purely to reduce cacheline pinging 2008-10-02 20:45 ah, ok, so that wasn't the bonus, that was just the second homework 2008-10-02 20:45 accurately characterized by akpm as "foul" 2008-10-02 20:45 http://lxr.linux.no/linux+v2.6.26.5/fs/block_dev.c#L290 2008-10-02 20:45 looks closer 2008-10-02 20:46 but no cigar 2008-10-02 20:46 that's the default value as well 2008-10-02 20:46 I still am not sure why we need i_mapping -> -i_data 2008-10-02 20:46 i_mapping = &i_data 2008-10-02 20:46 and http://lxr.linux.no/linux+v2.6.26.5/fs/block_dev.c#L425 2008-10-02 20:46 http://lxr.linux.no/linux+v2.6.26.5/fs/block_dev.c#L450 2008-10-02 20:46 to be more precise 2008-10-02 20:47 I suspect it's bogus, but a pretty extensive survey of usage would be required to say one way or the other 2008-10-02 20:47 that is the _main_ use case in the kernel 2008-10-02 20:47 (there are two others) 2008-10-02 20:47 right, coda and ? 2008-10-02 20:47 raw char devs 2008-10-02 20:47 char devs? 2008-10-02 20:48 why only char devs? 2008-10-02 20:48 the primary use case seems to be block devices, the secondary is raw char devices (ie. for direct io to block devs, ancient pre-O_DIRECT interface), and third/last is the coda fs 2008-10-02 20:48 well the blockdev usage smells really bogus 2008-10-02 20:48 -!- ajonat(~ajonat@190.48.123.108) has joined #tux3 2008-10-02 20:48 inode->i_mapping = &inode->i_data; 2008-10-02 20:48 from coda ;-) 2008-10-02 20:48 wrong line 2008-10-02 20:49 since that's restoring the default 2008-10-02 20:49 I pick it because of that ;-) 2008-10-02 20:49 the rest are in file.c 2008-10-02 20:50 jeez, that blockdev code is twisted 2008-10-02 20:50 I think, product of fuzzy thinking and not necessity 2008-10-02 20:50 but more analysis is needed to be sure 2008-10-02 20:51 there should be some system to mark as 'looks wrong to me' some stuff in the kernel :P 2008-10-02 20:51 heh 2008-10-02 20:51 we carve our comments in the internet, right hew 2008-10-02 20:51 right here 2008-10-02 20:51 ./fs/coda/file.c-106- host_inode = host_file->f_path.dentry->d_inode; 2008-10-02 20:51 ./fs/coda/file.c-107- coda_file->f_mapping = host_file->f_mapping; 2008-10-02 20:51 ./fs/coda/file.c:108: if (coda_inode->i_mapping == &coda_inode->i_data) 2008-10-02 20:51 ./fs/coda/file.c:109: coda_inode->i_mapping = host_inode->i_mapping; 2008-10-02 20:51 ./fs/coda/file.c-110- 2008-10-02 20:51 ./fs/coda/file.c-111- /* only allow additional mmaps as long as userspace isn't changing 2008-10-02 20:52 where they will be unearthed by archaeologists millenia later 2008-10-02 20:52 that's the relevant part of coda 2008-10-02 20:52 ./drivers/char/raw.c-76- filp->f_mapping = bdev->bd_inode->i_mapping; 2008-10-02 20:52 ./drivers/char/raw.c-77- if (++raw_devices[minor].inuse == 1) 2008-10-02 20:52 ./drivers/char/raw.c:78: filp->f_path.dentry->d_inode->i_mapping = 2008-10-02 20:52 ./drivers/char/raw.c-79- bdev->bd_inode->i_mapping; 2008-10-02 20:52 ./drivers/char/raw.c-80- filp->private_data = bdev; 2008-10-02 20:52 and that's for raw char dev 2008-10-02 20:53 bdev again 2008-10-02 20:53 while I can see/understand the need for the raw char dev and coda use cases 2008-10-02 20:53 I don't yet get what the normal bdev case is for 2008-10-02 20:53 actually... they looks similar 2008-10-02 20:53 coda and raw 2008-10-02 20:53 not surprising 2008-10-02 20:54 coda is a networked file system with local caching and offline operation 2008-10-02 20:54 the raw.c stuff looks bogus too 2008-10-02 20:54 at least party 2008-10-02 20:54 why dow d_inode need to have a mapping? 2008-10-02 20:54 it needs a way to tell the kernel that the page cache for a file in codafs is actually the page cache for another file in a local filesystem (ie. in the cache fs store) 2008-10-02 20:54 sorrry 2008-10-02 20:54 while the raw char dev case needs to remap the raw char dev to the block dev 2008-10-02 20:55 bd_acquire is only called in 3 places... 2008-10-02 20:55 lying underneath it 2008-10-02 20:55 whey does filp need a mapping, I meant to say 2008-10-02 20:55 maze, but that raw char dev case sounds like it could be done some other way 2008-10-02 20:56 hmm... how does cache-ing for char devices works? :P 2008-10-02 20:56 a maybe 2008-10-02 20:56 it's if we open the same block dev from different inodes? 2008-10-02 20:56 from different entries and/or filesystems? 2008-10-02 20:56 something wierd 2008-10-02 20:56 that offends my sense of form and balance 2008-10-02 20:56 since they're all actually the same block device, but they're not the same inode 2008-10-02 20:56 that makes sense 2008-10-02 20:56 want to have them backed by the same page cache 2008-10-02 20:57 make sense! :D 2008-10-02 20:57 how about coda? 2008-10-02 20:57 we don't open block devices "from inodes" 2008-10-02 20:57 we open them from names 2008-10-02 20:57 sure we do ;-) 2008-10-02 20:57 we're talking about i_node->i_mapping remember ;-) 2008-10-02 20:57 right name -> dentry -> inode -> bla bla -> mapping 2008-10-02 20:57 $ stat hda1 2008-10-02 20:57 File: `hda1' 2008-10-02 20:57 Size: 0 Blocks: 0 IO Block: 4096 block special file 2008-10-02 20:57 Device: dh/13d Inode: 2343 Links: 1 Device type: 3,1 2008-10-02 20:57 Access: (0660/brw-rw----) Uid: ( 0/ root) Gid: ( 6/ disk) 2008-10-02 20:57 Access: 2008-10-01 15:41:08.151619201 -0400 2008-10-02 20:57 Modify: 2008-10-01 15:40:54.344130563 -0400 2008-10-02 20:58 Change: 2008-10-01 15:40:54.344130563 -0400 2008-10-02 20:59 stat hdaX 2008-10-02 20:59 File: `hdaX' 2008-10-02 20:59 Size: 0 Blocks: 0 IO Block: 4096 block special file 2008-10-02 20:59 Device: dh/13d Inode: 911348 Links: 1 Device type: 3,1 2008-10-02 20:59 Access: (0644/brw-r--r--) Uid: ( 0/ root) Gid: ( 0/ root) 2008-10-02 20:59 MaZe is right 2008-10-02 20:59 # ls -al sda 2008-10-02 20:59 brw-rw---- 1 root disk 8, 0 2008-09-29 17:52 sda# mknod sda__ b 8 0 2008-10-02 20:59 # ls -al sda__ 2008-10-02 20:59 brw-r--r-- 1 root root 8, 0 2008-10-02 20:58 sda__ 2008-10-02 20:59 # stat sda 2008-10-02 20:59 Device: eh/14d Inode: 339 Links: 1 Device type: 8,0 2008-10-02 20:59 # stat sda__ 2008-10-02 20:59 Device: eh/14d Inode: 844038 Links: 1 Device type: 8,0 2008-10-02 20:59 :D 2008-10-02 20:59 I was first ;-) 2008-10-02 20:59 yup 2008-10-02 21:00 and it'll have an even different inode on a different partition/filesystem 2008-10-02 21:00 hence, different sb,inode pairs referring to the same block dev, but having to have the same page cache 2008-10-02 21:00 that for sure 2008-10-02 21:00 I don't understand the page cache for char dev though 2008-10-02 21:01 the raw char dev is an abomination 2008-10-02 21:01 it behave like a block dev 2008-10-02 21:01 nowadays the correct way is to open the normal (base) block dev with option O_DIRECT 2008-10-02 21:01 maze, but why does kernel ever have to use the inode from the mknod file directly? 2008-10-02 21:01 oh... 2008-10-02 21:01 why not dereference to the real inode first? 2008-10-02 21:01 flips: dentry? 2008-10-02 21:02 could be a dentry reason, still sounds bogus 2008-10-02 21:02 real inode? 2008-10-02 21:02 even if it's in the dentry 2008-10-02 21:02 it used to be you would map the base dev to a raw dev and then get direct io on the raw dev, which for reasons which escape me wasn't a block dev, but a char dev instead 2008-10-02 21:02 dreference after getting hold of the dentry 2008-10-02 21:02 because bdevs don't have inodes? 2008-10-02 21:02