On 6/6/19 1:12 PM, Sheena Artrip wrote: > On Thu, Jun 6, 2019 at 7:11 AM Eric Sandeen <sandeen@xxxxxxxxxxx> wrote: >> >> On 6/5/19 4:16 PM, Sheena Artrip wrote: >>> When running xfs_restore with a non-rtdev dump, >>> it will ignore any rtinherit flags on the destination >>> and send I/O to the metadata region. >>> >>> Instead, detect rtinherit on the destination XFS fileystem root inode >>> and use that to override the incoming inode flags. >>> >>> Original version of this patch missed some branches so multiple >>> invocations of xfsrestore onto the same fs caused >>> the rtinherit bit to get re-removed. There could be some >>> additional edge cases in non-realtime to realtime workflows so >>> the outstanding question would be: is it worth supporting? >> >> Hm, interesting. >> >> So this is a mechanism to allow dump/restore to migrate everything >> to the realtime subvol? I can't decide if I like this - normally I'd >> think of an xfsdump/xfsrestore session as more or less replicating the >> filesystem that was dumped, and not something that will fundamentally >> change what was dumped. >> >> OTOH, we can restore onto any dir we want, and I could see the argument >> that we should respect things like the rtinherit flag if that's what >> the destination dir says. > > Yes. What is strange is that an xfsrestore onto a rtdev system will > silently "fill" from a filesystem that previously did not have rt files, I guess? > the metadata partition until the available inode count goes to zero and we get > an ENOSPC. Not yet sure if the file data goes straight to the metadata partition > or if it's simply accounting for it in the metadata partition. > > I'm guessing xfsrestore should either fail-fast or allow this via > rtinherit detection. I don't mind putting it behind a flag either. Hm, can you more completely describe the usecase/testcase that leads to the problem? I just want to make sure I have the whole picture. >> One thing about the patch - the mechanism you've copied to get the root >> inode number via bulkstat turns out to be broken ... it's possible >> to have a non-root inode with the lowest number on the fs, unfortunately. > > I think i saw that on the list but this code is also a near-identical > copy of what is in xfsdump/content.c. yeah that's my mistake to fix now ;) >> But, wouldn't you want to test the rtinherit flag on the target dir anyway, >> not necessarily the root dir? > > Makes sense. How would I get the rtinherit flag on the target dir? Is there > a xfs-specific stat function that will give us a xfs_bstat_t for the > dstdir inode > I've opened or is it already part of stat64_t? it's available via the FS_IOC_FSGETXATTR ioctl: # xfs_io -c "chattr +t" mnt/rtdir # strace -e ioctl xfs_io -c lsattr mnt/rtdir ioctl(3, _IOC(_IOC_READ, 0x58, 0x7c, 0x70), 0x7ffd4cab44c0) = 0 ioctl(3, FS_IOC_FSGETXATTR, 0x7ffd4cab45a0) = 0 -------t-------- mnt/rtdir -Eric
