On Tue, Oct 29, 2019 at 08:29:38AM +0800, Ian Kent wrote: > On Mon, 2019-10-28 at 16:34 -0700, Darrick J. Wong wrote: > > On Mon, Oct 28, 2019 at 05:17:05PM +0800, Ian Kent wrote: > > > Hi Darrick, > > > > > > Unfortunately I'm having a bit of trouble with my USB keyboard > > > and random key repeats, I lost several important messages this > > > morning due to it. > > > > > > Your report of the xfstests generic/361 problem was one of them > > > (as was Christoph's mail about the mount code location, I'll post > > > on that a bit later). So I'm going to have to refer to the posts > > > and hope that I can supply enough context to avoid confusion. > > > > > > Sorry about this. > > > > > > Anyway, you posted: > > > > > > "Dunno what's up with this particular patch, but I see regressions > > > on > > > generic/361 (and similar asserts on a few others). The patches > > > leading > > > up to this patch do not generate this error." > > > > > > I've reverted back to a point more or less before moving the mount > > > and super block handling code around and tried to reproduce the > > > problem > > > on my test VM and I din't see the problem. > > > > > > Is there anything I need to do when running the test, other have > > > SCRATCH_MNT and SCRATCH_DEV defined in the local config, and the > > > mount point, and the device existing? > > > > Um... here's the kernel branch that I used: > > > > https://git.kernel.org/pub/scm/linux/kernel/git/djwong/xfs-linux.git/log/?h=mount-api-crash > > Ok, I'll see what I can do with that. > > > > > Along with: > > > > MKFS_OPTIONS -- -m crc=0 > > Right. > > > MOUNT_OPTIONS -- -o usrquota,grpquota > > It looked like generic/361 used only the SCRATCH_DEV so I thought > that meant making a file system and mounting it within the test. Yes. MOUNT_OPTIONS are used to mount the scratch device (and in my case the test device too). > > and both TEST_DEV and SCRATCH_DEV pointed at boring scsi disks. > > My VM disks are VirtIO (file based) virtual disks, so that sounds > a bit different. > > Unfortunately I can't use raw disks on the NAS I use for VMs and > I've migrated away from having a desktop machine with a couple of > disks to help with testing. > > I have other options if I really need to but it's a little bit > harder to setup and use company lab machines remotely, compared to > local hardware (requesting additional disks is hard to do), and > I'm not sure (probably not) if they can/will use raw disks (or > partitions) either. Sorry, I meant 'boring SCSI disks' in a VM. Er let's see what the libvirt config is... <disk type='file' device='disk'> <driver name='qemu' type='raw' cache='unsafe' discard='unmap'/> <source file='/run/mtrdisk/a.img'/> <target dev='sda' bus='scsi'/> <address type='drive' controller='0' bus='0' target='0' unit='0'/> </disk> Which currently translates to virtio-scsi disks. > > > > > This could have been a problem with the series I posted because > > > I did have some difficulty resolving some conflicts along the > > > way and may have made mistakes, hence reverting to earlier patches > > > (but also keeping the recent small pre-patch changes). > > > > Yeah, I had the same problem too; you might spot check the commits in > > there just in case /I/ screwed them up. > > I will, yes. > > > > > (I would say 'or rebase on for-next' but (a) I don't know how > > Christoph's mount cleanups intermix with that and (b) let's see if > > this afternoon's for-next is less broken on s390 than this morning's > > was > > <frown>) > > I neglected to mention that my series is now based on the for-next > branch as I noticed the get_tree_bdev() fix is present so I can drop > the first patch. > > It seemed to me that the for-next branch is the right place to base > the series. I expect there will be the odd bump in the road of course > ... Heh. Yes. :) --D > Ian >
