[arch-dev-public] aufs / unionfs / aufs2
Okay, I received a few mails from Christopher Rogers who played with these filesystems and 2.6.29. According to his statements, he could get aufs2 to compile, but it only actually worked when he omitted the unionfs patch. Maintaining this patch mess has been a PITA, so I say we have a choice here: Choose one and drop the rest. I think aufs should not be considered, but only unionfs or aufs2. I don't use these, but the people who do should give some input on which one to choose.
On Sat, Mar 28, 2009 at 4:24 PM, Thomas Bächler <thomas@archlinux.org> wrote:
Okay, I received a few mails from Christopher Rogers who played with these filesystems and 2.6.29. According to his statements, he could get aufs2 to compile, but it only actually worked when he omitted the unionfs patch. Maintaining this patch mess has been a PITA, so I say we have a choice here: Choose one and drop the rest. I think aufs should not be considered, but only unionfs or aufs2. I don't use these, but the people who do should give some input on which one to choose.
What one is most likely to land in the kernel? I assume one of these has to be on track to actually get in, and we should go with that and be done with this mess. Why is it that everyone seems to use union filesystems, and yet none of them have matured enough to get in the tree? -Dan
Dan McGee schrieb:
What one is most likely to land in the kernel? I assume one of these has to be on track to actually get in, and we should go with that and be done with this mess.
unionfs has been in -mm for ages, and aufs2 has just been submitted for mainline inclusion a few weeks ago.
Why is it that everyone seems to use union filesystems, and yet none of them have matured enough to get in the tree?
When unionfs was first submitted, apart from coding style and implementation issues, it had design problems, like non-consistent inode numbers in some cases (which aufs2 solves, according to the author). Also, it seems that people weren't happy about the general approach: Rather than stacking filesystems, doing copyup and such, it was suggested that a special filesystem should be designed that has its own on-disk-format for storing differences between an underlying filesystem and the actually visible filesystem. unionfs-odf does this, but apparently it is not very mature. For reference, here are the recent LKML discussions (most of the information from above is from what I read here some time ago and remembered): 23. Feb: aufs design and first comments http://permalink.gmane.org/gmane.linux.file-systems/29813 9. Mar: aufs source http://permalink.gmane.org/gmane.linux.file-systems/30026 16. Mar: aufs source, second try http://permalink.gmane.org/gmane.linux.file-systems/30160 This is a lot to read and I have no idea if and when this might be included. However, we should be able to build this as an external module with only a non-intrusive patch to the kernel (it exports some symbols that are otherwise not exported), while I don't know how intrusive unionfs is.
On Sat, Mar 28, 2009 at 4:24 PM, Thomas Bächler <thomas@archlinux.org> wrote:
Okay, I received a few mails from Christopher Rogers who played with these filesystems and 2.6.29. According to his statements, he could get aufs2 to compile, but it only actually worked when he omitted the unionfs patch. Maintaining this patch mess has been a PITA, so I say we have a choice here: Choose one and drop the rest. I think aufs should not be considered, but only unionfs or aufs2. I don't use these, but the people who do should give some input on which one to choose.
The ISOs use unionfs, as does the devtools chroot scripts. But, switching to aufs seems painless. I'm not sure if the aufs2 interface is the same? If it is then we could easily fix up these things to support aufs2. What I'm saying is that we need one of these, but not all. As far as I know aufs is better than unionfs in all aspects, but I have never used aufs2. Has anyone used aufs2? Does unionfs still have that goofy NFS issue? Furthermore - which kernel patch is cleaner? That could be a decider for us too
Aaron Griffin schrieb:
The ISOs use unionfs, as does the devtools chroot scripts. But, switching to aufs seems painless. I'm not sure if the aufs2 interface is the same? If it is then we could easily fix up these things to support aufs2. What I'm saying is that we need one of these, but not all.
AFAIK aufs2 is just aufs rewritten to get rid of design problems, I guess you can use it the same as aufs. I never tried though. (For details, see the first link in my reply to Dan).
As far as I know aufs is better than unionfs in all aspects, but I have never used aufs2. Has anyone used aufs2? Does unionfs still have that goofy NFS issue?
Furthermore - which kernel patch is cleaner? That could be a decider for us too
This patch was for 2.6.28, and it only exports some symbols which are otherwise not exported (according to Christopher, this patch gets even smaller with .29): http://git.c3sl.ufpr.br/gitweb?p=aufs/aufs2-standalone.git;a=blob;f=aufs2-st... Other than that, there is a patch for ecryptfs (I don't know why, probably to make it work with aufs) and a new directory fs/aufs/ About unionfs: No idea.
participants (3)
-
Aaron Griffin
-
Dan McGee
-
Thomas Bächler