2008-11-05 03:51 -!- pranith(ca4bcee2@webchat.mibbit.com) has joined #tux3 2008-11-05 06:47 -!- pgquiles(~pgquiles@228.Red-81-35-100.dynamicIP.rima-tde.net) has joined #tux3 2008-11-05 07:02 -!- mingming(~mingming@c-24-22-117-202.hsd1.or.comcast.net) has joined #tux3 2008-11-05 07:59 -!- tim_dimm(~timothyhu@cpe-76-90-98-247.socal.res.rr.com) has joined #tux3 2008-11-05 08:20 -!- stargazr5(~gauravstt@59.95.34.238) has joined #tux3 2008-11-05 08:53 -!- mingming(~mingming@32.97.110.51) has joined #tux3 2008-11-05 09:25 -!- MaZe(~MaZe@216-239-45-4.google.com) has joined #tux3 2008-11-05 10:17 -!- MaZe(~MaZe@216-239-45-4.google.com) has joined #tux3 2008-11-05 11:56 -!- MaZe(~MaZe@216-239-45-4.google.com) has joined #tux3 2008-11-05 14:28 -!- MaZe(~MaZe@216-239-45-4.google.com) has joined #tux3 2008-11-05 14:57 -!- MaZe1(~MaZe@216-239-45-4.google.com) has joined #tux3 2008-11-05 15:52 -!- tim_dimm(~timothyhu@cpe-76-90-98-247.socal.res.rr.com) has joined #tux3 2008-11-05 17:54 -!- MaZe(~MaZe@216-239-45-4.google.com) has joined #tux3 2008-11-05 18:25 maze, ping? 2008-11-05 18:25 pong 2008-11-05 18:26 re yesterday's proposition... 2008-11-05 18:26 that inode numbers can just be allocated sequentially 2008-11-05 18:26 the reasoning against goes like this... 2008-11-05 18:27 1) you want to store some attributes at the location indexed by the inum 2008-11-05 18:27 2) you want to store some file data near the inode attributes 2008-11-05 18:28 3) sequential allocation is only one possible access pattern, others have to be supported 2008-11-05 18:28 file data? as in file contetns? 2008-11-05 18:28 yes 2008-11-05 18:28 needs physical proximity to the inode attributes 2008-11-05 18:29 for tiny files, ie. symlinks... 2008-11-05 18:32 I'm not sure why the above matter? 2008-11-05 18:32 4) on update pattern that needs to be support is "add a new file near some existing files" which sequential inum allocation cannot do without violating (1) or (2) 2008-11-05 18:34 s/on/one/ 2008-11-05 18:38 hmm, maybe, I'm not convinced that it can't be solved by preallocating inodes at the directory level 2008-11-05 18:39 (ie. directories have pools of preallocated unused inode numbers) 2008-11-05 18:39 that's inode number allocation thinly disguised 2008-11-05 18:40 ...true... 2008-11-05 19:12 -!- tim_dimm(~timothyhu@cpe-76-90-98-247.socal.res.rr.com) has joined #tux3 2008-11-05 19:12 hi tim_dimm 2008-11-05 19:13 just ponged u 2008-11-05 19:13 just got it now 2008-11-05 19:26 -!- ajonat(~ajonat@190.48.125.59) has joined #tux3 2008-11-05 19:33 hmm, I need a term other than flush that means "force allocation of disk data to back dirty data cache" 2008-11-05 19:33 because "flush" also means "write it out", usually 2008-11-05 19:35 fallac? 2008-11-05 19:35 woo catchy 2008-11-05 19:35 falloc_dd 2008-11-05 19:35 woosh? 2008-11-05 21:54 folks