linux-btrfs.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Filipe David Manana <fdmanana@gmail.com>
To: Mark Fasheh <mfasheh@suse.de>
Cc: Josef Bacik <jbacik@fb.com>,
	"linux-btrfs@vger.kernel.org" <linux-btrfs@vger.kernel.org>
Subject: Re: [PATCH 1/4] Btrfs: send, bump stream version
Date: Tue, 15 Apr 2014 20:49:52 +0100	[thread overview]
Message-ID: <CAL3q7H5yYFOiJ=BkEHaRLOh87CoL49xqdm1-aFa2dPASwCFMSg@mail.gmail.com> (raw)
In-Reply-To: <20140415193518.GG7901@wotan.suse.de>

On Tue, Apr 15, 2014 at 8:35 PM, Mark Fasheh <mfasheh@suse.de> wrote:
> On Tue, Apr 15, 2014 at 07:30:51PM +0100, Filipe David Manana wrote:
>> On Tue, Apr 15, 2014 at 7:10 PM, Josef Bacik <jbacik@fb.com> wrote:
>> > Just make a SUPPORTS_V2 flag that userspace can pass in through the existing flags to make the kernel spit out V2 commands.  We don't want to break old user space, I still have to see distro guys in real life ;).  Thanks,
>>
>> So would this flag named like "supports_v2" imply to send fallocate
>> commands and data size computation/command? Right now I made data size
>> optional, sent only if a new ioctl send flag is set, because for large
>> fs trees it can take some time to compute data size.
>
> If it's already backwards-compatibilty you could keep the flag for data size computation as-is
> and simply add another flag that gets passed in for the fallocate commands
> (UNDERSTANDS_FALLOCATE or something lke that).

Yep, exactly what I had in mind.

>
>
>
>> Also, would new btrfs-progs version send that flag (support_v2)
>> always, without any option to use old v1, or not really that useful?
>
>
> As far as btrfs-progs go you could go with many different approaches. For
> the library interface to this we might just let the callers determine the
> behavior they want. For the command processing (user runs the btrfs program
> directly), you could do a couple things:
>
> - perhaps try once with the new flags, if you get an error (EINVAL right now
>   for bad flags) try with the old ones and only then throw an error out to
>   the caller?
>
> - have user specify whether new flags should be tried or not (this is
>   easiest)
>
> I would generally avoid breaking compatibility inside of btrfs-progs too so
> just forcing the new flag seems the most 'breaking' option.

Sounds good. Will probably try first to have the user explicitly pass
a --stream-version=2 for e.g to btrfs send command, with v1 (current)
being the default. I like the idea of clearing the
SUPPORT_FALLOCATE/DATA_SIZE bits from the flags and retry if the ioctl
returns -EINVAL too.

Thanks Mark

>
> Thanks,
>         --Mark
>
> --
> Mark Fasheh



-- 
Filipe David Manana,

"Reasonable men adapt themselves to the world.
 Unreasonable men adapt the world to themselves.
 That's why all progress depends on unreasonable men."

  reply	other threads:[~2014-04-15 19:49 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-04-15 16:40 [PATCH 1/4] Btrfs: send, bump stream version Filipe David Borba Manana
2014-04-15 16:40 ` [PATCH 2/4] Btrfs: send, implement total data size command to allow for progress estimation Filipe David Borba Manana
2014-04-16 14:50   ` [PATCH 2/4 v2] " Filipe David Borba Manana
2014-04-15 16:40 ` [PATCH 3/4] Btrfs: send, use fallocate command to punch holes Filipe David Borba Manana
2014-04-16 14:51   ` [PATCH 3/4 v2] " Filipe David Borba Manana
2014-04-16 16:16   ` [PATCH 3/4 v3] " Filipe David Borba Manana
2014-04-15 16:40 ` [PATCH 4/4] Btrfs: send, use fallocate command to allocate extents Filipe David Borba Manana
2014-04-16 14:52   ` [PATCH 4/4 v2] " Filipe David Borba Manana
2014-04-16 17:56   ` [PATCH 4/4 v3] " Filipe David Borba Manana
2014-04-15 17:28 ` [PATCH 1/4] Btrfs: send, bump stream version Mark Fasheh
2014-04-15 17:34   ` Filipe David Manana
2014-04-15 17:41     ` Mark Fasheh
2014-04-15 17:57       ` Filipe David Manana
2014-04-15 18:04         ` Mark Fasheh
2014-04-15 18:10           ` Josef Bacik
2014-04-15 18:30             ` Filipe David Manana
2014-04-15 19:35               ` Mark Fasheh
2014-04-15 19:49                 ` Filipe David Manana [this message]
2014-04-18 17:18                   ` David Sterba
2014-04-18 19:58                     ` Filipe David Manana
2014-04-16 14:48 ` [PATCH 1/4 v2] " Filipe David Borba Manana
2014-04-20 14:01   ` [PATCH 1/6 v3] " Filipe David Borba Manana
2014-06-23 12:00 ` [PATCH 1/6 v5] " Filipe David Borba Manana

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='CAL3q7H5yYFOiJ=BkEHaRLOh87CoL49xqdm1-aFa2dPASwCFMSg@mail.gmail.com' \
    --to=fdmanana@gmail.com \
    --cc=jbacik@fb.com \
    --cc=linux-btrfs@vger.kernel.org \
    --cc=mfasheh@suse.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
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).