Re: Why Unionfs is better than Aufs
Status: Beta
Brought to you by:
sfjro
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 |