there's one major bug in it that I know of, which I reported and fixed in my private tree. (and reported the fix) besides that I've spent many hours running with it, w/o experiencing a problem.
Please try w/ the patch I made against 1.1.3 if the cvs version are giving you trouble. I should create a patch of my fix after I wake up for real in a few hours. -----Original Message----- From: Klaus Knopper <[EMAIL PROTECTED]> Date: Thursday, May 11, 2006 3:31 am Subject: [Unionfs] UNIONFS_MMAP unstable Hi, On Tue, Mar 07, 2006 at 03:24:05PM -0500, Erez Zadok wrote: We have done very little testing on it; it's highly experimental, but looks promising as a starting point. So I preferred to have at least _something_ available for people to try, and hopefully help us enhance and fix it (while we're continuing to stabilize the rest of the code in preparation for a first release). So, consider this a request for testing from those of you who feel comfortable enough with the unionfs code, to try out UNIONFS_MMAP, find what's missing/broken, and give us feedback (or patches :-) Well, after using the current snapshot from 3.5.06 on Knoppix with -DUNIONFS_MMAP, Kernel 2.6.17-rc3-git17, I have to report that this is one of the more unstable versions. I get various kernel oopses because of apparently defective page caches after dpkg -i (too many different dmesg's to report something reliable). Seems t be caused by mmap, but I'll have to retry without -DUNIONFS_MMAP again today. Also, the current snapshot doesn't compile with Kernel 2.6.17-rc3-git17 because of wrong calling of sync_page(). It should probably be block_sync_page(), but that's just a guess. Btw, is anybody doing something about the "mv directory .." bug? With kind regards -Klaus Knopper _______________________________________________ unionfs mailing list [email protected] http://www.fsl.cs.sunysb.edu/mailman/listinfo/unionfs _______________________________________________ unionfs mailing list [email protected] http://www.fsl.cs.sunysb.edu/mailman/listinfo/unionfs
