Thread: Why Unionfs is better than Aufs
Status: Beta
Brought to you by:
sfjro
From: Barry K. <bk...@gm...> - 2010-03-21 03:01:12
|
Over the years with Puppy Linux I have gone backwards and forwards between using Aufs and Unionfs. They each have advantages and disadvantages, but Unionfs has two major advantages that make me prefer it. The problem is that we have had ongoing stability issues with Unionfs and the developers are extremely slow to fix them. That was the reason for my last move from Unionfs to Aufs. However, for the latest experiments with the 2.6.33.x kernel we are once again playing with Unionfs. I need to explain why I want to use Unionfs, if it is stable, rather than Aufs. We have been discussing these reasons on my blog: http://bkhome.org/blog/?viewDetailed=01440 Now, it may be that these two things can be done in Aufs, but I don't know how: First reason Puppy Linux has the layers (branches) with basically the r/w "save file" or "save partition" on top, the main Puppy f.s. below as a r/o Squashfs file (what we call a SFS file), and optionally more SFS files as layers below that -- for example a complete c/c++ development environment, or OpenOffice. If we have a "save partition" on top, we also have the SFS files in that partition. Aufs will refuse to mount those SFS files as they are already inside a branch. Consequently, we are forced to copy the main SFS file into RAM and mount it from there. However, Unionfs is quite happy with mounting SFS files that are actually present in another branch. Second reason Both Unionfs and Aufs have mechanisms for detecting direct writes to branches, however they are not perfect. Unless, in the case of Aufs you go for the mode using inotify, but that has performance penalty. When running Puppy from Flash memory, we have the top branch as a tmpfs in RAM, and the "save file" or "save partition" below that. This is done to minimise writes to the Flash memory. When a package is installed, we would like to be able to install it directly to the "save" layer, the actual Flash memory and have all the files visible on top. Our package installer recognises if Unionfs is being used and is able to write direct to the "save" layer, and then is able to do a perfect operation to make all files visible on top by doing this: mount -t unionfs -o remount,incgen unionfs / ...this flushes the caches and does a complete re-evaluation of the layers. As far as I know, Aufs does not have the equivalent. Regards, Barry Kauler |
From: <sf...@us...> - 2010-03-22 01:44:29
|
Hello Barry, Barry Kauler: > Now, it may be that these two things can be done in Aufs, but I don't know how: > > First reason ::: > If we have a "save partition" on top, we also have the SFS files in > that partition. Aufs will refuse to mount those SFS files as they are > already inside a branch. Consequently, we are forced to copy the main > SFS file into RAM and mount it from there. However, Unionfs is quite > happy with mounting SFS files that are actually present in another > branch. Because I had experienced a recursive lock (deadlock) by a loopback branch (fs image in a branch fs), aufs rejects it. But it was a long time ago. It was early stage in aufs1 era. I will check it again with recent kernel. > Second reason > Both Unionfs and Aufs have mechanisms for detecting direct writes to > branches, however they are not perfect. Unless, in the case of Aufs > you go for the mode using inotify, but that has performance penalty. udba=inotify has some overhead as you wrote. Is it so big penalty for you? CPU time or memory? If you show me some numbers about the penalty, I may re-consider the approach. > When running Puppy from Flash memory, we have the top branch as a > tmpfs in RAM, and the "save file" or "save partition" below that. This > is done to minimise writes to the Flash memory. When a package is > installed, we would like to be able to install it directly to the > "save" layer, the actual Flash memory and have all the files visible > on top. To install a package, modifying a branch permission temporarly may be useful. For instance, when you have three branches, - /u = /tmpfs(rw) + /flash=ro(ro) + /squashfs(ro) - modify /u = /tmpfs(ro) + /flash=ro(rw) + /squashfs(ro) - install a package to /u _if_ the same named file doesn't exist the first /tmpfs, aufs will pass the files to the second /flash. But it may not be a generic solution. I didn't test it actually either. You may prefer bypassing aufs. > Our package installer recognises if Unionfs is being used and is able > to write direct to the "save" layer, and then is able to do a perfect > operation to make all files visible on top by doing this: > > mount -t unionfs -o remount,incgen unionfs / > > ...this flushes the caches and does a complete re-evaluation of the > layers. As far as I know, Aufs does not have the equivalent. Do you mean that the newly added files in the second layer is invisile in aufs? Usually, "mount -o remount /your/aufs" is enough for such case. Of course, if the same named file already exist in the upper layer, you cannot see the new files in the lower. Or RDU (readdir in userspace) in libau.so and rdcache=N mount option may be helpful. The 'incgen' option is easy to implement, but I don't think it meaningful. Because - simple remount is enough for most cases, but files in use will not be refreshed. - with udba=inotify, you can skip the manual remount and the files in use will be refreshed if necessary. when an inotify event is fired and aufs receives it, aufs executes something like 'decgen' for that file internally. So that the next access to the file causes the refresh. Setting udba=inotify temporally is also recommended. # mount -o remount,udba=inotify / # install something to branch, bypassing aufs # mount -o remount,udba=reval / Reading the url you wrote, - Did you experience the corrupted filesystem after unmounting aufs? If so, let me know the detail please, particulary how you unmount it (or remount it read-only). > Posted on 18 Mar 2010, 15:33 by BarryK > Writing to branches ::: > I did actually try and explain this on the Aufs mail list once, but perhaps they never understood > what I was asking for, or didn't appreciate the value of it. I may not receive the mail. When did you post it? Did I reply it? Is it archived in the sourceforge ML? If you still have a copy, will you send it again? Thanx J. R. Okajima |
From: <sf...@us...> - 2010-03-23 09:03:28
|
> > First reason > ::: > > If we have a "save partition" on top, we also have the SFS files in > > that partition. Aufs will refuse to mount those SFS files as they are > > already inside a branch. Consequently, we are forced to copy the main > > SFS file into RAM and mount it from there. However, Unionfs is quite > > happy with mounting SFS files that are actually present in another > > branch. > > Because I had experienced a recursive lock (deadlock) by a loopback > branch (fs image in a branch fs), aufs rejects it. > But it was a long time ago. It was early stage in aufs1 era. > I will check it again with recent kernel. It may work. At least, my simple tests are passed. Here is a patch for you. Test it well, if you want. J. R. Okajima diff --git a/fs/aufs/loop.c b/fs/aufs/loop.c index 5fceec7..2a78a8d 100644 --- a/fs/aufs/loop.c +++ b/fs/aufs/loop.c @@ -32,6 +32,7 @@ int au_test_loopback_overlap(struct super_block *sb, struct dentry *h_d1, struct inode *h_inode; struct loop_device *l; + return 0; h_inode = h_d1->d_inode; if (MAJOR(h_inode->i_sb->s_dev) != LOOP_MAJOR) return 0; |
From: Barry K. <bk...@gm...> - 2010-03-24 00:04:23
|
Thank you very much for your very detailed response. This is the major difference from the Unionfs mail-list, where there is often no response. The idea of temporarily remounting with 'udba=inotify' looks like a great idea! I'll try it. I will also try the patch to mount a Squashfs file that is present in another branch. This is great, thanks again for your responsiveness. Note, regarding my previous attempt to explain one or more of these issues, that was a long time ago, and I don't recall the details -- probably my explanation back then was too vague. Regarding f.s. corruption, it is another Puppy Linux developer (Jemimah) who was having trouble. I did have a one-off problem but it didn't repeat so I don't really know what that problem was. I'll do another kernel compile (with the patch applied to Aufs) and will see if I can get any f.s. errors. One interesting point about the 2.6.33 kernel is that they have dropped the ext2 and ext3 drivers as the new ext4 driver handles those also. -- probably has nothing to do with this topic, just an interesting item of news. Regards, Barry Kauler On 3/23/10, sf...@us... <sf...@us...> wrote: > >> > First reason >> ::: >> > If we have a "save partition" on top, we also have the SFS files in >> > that partition. Aufs will refuse to mount those SFS files as they are >> > already inside a branch. Consequently, we are forced to copy the main >> > SFS file into RAM and mount it from there. However, Unionfs is quite >> > happy with mounting SFS files that are actually present in another >> > branch. >> >> Because I had experienced a recursive lock (deadlock) by a loopback >> branch (fs image in a branch fs), aufs rejects it. >> But it was a long time ago. It was early stage in aufs1 era. >> I will check it again with recent kernel. > > It may work. > At least, my simple tests are passed. > Here is a patch for you. Test it well, if you want. > > > J. R. Okajima > > > diff --git a/fs/aufs/loop.c b/fs/aufs/loop.c > index 5fceec7..2a78a8d 100644 > --- a/fs/aufs/loop.c > +++ b/fs/aufs/loop.c > @@ -32,6 +32,7 @@ int au_test_loopback_overlap(struct super_block *sb, > struct dentry *h_d1, > struct inode *h_inode; > struct loop_device *l; > > + return 0; > h_inode = h_d1->d_inode; > if (MAJOR(h_inode->i_sb->s_dev) != LOOP_MAJOR) > return 0; > |