"Simon Sasburg": > Well, it may be effective, but IMHO it is far from optimal. Moving a > file within 1 filesystem is an operation that costs nearly nothing > usually, while moving a file across file systems can be very expensive > as it has to actually move all the data, this becomes especially > problematic with larger files.
Of course, it is. If we rename a file on the same branch, we must check these things, - there is no whiteout for the target file on all upper branches - there is no diropq for the target parent dir on all upper branches - there is no same named file on all upper branches You say to copyup is expensive when a file size is large. Probably you can guess to check these things is expensive too when a branch is deep. Additionally, if you knew the costs of the name lookup and known file i/o and compared them, you would not say that the current algorithm is far from optimal. > In addition, the creation of the whiteout instead of just deleting the > file (why does it do this? its on a writeable branch, why white it > out?) is wasting space, this again becomes more problematic with > larger files. Generally aufs tries keeping only one branch to be written, in order to keep the consistency. In your case, the first branch was chosen and aufs didn't write anything to other branches. This is the reason to whiteout. I guess what you call 'wasting space' is a name space in a dir, but what is 'more problematic?' > Now i know making rename/move more 'optimal' will probably make it > quite a bit more complex to handle all the cases it needs to, but it > may be something to think about or put on a todo list somewhere? If you don't like current algorithm, why don't you rename it on that branch? You may want to use 'udba=inotify' mount option. I have/had a plan to introduce a new mount option 'writable_branch_policy=foo|bar', to support multiple writable branches. But the idea may be far from what you want. > By the way, i just tested unionfs, and it does keep a file on its own > branch during a move/rename, at least when the targets parent dir > exists on that branch, so it is possible to do this, it seems. This > issue may be something to mention in the "Compatible/Incompatible with > Unionfs" part of the manual too? Then, I will add this. ---------------------------------------------------------------------- Ignoring 'delete' option, and to keep filesystem consistency, aufs tries writing something to only one branch. ---------------------------------------------------------------------- Junjiro Okajima ------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
