> 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. Hmmm, i see yes, having to do all those lookups would indeed be expensive too. I guess it then depends on the sizes of the files you work with as for which method is better.
As my files are regularly >300mb in size, for me this is clear (rename in unionfs taking <1sec vs >1 min in aufs), but this is not a 'general' case i suppose. > 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?' Well actually i just meant disk space, not deleting a 300mb file costs me 300mb of disk space. But i can see how the current approach indeed makes it simpler to keep consistency. > 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. Possible, but that kind of defeats the purpose of using a union file system > 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. Sounds interesting... > Then, I will add this. > ---------------------------------------------------------------------- > Ignoring 'delete' option, and to keep filesystem consistency, aufs tries > writing something to only one branch. > ---------------------------------------------------------------------- Maybe add an example of a symptom of this? Like "Renaming large files can take longer than expected because aufs may move them to that writable branch in some cases." --- When i think about it logically, having all my branches writable should in theory make it possible to not have whiteouts at all, which is what i would like best. In practice this would probably make keeping consistency quite a lot more complex/expensive as it would also still have to cover the cases where whiteouts do exists. I guess its just a different type of union filesystem i am looking for. Simon Sasburg ------------------------------------------------------------------------- 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
