On Mon, Jun 10, 2019 at 04:02:36PM +0200, David Sterba wrote:
> On Mon, Jun 10, 2019 at 12:42:26PM +0000, Hugo Mills wrote:
> >    Hi, David,
> > 
> > On Mon, Jun 10, 2019 at 02:29:40PM +0200, David Sterba wrote:
> > > this patchset brings the RAID1 with 3 and 4 copies as a separate
> > > feature as outlined in V1
> > > (https://lore.kernel.org/linux-btrfs/cover.1531503452.git.dsterba@suse.com/).
> > [...]
> > > Compatibility
> > > ~~~~~~~~~~~~~
> > > 
> > > The new block group types cost an incompatibility bit, so old kernel
> > > will refuse to mount filesystem with RAID1C3 feature, ie. any chunk on
> > > the filesystem with the new type.
> > > 
> > > To upgrade existing filesystems use the balance filters eg. from RAID6
> > > 
> > >   $ btrfs balance start -mconvert=raid1c3 /path
> > [...]
> > 
> >    If I do:
> > 
> > $ btrfs balance start -mprofiles=raid13c,convert=raid1 \
> >                       -dprofiles=raid13c,convert=raid6 /path
> > 
> > will that clear the incompatibility bit?
> 
> No the bit will stay, even though there are no chunks of the raid1c3
> type. Same for raid5/6.
> 
> Dropping the bit would need an extra pass trough all chunks after
> balance, which is feasible and I don't see usability surprises. That you
> ask means that the current behaviour is probably opposite to what users
> expect.

   We've had a couple of cases in the past where people have tried out
a new feature on a new kernel, then turned it off again and not been
able to go back to an earlier kernel. Particularly in this case, I can
see people being surprised at the trapdoor. "I don't have any RAID13C
on this filesystem: why can't I go back to 5.2?"

   Hugo.

-- 
Hugo Mills             | Great films about cricket: Forrest Stump
hugo@... carfax.org.uk |
http://carfax.org.uk/  |
PGP: E2AB1DE4          |