I'd like btrfs to support full featured send and receive in the future.
If nobody is currently working on it, I'll grab the send/receive lock.
Now that I own the lock, I'm opening several discussions on this topic.
If you are in a hurry, it would be great if you could at least read and
comment on t
Hi Jan
On 08/01/2011 02:22 PM, Jan Schmidt wrote:
> I furthermore realized that the term "subvolume" is omitted in favor >
of the term "snapshot". This is because I tend to think of snapshots
> being read-only (though I very much appreciate they are not). Just
> replace the term wherever you feel
On 01.08.2011 20:51, Goffredo Baroncelli wrote:
> On 08/01/2011 02:22 PM, Jan Schmidt wrote:
>
>> I furthermore realized that the term "subvolume" is omitted in favor >
> of the term "snapshot". This is because I tend to think of snapshots
>> being read-only (though I very much appreciate they a
Excerpts from Jan Schmidt's message of 2011-08-02 05:43:39 -0400:
>
> On 01.08.2011 20:51, Goffredo Baroncelli wrote:
> > On 08/01/2011 02:22 PM, Jan Schmidt wrote:
> >
> >> I furthermore realized that the term "subvolume" is omitted in favor >
> > of the term "snapshot". This is because I tend t
On 02.08.2011 17:21, Chris Mason wrote:
> First: awesome! I can't wait to have this feature.
>
> I think you have a very sound list of requirements here, but I'll add
> one more. If there are metadata corruptions on the sender, we must not
> transmit them over to the receiver. In order for the
Hi all,
[...]
>
> Furthermore, receiving should not need kernel support at all (except for
> an optional interface to create a file with a certain inode, we'll see).
> Thus, replicating metadata corruptions should be very unlikely.
I think that for receiving we can have three level, which may re
On 02.08.2011 19:42, Goffredo Baroncelli wrote:
>> Furthermore, receiving should not need kernel support at all (except for
>> an optional interface to create a file with a certain inode, we'll see).
>> Thus, replicating metadata corruptions should be very unlikely.
>
> I think that for receiving
On 02.08.2011 18:01, Jan Schmidt wrote:
> On 02.08.2011 17:21, Chris Mason wrote:
>> But, I'll toss in an alternative. Adapt the git pack files a little and
>> use them as the format. There are a few reasons for this:
>>
>> Git has a very strong developer community and is already being
>> hammere
On Wednesday, 03 August, 2011 17:04:40 Jan Schmidt wrote:
> On 02.08.2011 19:42, Goffredo Baroncelli wrote:
> >> Furthermore, receiving should not need kernel support at all (except for
> >> an optional interface to create a file with a certain inode, we'll see).
> >> Thus, replicating metadata cor
On Tuesday, 02 August, 2011 11:43:39 you wrote:
> On 01.08.2011 20:51, Goffredo Baroncelli wrote:
[...]
> > 1) If we are interested to transport only the file
> > type/contents/timestamps/acls/owners/permissions, that could be obtained
> > with a combination of "find-new" (with some extensions [1])
10 matches
Mail list logo
