Hello Catalin, Thursday, June 12, 2014, 9:00:54 PM, you wrote: vblade vs aoede fork: vblade itself looks more like a minimalistic 'AoE technology demo' project, and I suspect that including such thinks that I made run counter to project's 'philosophy'. ABout splitting read-ahead code: it requires asynchronous IO so splitting to use in vblade will require writing code that deals with Posix AIO, otherwise it will be Linux-only. Winaoe: Its possible to generate crashdump manually: http://msdn.microsoft.com/en-us/library/windows/hardware/ff545499(v=vs.85).aspx Usually it works (if all CPUs are not locked on too high IRQL). But from you description seems my changes didn't fix this. About name: seems you're right, and I better will rename project instead of bothering its initial author. Let it be AoE Disk.. (will complete all rename-related changes bit later) CS> Hi, CS> I'm sorry to say it was not clear to me that you went ahead with a fork CS> from your previous mail. (but given the time I took to answer it, I CS> should have assumed that) CS> I'm not exactly working in a resource constrained environment and I CS> already have most of the data cached in RAM. As I attempted to say CS> earlier, my main issue with these changes being in a fork is that they CS> stand a much smaller chance of being included in a distribution for CS> something that might need it (say Raspbian, for example. vblade is in CS> the Debian repository) and is also less likely to get contributions and CS> support from people that might care about the changes, without at least CS> a reference from the vblade README file. CS> However, I would like to encourage you to split at least the read-ahead CS> code and make a pull-request. CS> Regarding the mentioned WinAoE deadlock, there are no crashes or stack CS> dumps in the described situation. The issue I was talking about CS> manifests itself when some filters attach to the stack. Windows appears CS> to like to unload filters from the stack when inserting some other types CS> of filters, including some firewall products. This might not be CS> noticeable when using AoE for secondary storage, but when the system CS> drive is affected, Windows removes the AoE filter before attaching the CS> new driver to the stack, then attempts to save the changes to disk CS> before reattaching AoE. It is somewhere between these changes that the CS> system locks until the disk flushes the changes, which is, of course, CS> dependant on the filter being attached to the network card. This causes CS> a deadlock. On Windows XP, the system would die after a few seconds. On CS> Windows Vista and above, including with the NDIS6 network rewrite, it CS> will hang there for quite a bit of time, acting like the disk is CS> faulting. Some caching might help with this, but it wasn't high enough CS> on the priority list for me to test if Windows would then ask for a read CS> from the disk, that would prove caching was largely useless. (our CS> specific usage pattern would actually suffer from constant caching in CS> WinAoE) CS> I haven't yet looks at the linked projects, but I believe you should ask CS> the previous developer of WinAoE, if you still can, if they're ok with CS> you using the same name for the fork. CS> Cheers! -- Best regards, Killer{R} mailto:support@xxxxxxxxxxxx ------------------------------------------------------------------------------ HPCC Systems Open Source Big Data Platform from LexisNexis Risk Solutions Find What Matters Most in Your Big Data with HPCC Systems Open Source. Fast. Scalable. Simple. Ideal for Dirty Data. Leverages Graph Analysis for Fast Processing & Easy Data Exploration http://p.sf.net/sfu/hpccsystems _______________________________________________ Aoetools-discuss mailing list Aoetools-discuss@xxxxxxxxxxxxxxxxxxxxx https://lists.sourceforge.net/lists/listinfo/aoetools-discuss
