Erez Zadok <ezk <at> cs.sunysb.edu> writes: > > Huh? There's still aboslutely not fix to the underlying problems of > > the whole idea. I think we made it pretty clear that unionfs is not > > the way to go, and that we'll get the union mount patches clear once > > the per-mountpoint r/o and unprivilegued mount patches series are in > > and stable. > > I'll reiterate what I've said before: unionfs is used today by many users, > it works, and is stable. After years of working with unionfs, we've settled > on a set of features that users actually use. This functionality can be in > mainline today. I think it would be of great benefit to many linux users to have Unionfs in mainline. It is a highly valuable and reliable filesystem which allows one to develop interesting live distributions, read only root images and other types of layered systems. Unionfs works well now, and given that it is a stand alone filesystem I think it would really be a waste to exclude it from mainline only to insist that one should wait for union mounts, which may never reach feature parity with Unionfs, especially given that the linux kernel has a long running history of filesystems with overlapping abilities. - Jesse Hathaway > Unioning at the VFS level, will take a long time to reach the same level of > maturity and support the same set of features. Based on my years of > practical experience with it, unioning directories seems like a simple idea, > but in practice it's quite hard no matter the approach taken to implement > it. > > Existing users of unioning aren't likely to switch to Union Mounts unless it > supports the same set of features. How long will it realistically take to > get whiteout support in every lower file system that's used by Unionfs > users? How will Union Mounts support persistent inode numbers at the VFS > level? Those are just a few of the questions. > > I think a better approach would be to start with Unionfs (a standalone file > system that doesn't touch the rest of the kernel). And as Linux gradually > starts supporting more and more features that help unioning/stacking in > general, to change Unionfs to use those features (e.g., native whiteout > support). Eventually there could be basic unioning support at the VFS > level, and concurrently a file-system which offers the extra features (e.g., > persistency). This can be done w/o affecting user-visible APIs. > > Cheers, > Erez. > - > To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in > the body of a message to majordomo <at> vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > - To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
