Re: [PATCH 2/2] mkfs: remove notion of config "type"

[Dave Chinner <david@fromorbit.com>]

On Fri, Jun 15, 2018 at 07:55:02PM -0500, Eric Sandeen wrote:
> t
> 
> On 6/15/18 7:17 PM, Dave Chinner wrote:
> > On Thu, Jun 14, 2018 at 09:45:49PM -0500, Eric Sandeen wrote:
> >>
> >>
> >> On 6/14/18 9:33 PM, Dave Chinner wrote:
> >>> On Thu, Jun 14, 2018 at 07:10:09PM -0700, Luis R. Rodriguez wrote:
> >>>> Silly mobile gmail interface not letting me bottom-post... What if we treat
> >>>> no version being present as version 0?
> >>>
> >>> We haven't released anything yet so we should put it in there from
> >>> the start rather than having to work around the lack of a version
> >>> field later.
> >>
> >> So, pretend I'm dumb ('cause I often am) and spell it out for me, what would
> >> we do with a version?
> >>
> >> If a config file contains a section or token that some version of mkfs doesn't
> >> understand, it'll fail.
> >>
> >> If we try to read a config file with a too-new version, we'd ... fail?
> > 
> > Fail with a useful error message, rather than do something
> > unexpected or incorrect.
> 
> like "section 'foo' uknown" or "token 'bar' unknown?"
> We'd do that today...

User upgrades xfsprogs version (e.g. has built a git version to sort
a problem with repair. Days later, runs mkfs, it throws "unknown
foo" errors. User has no idea why, nor how to remedy the problem.

As opposed to an error that says "Config file version too old -
please update", which tells them exactly what the problem is, and
it's easy to understand that it's a result of using the git version
rather than the distro packaged version.

> > Let's face it - the config file is a persistent, on-disk structure
> > that we have to handle in both forwards and backwards compatible
> > manners for many, many years. It's no different to the on-disk
> > format in that respect. Why wouldn't we apply the same guards for
> > format changes we apply to syscalls, ioctls, on-disk formats, etc
> > that all have the same long term compatibility requirements?
> 
> Indeed, with on-disk formats we have compat, incompat, ro-compat ....
> 
> Are you proposing forward and backward, compat/imcompat ... tokens?
> Pobably not.

No. Just a version number.

> Disk formats have that because we may corrupt the things around us if
> we don't understand the existence of a new metadata type; others we can
> safely ignore.
> 
> With ioctls we have a set size; the only time we have versions is if we
> have padding that should now be parsed in a newer version.

ioctls and syscalls have flags fields in either the API or in the
data stuctures that are passed in to indicate what the function and
data structures support. This changes over time even when the
ioctl/syscall definition and structures don't change size. And if we
leave the version field in the same location across revisions of the
format, then we have a mechanism for supporting both internal
feature support addition/removal and entire file format changes...

Cheers,

Dave.
-- 
Dave Chinner
david@fromorbit.com