On Tue, Dec 17, 2024 at 5:22 PM Darrick J. Wong <djwong@xxxxxxxxxx> wrote: > > On Tue, Dec 17, 2024 at 08:26:33AM +0000, Filipe Manana wrote: > > On Tue, Dec 17, 2024 at 8:14 AM Christoph Hellwig <hch@xxxxxxxxxxxxx> wrote: > > > > > > On Wed, Dec 11, 2024 at 03:09:40PM +0000, fdmanana@xxxxxxxxxx wrote: > > > > The test also fails sporadically on xfs and the bug was already reported > > > > to the xfs mailing list: > > > > > > > > https://lore.kernel.org/linux-xfs/CAL3q7H7cURmnkJfUUx44HM3q=xKmqHb80eRdisErD_x8rU4+0Q@xxxxxxxxxxxxxx/ > > > > > > > > > > This version still doesn't seem to have the fs freeze/unfreeze that Darrick > > > asked for in that thread. > > > > I don't get it, what's the freeze/unfreeze for? Where should they be placed? > > Is it some way to get around the bug on xfs? > > freeze kicks the background inode gc thread so that the unlinked clones > actually get freed before the swapon call. A less bighammer idea might > be to call XFS_IOC_FREE_EOFBLOCKS which also kicks the garbage > collectors. No matter the technical details that make the bug not so easy to fix on xfs, adding calls to freeze/unfreeze, XFS_IOC_FREE_EOFBLOCKS, or whatever else, is just a way to hide the bug on xfs, isn't it? If the file has no more shared extents, swap activation should work. Thanks. > > --D
