Re: [GIT PULL] ocfs2 changes for 2.6.32
From: Linus Torvalds
Date: Mon Sep 14 2009 - 19:28:46 EST
On 2009年9月14日, Joel Becker wrote:
>
>
It's a link(2) analogue. symlink(2) has the loosest coupling,
>
and reflink(2) the highest. We're not going to add freflink[at]().
>
It's a snap, not a copy. It can be used to implement a copy, and
>
copyfile() in libc can be written with reflinkat(2), but it isn't just a
>
copy.
>
From all but a performance standpoint, it's a copy. It has absolutely
_zero_ "link" semantics. When you do a symlink or a hardlink, you see it
in the resulting semantics: changing one changes the other.
This 'reflink' has no such semantics that I can tell. It has purely copy
semantics, never mind that it's optimized.
And the thing to note is that it doesn't even have to be optimized as a
"link". Think about network filesystems: maybe they want to implement this
thing as a server-side "copy" operation (with atomicity guarantees).
In other words, I can well imagine that for some filesystems, there really
is no refcounting or linking implied, and that's why I think naming should
be about semantics, not some random implementation issue that just happens
to be true for some particular class of filesystems.
So tell me - are there actually any non-copying semantics as far as the
_user_ is concerned? Is there some reason why a NFS server might not
implement this as a server-side copy? Is there something fundamentally in
this all that is about reference counting as far as a user is concerned?
I also still didn't get any answer to the "freflink()" question. You just
said that we wouldn't do it, with no explanation. Why? We've discussed
'flink()' in the past, I just want to know that when we do a new system
call there is some _reason_ why it's not going to explode into many
different variants later...
Linus
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at
http://vger.kernel.org/majordomo-info.html
Please read the FAQ at
http://www.tux.org/lkml/