On Tue, 24 Feb 2009, hooanon05@xxxxxxxxxx wrote: > I have to admit aufs is big, but actually, as I wrote in the documents, > aufs2 has already dropped several features. And I believe it is the core > feature set. If aufs2 drops some more features, then both of users and > reviewers will say it doesn't work in this case, in that case. I don't > think you would like to review such unusable code in real world. It's always easier to review something with less features, even if that feature set is too little for real world use. Maybe it has all got to get into mainline to be really useful, but still, splitting it up by functionality (not just files) helps reviewers a lot. Let's see this feature list: > 1. Features > ---------------------------------------- > - unite several directories into a single virtual filesystem. The member > directory is called as a branch. Sounds like a core functionality :) > - you can specify the permission flags to the branch, which are 'readonly', > 'readwrite' and 'whiteout-able.' The simplest version is with all branches read-only. That gets rid of a _huge_ amount of complexity, yet it's still useful in some situations. It also deals with a lot of the basic infrastucture needed for stacking. > - by upper writable branch, internal copyup and whiteout, files/dirs on > readonly branch are modifiable logically. Right. The second most simple version is all branches read-only except the top one. And that's when one starts thinking about whether unioning is really the right solution. Instead this could be implemented with a special filesystem format that only contains deltas to the data, metatata and directory tree. It would be much more space efficient, could easily handle renames, hard links etc, without all the hacks that unionfs/aufs does. Has this been discussed somewhere? Thanks, Miklos -- 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
