| Message ID | 20200930145840.GL49547@magnolia (mailing list archive) |
|---|---|
| State | Superseded, archived |
| Headers | show |
| Series | libxfs: disallow filesystems with reverse mapping and reflink and realtime | expand |
On 9/30/20 9:58 AM, Darrick J. Wong wrote: > From: Darrick J. Wong <darrick.wong@oracle.com> > > Neither the kernel nor the code in xfsprogs support filesystems that > have (either reverse mapping btrees or reflink) enabled and a realtime > volume configured. The kernel rejects such combinations and mkfs > refuses to format such a config, but xfsprogs doesn't check and can do > Bad Things, so port those checks before someone shreds their filesystem. > > Signed-off-by: Darrick J. Wong <darrick.wong@oracle.com> seems fine in general but a couple thoughts... > --- > libxfs/init.c | 14 ++++++++++++++ > 1 file changed, 14 insertions(+) > > diff --git a/libxfs/init.c b/libxfs/init.c > index cb8967bc77d4..1a966084ffea 100644 > --- a/libxfs/init.c > +++ b/libxfs/init.c > @@ -724,6 +724,20 @@ libxfs_mount( > exit(1); > } > > + if (xfs_sb_version_hasreflink(sbp) && sbp->sb_rblocks) { Hm, we really don't use xfs_sb_version_hasrealtime() very consistently, but it might be worth doing here? I wish we had a feature flag to cross-ref against, a corruption in sb_rblocks will lead to an untouchable filesystem, but I guess there's nothing we can do about that. Actually, would it help to cross-check against the rtdev arg as well? Should we do anything different if the user actually specified a realtime device on the commandline? I mean, I suppose > + fprintf(stderr, > + _("%s: Reflink not compatible with realtime device. Please try a newer xfsprogs.\n"), I like this optimism. ;) > + progname); > + exit(1); > + } > + > + if (xfs_sb_version_hasrmapbt(sbp) && sbp->sb_rblocks) { > + fprintf(stderr, > + _("%s: Reverse mapping btree not compatible with realtime device. Please try a newer xfsprogs.\n"), > + progname); > + exit(1); > + } > + > xfs_da_mount(mp); > > if (xfs_sb_version_hasattr2(&mp->m_sb)) >
On Wed, Sep 30, 2020 at 10:31:21AM -0500, Eric Sandeen wrote: > On 9/30/20 9:58 AM, Darrick J. Wong wrote: > > From: Darrick J. Wong <darrick.wong@oracle.com> > > > > Neither the kernel nor the code in xfsprogs support filesystems that > > have (either reverse mapping btrees or reflink) enabled and a realtime > > volume configured. The kernel rejects such combinations and mkfs > > refuses to format such a config, but xfsprogs doesn't check and can do > > Bad Things, so port those checks before someone shreds their filesystem. > > > > Signed-off-by: Darrick J. Wong <darrick.wong@oracle.com> > > seems fine in general but a couple thoughts... > > > --- > > libxfs/init.c | 14 ++++++++++++++ > > 1 file changed, 14 insertions(+) > > > > diff --git a/libxfs/init.c b/libxfs/init.c > > index cb8967bc77d4..1a966084ffea 100644 > > --- a/libxfs/init.c > > +++ b/libxfs/init.c > > @@ -724,6 +724,20 @@ libxfs_mount( > > exit(1); > > } > > > > + if (xfs_sb_version_hasreflink(sbp) && sbp->sb_rblocks) { > > Hm, we really don't use xfs_sb_version_hasrealtime() very > consistently, but it might be worth doing here? Nah, I'll move it to rtmount_init. > I wish we had a feature flag to cross-ref against, a corruption in > sb_rblocks will lead to an untouchable filesystem, but I guess there's > nothing we can do about that. I guess xfs_repair could add a -E killrt=1 flag that would read the sb, zero out sb_rblocks, and pass that to libxfs_mount. > Actually, would it help to cross-check against the rtdev arg as well? > Should we do anything different if the user actually specified a > realtime device on the commandline? I doubt it? I mean, the fs allege it has an rt volume and some unsupported feature; it doesn't matter if the user did or didn't pass an rtdev. > I mean, I suppose you suppose...? > > > + fprintf(stderr, > > + _("%s: Reflink not compatible with realtime device. Please try a newer xfsprogs.\n"), > > I like this optimism. ;) Optimism? /me now has an xfsprogs that /does/ support rt rmap and reflink, though at current patch review rates it won't hit the list until 2024, and that's assuming I can keep ahead of all the bitrot in rtrmap... --D > > > > + progname); > > + exit(1); > > + } > > + > > + if (xfs_sb_version_hasrmapbt(sbp) && sbp->sb_rblocks) { > > + fprintf(stderr, > > + _("%s: Reverse mapping btree not compatible with realtime device. Please try a newer xfsprogs.\n"), > > + progname); > > + exit(1); > > + } > > + > > xfs_da_mount(mp); > > > > if (xfs_sb_version_hasattr2(&mp->m_sb)) > >
diff --git a/libxfs/init.c b/libxfs/init.c index cb8967bc77d4..1a966084ffea 100644 --- a/libxfs/init.c +++ b/libxfs/init.c @@ -724,6 +724,20 @@ libxfs_mount( exit(1); } + if (xfs_sb_version_hasreflink(sbp) && sbp->sb_rblocks) { + fprintf(stderr, + _("%s: Reflink not compatible with realtime device. Please try a newer xfsprogs.\n"), + progname); + exit(1); + } + + if (xfs_sb_version_hasrmapbt(sbp) && sbp->sb_rblocks) { + fprintf(stderr, + _("%s: Reverse mapping btree not compatible with realtime device. Please try a newer xfsprogs.\n"), + progname); + exit(1); + } + xfs_da_mount(mp); if (xfs_sb_version_hasattr2(&mp->m_sb))