In message <[EMAIL PROTECTED]>, Tomas M writes: > > Andreas Hasenack wrote: > > I was just checking www.unionfs.org and saw that it is now considered > > "deprecated"? And that AuFS is the new replacement? Right now as unionfs > > got accepted into the mm tree? > > I'm responsible for that webpage. I'm the bad guy. > I consider unionfs obsolete, not deprecated. > > With all the respect to unionfs developers, I am here to inform the > world about a working alternative. The choice is still up to you. > > > Tomas M > slax.org
Tomas, it would have been nice to inform us Unionfs developers before making that change. The choice is indeed yours and everyone else's. You may not appreciate the amount of effort that goes into getting into -mm and beyond. But since you do own the unionfs.org domain, I think it's your responsibility to be fair, not "the bad guy." Calling our Unionfs "dead" is irresponsible and plainly unprofessional of you. Unionfs is far from obsolete or deprecated. If you will be on this mailing list a little longer, you will see patches we submit, both to -mm and as standalone, which will address the following: - cache coherency and mmap, done the right way (we're presenting it at LSF *today*). - dynamic branch management. This is done, just needs through testing. - an on-disk persistent store, and idea suggested by Ted Ts'o at OLS 2006, which fixes (this is 80% coded) + whiteouts and opaqueness + stacking Unionfs on top of Unionfs + persistent inodes + rename + readdir/seekdir + hard links + resuming previous mounts with a simple handle Remember everyone, our goal is to get Unionfs into the mainline kernel, which means we have to do things *right*, efficient, and comply with the many important things that kernel developers look for. Stay tuned. Sincerely, Erez, on behalf of the Unionfs team. _______________________________________________ unionfs mailing list unionfs@mail.fsl.cs.sunysb.edu http://www.fsl.cs.sunysb.edu/mailman/listinfo/unionfs
