Jeff Hanson:
> Tried that. $BB (BThe result is that the rw branch ends up with the entire
> data of the ro branch. $BB (BIt seems that aufs copies the entire file to
> the rw branch even if only the ownership changes. $BB (BEffectively:
> aufs + chown = cp
> which eliminates my primary reason for using aufs which is to save
> storage space by eliminating the need to replicate the entire contents
> of the application directory in each users' home directory.

What did you chown?
My asummption is
- you have all common files in the ro branch.
  (if your "common" files should be run by multiple users at the same
  time as Michael S. Zick pointed, then you should not do that)
- users customize some of files, and these files are put in his rw
  branch.
- finally the rw branch has only the "difference".

If the difference is so large and the rw branch cannot have all of them
due to its space, then you just need to expand the size of rw branch.

If you have chwon-ed the common files, then that must be unnecessary.


> No. $BB (BFrom the user's perspective, only the file ownership within the
> aufs mount point appears to change. $BB (BThe real ro branch remains owned
> by root. $BB (BThey can modify the files as if they owned them but the
> changes end up in the rw branch. $BB (BThe ro branch is not affected.

Aufs never write to the ro branch.
If it happens, it must a bug.


Jeff,
I don't think your discussion style is good. You send mails to me
directly, personally and I replied to you. Later you forwarded your
messages only to the aufs ML. It might be your simple failure of
operating mail software. But it is not only once. I won't reply to your
personal mails.


J. R. Okajima

------------------------------------------------------------------------------
The ultimate all-in-one performance toolkit: Intel(R) Parallel Studio XE:
Pinpoint memory and threading errors before they happen.
Find and fix more than 250 security defects in the development cycle.
Locate bottlenecks in serial and parallel code that limit performance.
http://p.sf.net/sfu/intel-dev2devfeb

Reply via email to