sf...@users.sourceforge.net wrote:

> > If I do the same on a pure ext3 system, the inode number of the
> > file is not being changed if I copy new content in it. It is just
> > the case if I do some kind of copy-on-write.
> 
> I might misunderstand the behaviour of rsync.
> I thought it operats
> - create a temporary empty file, get a new inode
> - write latest contents to it
> - rename it to the original name, old file is remove
>
> But according to your experience, rsync seems to operate
> - open and truncate a file
> - write latest contents to it
> So the inode number is unchanged.
> 

No, I made a mistake and made the test with just a "cp", which behaves
like I said and I assumed rsync would do the same.
Now I also know what these "--delete-XXXXX" parameters of rsync do.
AFAIK you're right about the behaviour of rsync and your explanation in
your second-last post makes sense to me.

If I substitute the rsync command to this in my script:

rsync --exclude=".wh.*" --exclude=lost+found --inplace -vaHx --devices
--specials ${UPPER_BRANCH} ${LOWER_BRANCH}

, rsync behaves like "cp" would do and the fsck errors are gone. :D

The "--inplace" option of rsync has some tradeoffs, that are described
in the manpage.

Do you consider this a bug in aufs, though?

> I am afraid that the "Deleted inode XXXX has zero dtime" msg in your
> fsck log made me misunderstood. Now I'd ask you "Who deleted what?"
> Is another process like log rotation (for example) related to this
> problem?
> 
> 

So I guess it was rsync too...


> > > ext3 is already set to readonly, right?
> > At which part of the process? Do you mean right after the rsync
> > command? However, below is the script I am using.
> 
> I meant
> when you shutdown your system, ext3 is readonly, right?

Yes.


> > > > If this option is correct, it is worth to try remounting ext3
> > > > writable in your shutdown script. But it is just my guess.
> > This script is not neccessarily called at shutdown. I call it at
> > random times.
> 
> I meant
> - run your rsync script
> - before you shutdown your system, remount ext3 as readwrite
> - and shutdown

Well, I will try that - but after errors are discovered from fsck
once, the system will refuse to remount the filesystem in whatever way.
But it is vital for me that remounts, and so the copy-downs are
possible multiple times.


# Marcus

------------------------------------------------------------------------------
Increase Visibility of Your 3D Game App & Earn a Chance To Win $500!
Tap into the largest installed PC base & get more eyes on your game by
optimizing for Intel(R) Graphics Technology. Get started today with the
Intel(R) Software Partner Program. Five $500 cash prizes are up for grabs.
http://p.sf.net/sfu/intelisp-dev2dev

Reply via email to