On Sun, Sep 02, 2018 at 10:05:29PM +0800, Eryu Guan wrote: > On Sun, Sep 02, 2018 at 12:13:26AM -0500, Eric Sandeen wrote: > > > > > > On 9/1/18 11:03 PM, Ernesto A. Fernández wrote: > > > On Sun, Sep 02, 2018 at 01:09:57AM +0800, Eryu Guan wrote: > > >> On Fri, Aug 31, 2018 at 11:05:03PM -0300, Ernesto A. Fernández wrote: > > >>> It is not possible to set file system size when running mkfs.hfsplus, > > >>> so use the device mapper as a workaround. > > >> > > >> I'd prefer _notrun the test in _scratch_mkfs_sized() instead of this > > >> workaround, as the harness is expecting to operate $SCRATCH_DEV but this > > >> workaround may break this assumption in subtle ways, e.g. now > > >> _check_scratch_fs fails to create hfsplus-tmp device because > > >> $SCRATCH_DEV may still be mounted. > > > > > > I didn't realize $SCRATCH_DEV could still be mounted, sorry. Maybe I can > > > unmount it before _dmsetup_create(), and remount after _dmsetup_remove()? > > > Like _check_generic_filesystem() does. Or would that bring other problems? > > I haven't seen other problems yet (after just a few simple test runs), > but I suspect it may break tests in more subtle ways, the > _check_scratch_fs failure is just an example. And even it works for now, > and we have to worry about making it continue to work when adding new > features in the future and that's a maintaining burden we'd better to > avoid. Ah, I just replied on the -fsdevel thread saying exactly this.... > > > I know it's ugly, but one test that uses _scratch_mkfs_sized() has helped > > > me find a number of bugs already. It would be really useful to get it to > > > work. > > > > Has anyone proposed a patch to mkfs.hfsplus to accept a filesystem size? > > I'd expect that might be less complicated than this sort of devicemapper > > setup ;) > > Yeah, this would be the best way to let _scratch_mkfs_sized() support > hfsplus :) .... and this, too. :) It'll be easy to add a mkfs option check in _scratch_mkfs_sized() for hfsplus. That should make it work (or not run, as the case may be) reliably into the future, too. Cheers, Dave. -- Dave Chinner david@xxxxxxxxxxxxx
