On Sat, 07 Aug 2010 07:33:07 +0900, sfjro wrote:
>> mount -t aufs -o br:./rw:./ro2=wh:./ro1 none ./u
>
> I am afraid this branch permission "=wh" returned an error. Did it
> really succeed?
It seems to be OK at my side. Here is the full log around the point that
I did it:
r...@coral:/dev/shm/aumt# umount /dev/shm/aumt/u
r...@coral:/dev/shm/aumt# mount -vt aufs -o br:./rw:./ro2:./ro1 none ./u
none on /dev/shm/aumt/u type aufs (rw,relatime,si=a5a2917852f9942e)
r...@coral:/dev/shm/aumt# mount -o remount,ro,mod:ro2=ro+wh u
r...@coral:/dev/shm/aumt# umount /dev/shm/aumt/u
r...@coral:/dev/shm/aumt# mount -t aufs -o br:./rw:./ro2=wh:./ro1 none ./u
r...@coral:/dev/shm/aumt#
r...@coral:/dev/shm/aumt# umount /dev/shm/aumt/u
r...@coral:/dev/shm/aumt# mount -t aufs -o br:./rw:./ro2=wh:./ro1 none ./u
r...@coral:/dev/shm/aumt# ls u/d?
u/d1:
1 2 3 4 5 6 7 8 9 four
. . .
I have to admit that my aufs-tools is not up to the bleeding edge:
$ apt-cache policy aufs-tools
aufs-tools:
Installed: 20100601-1
Candidate: 20100601-1
Version table:
*** 20100601-1 0
360 http://cdn.debian.net testing/main Packages
50 http://cdn.debian.net unstable/main Packages
100 /var/lib/dpkg/status
> Because the permission "=wh" returned an error, the whiteout ".wh.4" has
> no effect. And "ls u/d?" showed "4", I guess.
yes, that explains it well.
>
>> % aubrsync _move u rw/ ro1/ '--remove-source-files --exclude=.wh..wh.*
>> rw/ ro2'
> :::
>> ++ rsync --exclude=lost+found -aHSx --devices --specials
>> --delete-before --remove-source-files '--exclude=.wh..wh.*' rw/ ro2
> :::
>> See, all the previous content have gone.
>
> Because "--delete-before" is specified. How about specifying
> "--max-delete=0"? But this option depends upon your rsync version.
I'm afraid not:
--delete-before receiver deletes before transfer (default)
I.e., "--delete-before" is the default action. It only affect the files
to be copied over. Nothing else.
--delete-before
Request that the file-deletions on the receiving side be
done before the transfer starts. See --delete (which is
implied) for more details on file-deletion.
Deleting before the transfer is helpful if the
filesystem is tight for space and removing extraneous
files would help to make the transfer possible.
However, it does introduce a delay before the start of
the transfer, and this delay might cause the transfer to
timeout (if --timeout was specified). It also forces
rsync to use the old, non-incremental recursion
algorithm that requires rsync to scan all the files in
the transfer into memory at once (see --recursive).
>> Could you double check please?
>
> I don't think you expect me to double check what you did. :-)
Fine, not what I did.
But could you double check if the 2nd invocation of 'aubrsync _move'
doesn't affect old history at your side please? I was hoping that giving
my work history would make your life a bit easier than re-creating/
retyping on your own. Anyway...
Thanks for your help.
--
Tong (remove underscore(s) to reply)
http://xpt.sourceforge.net/techdocs/
http://xpt.sourceforge.net/tools/
------------------------------------------------------------------------------
This SF.net email is sponsored by
Make an app they can't live without
Enter the BlackBerry Developer Challenge
http://p.sf.net/sfu/RIM-dev2dev
