| Message ID | 160013420779.2923511.9462939883966946313.stgit@magnolia (mailing list archive) |
|---|---|
| State | Deferred, archived |
| Headers | show |
| Series | fstests: tons of random fixes | expand |
On Mon, Sep 14, 2020 at 06:43:27PM -0700, Darrick J. Wong wrote: > From: Darrick J. Wong <darrick.wong@oracle.com> > > mkfs.xfs does not support setting rtinherit on the root directory /and/ > pre-populating the filesystem with protofiles, so don't run this test if > rtinherit is in the mkfs options. That is a bit of a weird limitation. Any reason we can't fix this in mkfs instead?
On Thu, Sep 17, 2020 at 08:53:51AM +0100, Christoph Hellwig wrote: > On Mon, Sep 14, 2020 at 06:43:27PM -0700, Darrick J. Wong wrote: > > From: Darrick J. Wong <darrick.wong@oracle.com> > > > > mkfs.xfs does not support setting rtinherit on the root directory /and/ > > pre-populating the filesystem with protofiles, so don't run this test if > > rtinherit is in the mkfs options. > > That is a bit of a weird limitation. Any reason we can't fix this in > mkfs instead? Userspace doesn't implement the rt allocator at all, and the last few times I've tried to do any serious surgery in the protofile code, Dave grumbled that we should just kill it off instead. Do people actually /use/ protofile support? Do they like it? Or would they rather have an option like mke2fs -D, where you point it at a directory and it uses ftw to copy-in all the files in that directory tree, attributes and all? (I guess I could propose deprecating it and see who pops out. :P) --D
On Thu, Sep 17, 2020 at 08:57:47AM -0700, Darrick J. Wong wrote: > On Thu, Sep 17, 2020 at 08:53:51AM +0100, Christoph Hellwig wrote: > > On Mon, Sep 14, 2020 at 06:43:27PM -0700, Darrick J. Wong wrote: > > > From: Darrick J. Wong <darrick.wong@oracle.com> > > > > > > mkfs.xfs does not support setting rtinherit on the root directory /and/ > > > pre-populating the filesystem with protofiles, so don't run this test if > > > rtinherit is in the mkfs options. > > > > That is a bit of a weird limitation. Any reason we can't fix this in > > mkfs instead? > > Userspace doesn't implement the rt allocator at all, and the last few > times I've tried to do any serious surgery in the protofile code, Dave > grumbled that we should just kill it off instead. Maybe killing it off is indeed the better option. And in that case this patch to disable it for RT devices would be a good start. > > Do people actually /use/ protofile support? Do they like it? Or would > they rather have an option like mke2fs -D, where you point it at a > directory and it uses ftw to copy-in all the files in that directory > tree, attributes and all? I always found the protofile stuff really weird and not actually useful. mke2fs -D actually does seem useful if you want to generate an xfs file systems and fill it without having admin privileges. I think that is what the mke2fs feature is used for.
diff --git a/tests/xfs/019 b/tests/xfs/019 index f42b62bb..aa5365e7 100755 --- a/tests/xfs/019 +++ b/tests/xfs/019 @@ -51,6 +51,11 @@ _supported_os Linux _require_scratch +# mkfs cannot create a filesystem with protofiles if realtime is enabled, so +# don't run this test if the rtinherit is anywhere in the mkfs options. +echo "$MKFS_OPTIONS" | grep -q "rtinherit" && \ + _notrun "Cannot mkfs with a protofile and -d rtinherit." + protofile=$tmp.proto tempfile=$tmp.file diff --git a/tests/xfs/031 b/tests/xfs/031 index 6403fd40..671b6727 100755 --- a/tests/xfs/031 +++ b/tests/xfs/031 @@ -81,6 +81,11 @@ _supported_os Linux _require_scratch _require_no_large_scratch_dev +# mkfs cannot create a filesystem with protofiles if realtime is enabled, so +# don't run this test if the rtinherit is anywhere in the mkfs options. +echo "$MKFS_OPTIONS" | grep -q "rtinherit" && \ + _notrun "Cannot mkfs with a protofile and -d rtinherit." + # sanity test - default + one root directory entry # Note: must do this proto/mkfs now for later inode size calcs _create_proto 0