On Wed, Feb 25, 2015 at 06:31:15PM -0500, Brian Foster wrote: > On Thu, Feb 26, 2015 at 09:32:48AM +1100, Dave Chinner wrote: > > [cc linux-fsdevel, Boaz and others] > > > > On Wed, Feb 25, 2015 at 11:11:51AM -0500, Brian Foster wrote: > > > On Wed, Feb 25, 2015 at 09:54:36AM +1100, Dave Chinner wrote: > > > > From: Dave Chinner <dchinner@xxxxxxxxxx> > > > > > > > > xfs/104, xfs/119, xfs/291 and xfs/297 have small fixed log sizes. A > > > > recent change to the kernel ramdisk changed it's physical sector > > > > size from 512B to 4kB, and this results in mkfs calculating a log > > > > size larger than the fixed test size and hence the tests fail. > > > > > > > > Change the log size to a larger size that works with 4k sectors, and > > > > also increase the size of the filesystem being created so that the > > > > amount of data space in the filesystem does not change and hence > > > > does not perturb the rest of the test. > > > > > > > > Signed-off-by: Dave Chinner <dchinner@xxxxxxxxxx> > > > > --- > > > > > > Well for some reason I can't mount a ramdisk on the current tot to test > > > this. In fact, I can't mount _anything_ after the ramdisk mount attempt. > > > The mount actually reports success too, but there's nothing there... :/ > > > > > > # modprobe brd > > > # mkfs.xfs -f /dev/ram0 > > > meta-data=/dev/ram0 isize=256 agcount=1, agsize=4096 > > > blks > > > = sectsz=4096 attr=2, projid32bit=1 > > > = crc=0 finobt=0 > > > data = bsize=4096 blocks=4096, imaxpct=25 > > > = sunit=0 swidth=0 blks > > > naming =version 2 bsize=4096 ascii-ci=0 ftype=0 > > > log =internal log bsize=4096 blocks=1605, version=2 > > > = sectsz=4096 sunit=1 blks, lazy-count=1 > > > realtime =none extsz=4096 blocks=0, rtextents=0 > > > # mount /dev/ram0 /mnt/ > > > # mount | grep mnt > > > # umount /mnt/ > > > umount: /mnt/: not mounted > > > > > > ... and then I can't even mount my normal scratch device until after a > > > reboot: > > > > > > # mount /dev/test/scratch /mnt/ > > > # mount | grep mnt > > > # umount /mnt/ > > > umount: /mnt/: not mounted > > > > Ok, so that's just plain broken. What's in dmesg? > > > > Once I got back to this I found that for some reason systemd is > immediately invoking a umount on the mount. :/ No idea why or how to > stop it, but if I do something like this: > > mount /dev/ram0 /mnt; cd /mnt > > ... I can occasionally win the race and get systemd to spin in a > umount() cycle trying to undo the mount. I haven't gone back to confirm > it's the same behavior with the normal devices at that point, but I > suspect it is, perhaps due to getting into some kind of bad state. > > So fyi that this particular problem doesn't appear to be directly kernel > related... It may still be related to the kernel changes e.g. by triggering udev events when they didn't previously. The only machine I have that is triggering the partition probing is also the only test machine that I have that runs systemd and it didn't have this problem on 3.19. Cheers, Dave. -- Dave Chinner david@xxxxxxxxxxxxx -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
