Re: Deduplication on stat change?

[sfjro]

Karl Semich:
> Would it be reasonable for aufs to refrain from copying up if only the
> ctime is changed?  Perhaps a mount option to ignore isolated ctime
> changes?

Hmm, I think I can understand your point.
But it won't be so easy to decide because it is against a generic
filesystem behaviour.

Very basic behaviour:
- on ext2 or something
$ > fileA
$ stat fileA
$ sleep 1
$ chown $(id -u) fileA
$ stat fileA
- then you can see only ctime was changed.

If we introduce "ignore_isolated_ctime_change" mount option, then this
behaviour breaks. Ok, that is intentinal and won't be a problem.

Hmm, I need to consider more about it.
Give me some time.


J. R. Okajima

--
Transform Data into Opportunity.
Accelerate data analysis in your applications with
Intel Data Analytics Acceleration Library.
Click to learn more.
http://pubads.g.doubleclick.net/gampad/clk?id=278785111=/4140

Re: Deduplication on stat change?

[Karl Semich]

Hi,

On 3/8/16, sf...@users.sourceforge.net  wrote:
>
> Splitting file-data and meta-data will break these policies.
>
> For your case, I'd suggest you to try
>   $ find /your/dir \! -user userA | xargs -r chown userB

I think the problem is when this occurs catastrophically as an
accident, having forgotten that large chown's need to be guarded like
this.

Would it be reasonable for aufs to refrain from copying up if only the
ctime is changed?  Perhaps a mount option to ignore isolated ctime
changes?

-Karl

--
Transform Data into Opportunity.
Accelerate data analysis in your applications with
Intel Data Analytics Acceleration Library.
Click to learn more.
http://pubads.g.doubleclick.net/gampad/clk?id=278785111=/4140

Re: Deduplication on stat change?

[sfjro]

Hello Karl,

Karl Semich:
> I was wondering if there could be some way to deduplicate in this
> scenario?  Such that when the ctime needs to be updated, just some
> small metafile is copied up, and not all the contents which could be
> many gigabytes?

Many years ago, I had thought about somethink like that, but gave
up. And aufs still keeps the policy like these.
- the branch fs is still a valid fs as usual
- users can use the branch fs as usual
- etc.

Splitting file-data and meta-data will break these policies.

For your case, I'd suggest you to try
$ find /your/dir \! -user userA | xargs -r chown userB


J. R. Okajima

--
Transform Data into Opportunity.
Accelerate data analysis in your applications with
Intel Data Analytics Acceleration Library.
Click to learn more.
http://pubads.g.doubleclick.net/gampad/clk?id=278785111=/4140