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."
next prev parent 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).