Re: ramdisk problems in 4.0-rc1? (was Re: [PATCH 1/4] xfs/104: log size too small for 4k sector drives)

[Dave Chinner <david@fromorbit.com>]

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@redhat.com>
> > > > 
> > > > 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@redhat.com>
> > > > ---
> > > 
> > > 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@fromorbit.com