reflink status?

reflink status?

[Iustin Pop]

Apologies if this information is available somewhere, but a quick scan
at the list archives failed to clarify things for me.

How production ready is the reflink/clone code? I saw a patch series in
October for 4.19rc-something with many fixes ("fixes for serious
clone/dedupe problems"), so I guess pre-4.19 kernels are not quite
recommended yet? Is 4.19 OK for it?

Thanks in advance for any hints. Pointers to where I can keep up to date
with this besides the mailing list are also welcome.

regards,
iustin

Re: reflink status?

[Dave Chinner]

On Tue, Dec 18, 2018 at 10:22:07PM +0100, Iustin Pop wrote:
> Apologies if this information is available somewhere, but a quick scan
> at the list archives failed to clarify things for me.
> 
> How production ready is the reflink/clone code?

The XFS code is pretty robust - I've been using it in anger for
filesystem image duplication on my test machines for well over a
year now, so it gets beaten on every day by my test machines...

> I saw a patch series in
> October for 4.19rc-something with many fixes ("fixes for serious
> clone/dedupe problems"), so I guess pre-4.19 kernels are not quite
> recommended yet? Is 4.19 OK for it?

... but the vfs interfaces were not so good. The original APIs were
overly complex and not very well defined or implemented, so there
were lots of little corner cases where things could go very wrong.

IOWs, if you are doing basic stuff like cloning entire files (e.g.
cp --reflink=always) then they work just fine. However, if you have
custom apps that do partial file operations (i.e.  use the "range"
part of the API) and/or overwrite parts of existing files using
clones, then there's lots of corner cases where stuff can go wrong.

best advice right now is to use the most recent kernel you can -
4.19 has the worst problems already fixed - and upgrade to 4.20 when
it is released.....

Cheers,

Dave.
-- 
Dave Chinner
david@fromorbit.com

Re: reflink status?

[Iustin Pop]

On 2018-12-19 16:30:00, Dave Chinner wrote:
> On Tue, Dec 18, 2018 at 10:22:07PM +0100, Iustin Pop wrote:
> > Apologies if this information is available somewhere, but a quick scan
> > at the list archives failed to clarify things for me.
> > 
> > How production ready is the reflink/clone code?
> 
> The XFS code is pretty robust - I've been using it in anger for
> filesystem image duplication on my test machines for well over a
> year now, so it gets beaten on every day by my test machines...

Got it, thanks.

> > I saw a patch series in
> > October for 4.19rc-something with many fixes ("fixes for serious
> > clone/dedupe problems"), so I guess pre-4.19 kernels are not quite
> > recommended yet? Is 4.19 OK for it?
> 
> ... but the vfs interfaces were not so good. The original APIs were
> overly complex and not very well defined or implemented, so there
> were lots of little corner cases where things could go very wrong.

Interesting.

> IOWs, if you are doing basic stuff like cloning entire files (e.g.
> cp --reflink=always) then they work just fine. However, if you have
> custom apps that do partial file operations (i.e.  use the "range"
> part of the API) and/or overwrite parts of existing files using
> clones, then there's lots of corner cases where stuff can go wrong.

I see. Yes, this is my intended use case, so I'll hold off for now.

> best advice right now is to use the most recent kernel you can -
> 4.19 has the worst problems already fixed - and upgrade to 4.20 when
> it is released.....

I was hoping 4.19 is "good to go", since it's an LTS version; I prefer
to keep to LTS to reduce upgrade churn.

But, it also means the next LTS will be even more stable in this regard,
so all is good.

Thanks for the fast reply!

iustin