On Mon, 2019-10-28 at 17:52 -0700, Darrick J. Wong wrote: > 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. I could use the scsi driver for the disk I guess but IO is already a bottleneck for me. For my VM disks I have: <disk type='file' device='disk'> <driver name='qemu' type='qcow2' cache='writeback'/> <source file='/share/VS-VM/images/F30 test/F30 test_2.1565610215' startupPolicy='optional'/> <target dev='vdc' bus='virtio'/> <address type='pci' domain='0x0000' bus='0x00' slot='0x08' function='0x0'/> </disk> I'm pretty much restricted to cow type VM disks if I don't do some questionable manual customization to the xml, ;) In any case the back trace you saw looks like it's in the mount/VFS code so it probably isn't disk driver related. I'll try and reproduce it with a checkout of you branch above. > > > > > 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 > >
