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 <jba...@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).
> 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.
Thanks,
--Mark
--
Mark Fasheh
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
