On Thu, Nov 28, 2013 at 11:00:34AM +0100, Arkadiusz Bubała wrote: > Hello, > thank you for valuable information. > > On 28.11.2013 00:06, Dave Chinner wrote: > > > >>Running a custom built 3.4.63 kernel with a bunch of out of tree > >>modules installed. can you reproduce this on a vanilla 3.12 kernel? > >> > Ok, we'll try. > > >The script is full of bugs, and i don't have time to debug it - it > >hard codes /dev/sda in places despite taking the device as a CLI > >parameter. It has hard coded mount points. It sometimes fails to > >make the filesystem on the base LV after it's been created. > >start_snap() appears to fail for some reason, as it doesn't result > >in mounted snapshots. stop_snap fails as well: > > > >Starting snap19 : Thursday 28 November 10:01:26 EST 2013 > > Logical volume lv1+snap19 converted to snapshot. > >[ FAIL ] Can't umount snapshot > >[ FAIL ] Can't remove snapshot > >[ FAIL ] Can't umount snapshot > >[ FAIL ] Can't remove snapshot > >[ FAIL ] Can't umount snapshot > >[ FAIL ] Can't remove snapshot > >[ FAIL ] Can't umount snapshot > >[ FAIL ] Can't remove snapshot > >[ FAIL ] Can't umount snapshot > >[ FAIL ] Can't remove snapshot > >[ FAIL ] Can't umount snapshot > >[ FAIL ] Can't remove snapshot > >[ FAIL ] Can't umount snapshot > >[ FAIL ] Can't remove snapshot > >[ OK ] lv1+snap19 activated. > >Starting time : 37 s. > >--------------------------- > >Stopping snap0 : Thursday 28 November 10:02:06 EST 2013 > >[ FAIL ] Can't umount snapshot > >[ FAIL ] Can't remove snapshot > >[ FAIL ] lv0+snap00 still active !!! > >[ OK ] lv0+snap00 umounted. > >Stopping time : 0 s. > > > >I've got no idea is this is intended behaviour, but it sure doesn't > >seem right to me... > > > > > Yes, sometimes umount and remove operations fail. They always fail here - snapshots are not being mounted at all (nothing in dmesg about XFS filesystems being mounted during the test at all), so the test does not appear to be doing what you expect to be doing... > This script tests > system stability and these messages are debug info only. It ran overnight on a TOT 3.13-rc1 kernel with memory leak and poisoning turned on, issuing those fail messages and nothing broke... > I've fixed it. Now it takes two parameters: device and mount point. I'll try it again... Cheers, Dave. -- Dave Chinner david@xxxxxxxxxxxxx _______________________________________________ xfs mailing list xfs@xxxxxxxxxxx http://oss.sgi.com/mailman/listinfo/xfs
