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
