On Thu, Mar 01, 2012 at 09:46:07PM -0600, Eric Sandeen wrote:
> On 3/1/12 6:15 PM, Dave Chinner wrote:
> > On Thu, Mar 01, 2012 at 05:27:13PM -0600, Eric Sandeen wrote:
> >> + _get_sector_size | tee -a $seq.full
> >> + device=`echo $@ | awk '{print $NF}'`
> >> + _wipe_device $device
> >
> > Not sure what this is supposed to do. The awk statement prints the
> > number of fields in the input record, and _wipe_device uses that as
> > a file name? What am I missing?
>
> that '{print $NF}' prints the last field...
/me slaps forehead. NF and $NF give different things..
> >> +# Functions useful for tests on unique block devices
> >> +#
> >> +
> >> +_require_scsi_debug()
> >> +{
> >> + # make sure we have the module and it's not already used
> >> + modinfo scsi_debug 2>&1 > /dev/null || _notrun "scsi_debug module not found"
> >> + lsmod | grep -wq scsi_debug && _notrun "scsi_debug module in use"
> >> + # make sure it has the features we need
> >> + # logical/physical sectors plus unmap support all went in together
> >> + modinfo scsi_debug | grep -wq sector_size || _notrun "scsi_debug too old"
> >> +}
> >
> > Might work for modules, but what about CONFIG_SCSI_DEBUG=y? I
> > thought you could do all this configuration stuff through the
> > /sys/bus/scsi/drivers/scsi_debug interface so you didn't need to
> > screw with modules and parameters?
>
> sigh, have to handle them both I suppose.
Actaully, having looked at this, don't bother. Just use the module
version. Adding CONFIG_SCSI_DEBUG=y makes your system fail to boot
if you have /dev/sdaX entries as your boot device. The scsi debug
device becomes /dev/sda, and funnily enough stuff stops working
because /dev/sda2 isn't the root filesystem anymore...
> >> +_put_scsi_debug_dev()
> >> +{
> >> + sleep 1
> >> + rmmod scsi_debug || _fail "Could not remove scsi_debug module"
> >> +}
> >
> > What is the sleep for?
>
> Module stays busy w/o it and the rmmod fails, not sure why offhand....
> which probably makes it not very robust :)
Hmmm. We don't have any active references to it after mkfs exists.
Seems kind of strange. I've seen similar things with blkid running
probes in the background due to udev events when the device is first
created. Given that we are just running a mkfs on it, the lifetime
of the device is under a second, right? Perhaps adding a udev_settle
call after doing the modprobe might solve this....
Cheers,
Dave.
--
Dave Chinner
david@xxxxxxxxxxxxx
_______________________________________________
xfs mailing list
xfs@xxxxxxxxxxx
http://oss.sgi.com/mailman/listinfo/xfs
