From: Eric Sandeen <sandeen@redhat.com>
To: xfs-oss <xfs@oss.sgi.com>
Subject: [PATCH 0/3] xfsdump: more projid32bit fixes
Date: Fri, 12 Oct 2012 16:32:00 -0500 [thread overview]
Message-ID: <50788C50.40600@redhat.com> (raw)
I recently sent a patch for 32-bit project IDs for xfsdump, to properly
restore the top 16 bits, which otherwise get lost. This forced a new
dump format version 4 (we were currently at 3).
One thing missing is that we should not restore a dump with 32-bit
project IDs onto a filesystem w/o that format; the restore will fail
to restore the top 16 bits (but otherwise it returns success; attribute
setting failures are not fatal (!?))
Also, 32-bit project ID is a bit uncommon; bumping the format (and making
older restore incompatible) is a bit draconian.
3 patches here:
1/3: extend fs info call to get fs flags as well
2/3: default back to V3 and go to V4 only if the projid32 flag is set
3/3: fail restore if the target XFS fs doesn't have projid32 set
I have to say, I'm not super happy with this. I have nagging fear
of feature-flag-itis, and I'm not sure how extensible this is as newer
versions may appear. But anyway, here's a place to start.
(p.s. anybody have wkendall's new email?) ;)
_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs
next reply other threads:[~2012-10-12 21:30 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-10-12 21:32 Eric Sandeen [this message]
2012-10-12 21:35 ` [PATCH 1/3] xfsdump: extend fs_info to gather fs feature flags Eric Sandeen
2012-11-09 18:31 ` Rich Johnston
2012-10-12 21:37 ` [PATCH 2/3] xfsdump: default to V3, use V4 if projid32bit is set Eric Sandeen
2012-11-09 18:31 ` Rich Johnston
2012-11-09 18:32 ` Eric Sandeen
2012-10-12 21:42 ` [PATCH 3/3] xfsdump: refuse restore of V4 format unless FS has projid32bit set Eric Sandeen
2012-11-09 18:32 ` Rich Johnston
2012-10-22 14:36 ` [PATCH 0/3] xfsdump: more projid32bit fixes Eric Sandeen
2012-10-22 15:56 ` Ben Myers
2012-10-22 16:22 ` Eric Sandeen
2012-10-22 20:24 ` Ben Myers
2012-10-22 20:30 ` Eric Sandeen
2012-10-22 20:11 ` Eric Sandeen
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=50788C50.40600@redhat.com \
--to=sandeen@redhat.com \
--cc=xfs@oss.sgi.com \
/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