Re: [patch 1/3] wait host devs in base module

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Mon, Aug 20, 2012 at 01:53:49PM +0800, Dave Young wrote:
> On 08/18/2012 12:57 AM, Vivek Goyal wrote:
> 
> > On Fri, Aug 17, 2012 at 08:35:20PM +0800, dyoung@xxxxxxxxxx wrote:
> >> each dev in host_devs[] should be waited in initqueue to make sure they
> >> are oneline before initqueue finish.
> >>
> >> Add a new wait_host_devs.sh in base module to make this a generic thing.
> >> Because all the devs in fstab lines are also added to host_devs, so no need
> >> do same wait in fstab-sys module anymore.
> >>
> >> Chaowang: add slave devices to host_devs as well.
> > 
> > Why should we wait for slave devices? If slave device does not come up,
> > top level device will not come up anyway. So I don't think we should wait
> > for slave devices.
> 
> 
> Yes, agree. Adding the slaves is only for patch 2/3, ie. is_scsi with
> for_each_host_dev. I think I do not fully understand the relations
> beteen the master and slave devices of iscsi/multipath/etc.
> 
> 
> > 
> > Secondly, trying to list slave devices is dangerous as the names you
> > seem to be stroing are not persistent and device renaming will hang
> > the system.
> > 
> > So whereever you are waiting for a device to come up, make sure you
> > are using persistent device name as generated by udev.
> 
> 
> Agree too, this is a problem. Looking at the fstab-sys
> wait_mount_dev.sh, there's same issue if the dev name in fstab is not
> the "persistent device name"

Non persistent names in /etc/fstab will not make sense as system will
be broken across reboots. So it is a requirement to put persistent
names only in /etc/fstab.

I think last time I did partial patch to wait for device nodes. But we
still need mechanism to convert UUID= and LABEL= into respective
persistent device names. Can you please take care of that too while you
are at it.

Thanks
Vivek
--
To unsubscribe from this list: send the line "unsubscribe initramfs" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[Index of Archives]     [Linux Kernel]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite News]     [Linux SCSI]

  Powered by Linux