linux-btrfs.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
* Why isnt NOCOW attributes propogated on snapshot transfers?
@ 2017-10-15  1:19 Cerem Cem ASLAN
  2017-10-16  0:51 ` Qu Wenruo
  2017-10-16 13:28 ` David Sterba
  0 siblings, 2 replies; 4+ messages in thread
From: Cerem Cem ASLAN @ 2017-10-15  1:19 UTC (permalink / raw)
  To: linux-btrfs

`btrfs send | btrfs receive` removes NOCOW attributes. Is it a bug or
a feature? If it's a feature, how can we keep these attributes if we
need to?

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: Why isnt NOCOW attributes propogated on snapshot transfers?
  2017-10-15  1:19 Why isnt NOCOW attributes propogated on snapshot transfers? Cerem Cem ASLAN
@ 2017-10-16  0:51 ` Qu Wenruo
  2017-10-16 13:28 ` David Sterba
  1 sibling, 0 replies; 4+ messages in thread
From: Qu Wenruo @ 2017-10-16  0:51 UTC (permalink / raw)
  To: Cerem Cem ASLAN, linux-btrfs



On 2017年10月15日 09:19, Cerem Cem ASLAN wrote:
> `btrfs send | btrfs receive` removes NOCOW attributes. Is it a bug or
> a feature? If it's a feature, how can we keep these attributes if we
> need to?

It seems that, current send doesn't have support for extra inode flags.

Send can only send out c/m/atime, uid/gid and xattr.

Since NODATACOW is stored in inode item flags, not xattr, so it's not 
supported yet.

Thanks,
Qu
> --
> To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: Why isnt NOCOW attributes propogated on snapshot transfers?
  2017-10-15  1:19 Why isnt NOCOW attributes propogated on snapshot transfers? Cerem Cem ASLAN
  2017-10-16  0:51 ` Qu Wenruo
@ 2017-10-16 13:28 ` David Sterba
  2017-10-16 15:59   ` Graham Cobb
  1 sibling, 1 reply; 4+ messages in thread
From: David Sterba @ 2017-10-16 13:28 UTC (permalink / raw)
  To: Cerem Cem ASLAN; +Cc: linux-btrfs

On Sun, Oct 15, 2017 at 04:19:23AM +0300, Cerem Cem ASLAN wrote:
> `btrfs send | btrfs receive` removes NOCOW attributes. Is it a bug or
> a feature? If it's a feature, how can we keep these attributes if we
> need to?

This is a known defficiency of send protocol v1. And there are more,
listed on
https://btrfs.wiki.kernel.org/index.php/Design_notes_on_Send/Receive#Send_stream_v2_draft

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: Why isnt NOCOW attributes propogated on snapshot transfers?
  2017-10-16 13:28 ` David Sterba
@ 2017-10-16 15:59   ` Graham Cobb
  0 siblings, 0 replies; 4+ messages in thread
From: Graham Cobb @ 2017-10-16 15:59 UTC (permalink / raw)
  To: linux-btrfs

On 16/10/17 14:28, David Sterba wrote:
> On Sun, Oct 15, 2017 at 04:19:23AM +0300, Cerem Cem ASLAN wrote:
>> `btrfs send | btrfs receive` removes NOCOW attributes. Is it a bug or
>> a feature? If it's a feature, how can we keep these attributes if we
>> need to?
> 
> This is a known defficiency of send protocol v1. And there are more,
> listed on
> https://btrfs.wiki.kernel.org/index.php/Design_notes_on_Send/Receive#Send_stream_v2_draft

It is not mentioned on the list (and I haven't tested to find out)...
but if xattr are supported in the V1 protocol, any chance of `send`
converting these file flags to xattr, and `receive` converting back? No
need for a protocol bump and would even preserve the information
(although not the effect) in the case of an old receiver.

^ permalink raw reply	[flat|nested] 4+ messages in thread

end of thread, other threads:[~2017-10-16 15:59 UTC | newest]

Thread overview: 4+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2017-10-15  1:19 Why isnt NOCOW attributes propogated on snapshot transfers? Cerem Cem ASLAN
2017-10-16  0:51 ` Qu Wenruo
2017-10-16 13:28 ` David Sterba
2017-10-16 15:59   ` Graham Cobb

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).