On Mon, Jun 17, 2019 at 11:28:03PM -0700, Sheena Artrip wrote: > On Mon, Jun 17, 2019 at 3:56 PM Darrick J. Wong <darrick.wong@xxxxxxxxxx> wrote: > > > > On Mon, Jun 17, 2019 at 03:09:15PM -0700, Sheena Artrip wrote: > > > On Thu, Jun 6, 2019 at 3:37 PM Dave Chinner <david@xxxxxxxxxxxxx> wrote: > > > > > > > > On Thu, Jun 06, 2019 at 05:08:12PM -0500, Eric Sandeen wrote: > > > > > On 6/6/19 4:50 PM, Dave Chinner wrote: > > > > > > My take on this is that we need to decide which allocation policy to > > > > > > use - the kernel policy or the dump file policy - in the different > > > > > > situations. It's a simple, easy to document and understand solution. > > > > > > > > > > > > At minimum, if there's a mismatch between rtdev/non-rtdev between > > > > > > dump and restore, then restore should not try to restore or clear rt > > > > > > flags at all. i.e the rt flags in the dump image should be > > > > > > considered invalid in this situation and masked out in the restore > > > > > > process. This prevents errors from being reported during restore, > > > > > > and it does "the right thing" according to how the user has > > > > > > configured the destination directory. i.e. if the destdir has the > > > > > > rtinherit bit set and there's a rtdev present, the kernel policy > > > > > > will cause all file data that is restored to be allocated on the > > > > > > rtdev. Otherwise the kernel will place it (correctly) on the data > > > > > > dev. > > > > > > > > > > > > In the case where both have rtdevs, but you want to restore to > > > > > > ignore the dump file rtdev policy, we really only need to add a CLI > > > > > > option to say "ignore rt flags" and that then allows the kernel > > > > > > policy to dictate how the restored files are placed in the same way > > > > > > that having a rtdev mismatch does. > > > > > > > > > > > > This is simple, consistent, fulfils the requirements and should have > > > > > > no hidden surprises for users.... > > > > > > > > > > Sounds reasonable. So the CLI flag would say "ignore RT info in the > > > > > dump, and write files according to the destination fs policy?" > > > > > I think that makes sense. > > > > > > Any suggested flag name/prefix for this? Last i checked all the single > > > letters were taken up? > > > > I suggest --preserve-xflags=<same letters as xfs_io lsattr command> > > What's the implication? That we do not copy any xflags bits unless you > include them in --preserve-xflags? > The defaults of this would be all the available fields. > > That still leaves the destination needing a xflag bit like realtime > and the source not having it...Maybe > xfsdump needs --preserve-xflags and xfsrestore needs --apply-xflags ? > That will catch > all the cases and the solution is just an and/xor on the > outgoing/incoming bsp_xflags field: > > * realtime->realtime (--preserve-xflags=all --apply-xflags=none) > * non-realtime->realtime (--preserve-xflags=all --apply-xflags=t) > * non-realtime->non-realtime (--preserve-xflags=all --apply-xflags=none) > * realtime->non-realtime (--preserve-xflags=all-but-t) I was clearly confusing, my apologies. :/ What I should've said more explicitly was that xfsdump continues to save all the xflags as it does now, and that we should consider adding a new cli option to xfsrestore to preserve certain xflags from the underlying fs with a new --preserve-xflags= option. Maybe it should be --preserve-dest-xflags to make it clear that the xflags of the destination are overriding the dump. For your "create dump on non-rt fs and restore to rt dev on rt fs" use case, you'd do.... # xfsdump -f /dumpfile /oldfs # mkfs.xfs -r rtdev=/dev/sdX -d rtinherit=1 /dev/sdY # mount /dev/sdY /newfs # xfsrestore -f /dumpfile --preserve-dest-xflags=t /newfs --D > Thanks! > > > --D > > > > > > *nod* > > > > > > > > > Now: do we need to do the same for all inheritable flags? projid, > > > > > extsize, etc? I think we probably do. > > > > > > > > I disagree. These things are all supported on all destination > > > > filesystems, unlike the rtdev. They are also things that can be > > > > changed after the fact, unlike rtdev allocation policy. i.e. rtdev > > > > has to be set /before/ restore, just about everything else can be > > > > set or reset after the fact.... > > > > Cheers, > > > > > > > > Dave. > > > > -- > > > > Dave Chinner > > > > david@xxxxxxxxxxxxx
