Re: [PATCH 0/2][RESEND] scsi_transport_fc: LUN masking
On 03/02/2016 03:54 AM, Ewan Milne wrote: > On Tue, 2016-02-23 at 18:21 +0800, Hannes Reinecke wrote: >> On 02/22/2016 07:39 PM, Seymour, Shane M wrote: >>> Hi Hannes, >>> >>> How do you know that a request for an async scan is complete (I'm assuming >>> that you get add or change udev events)? Assuming that someone has manually >>> started a scan on something (e.g. some newly presented devices after boot) >>> and all scans are going to be async how do you know when it is complete >>> rather than waiting in a work queue? An example may be a sysfs >>> file that contains unscanned, pending, scanning, scanned so you know >>> when it's complete at the appropriate level in sysfs (the hba and the >>> rports) >>> so you know when can continue if you're polling the status (e.g. checking >>> as part of system admin work with newly >>> presented rports so you can then do something with them). >>> >> Thing is, I don't. >> >> We have had a similar discussion with the IBM zfcp folks, that it would >> be desirable to have a marker in sysfs telling us that the rport is >> stable (ie no scanning in progress). >> However, this cannot be at the rport level (as the rport itself might be >> going away), but rather at some higher level (eg fc_host). > > I am not sure this really helps. If another process initiates a scan > then sysfs might report that the scanning was still in progress. If > scans are initiated often enough, you might never observe a stable state. > True. Which is one of the reasons why this particular item hasn't made any progress yet. Cheers, Hannes -- Dr. Hannes Reinecke zSeries & Storage h...@suse.de +49 911 74053 688 SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg GF: J. Hawn, J. Guild, F. Imendörffer, HRB 16746 (AG Nürnberg) -- To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/2][RESEND] scsi_transport_fc: LUN masking
On Tue, 2016-02-23 at 18:21 +0800, Hannes Reinecke wrote: > On 02/22/2016 07:39 PM, Seymour, Shane M wrote: > > Hi Hannes, > > > > How do you know that a request for an async scan is complete (I'm assuming > > that you get > > add or change udev events)? Assuming that someone has manually started a > > scan on something > > (e.g. some newly presented devices after boot) and all scans are going > to be async how > > do you when it is complete rather than waiting in a work queue? An > example may be a sysfs > > file that contains unscanned, pending, scanning, scanned so you know > when it's complete > > at the appropriate level in sysfs (the hba and the rports) so you know > when can continue > > if you're polling the status (e.g. checking as part of system admin > work with newly > > presented rports so you can then do something with them). > > > Thing is, I don't. > > We have had a similar discussion with the IBM zfcp folks, that it would > be desirable to have a marker in sysfs telling us that the rport is > stable (ie no scanning in progress). > However, this cannot be at the rport level (as the rport itself might be > going away), but rather at some higher level (eg fc_host). I am not sure this really helps. If another process initiates a scan then sysfs might report that the scanning was still in progress. If scans are initiated often enough, you might never observe a stable state. > > But this has nothing to do with the patchset, right? > We're just disabling the (existing) scan callback, and retrigger it once > the sysfs attribute has been cleared. > > We don't change the behaviour during scanning with this patchset. > > Cheers, > > Hannes -- To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH 0/2][RESEND] scsi_transport_fc: LUN masking
> But this has nothing to do with the patchset, right? Correct. -- To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/2][RESEND] scsi_transport_fc: LUN masking
On 02/22/2016 07:39 PM, Seymour, Shane M wrote: > Hi Hannes, > > How do you know that a request for an async scan is complete (I'm assuming > that you get > add or change udev events)? Assuming that someone has manually started a scan > on something > (e.g. some newly presented devices after boot) and all scans are going to be async how > do you when it is complete rather than waiting in a work queue? An example may be a sysfs > file that contains unscanned, pending, scanning, scanned so you know when it's complete > at the appropriate level in sysfs (the hba and the rports) so you know when can continue > if you're polling the status (e.g. checking as part of system admin work with newly > presented rports so you can then do something with them). > Thing is, I don't. We have had a similar discussion with the IBM zfcp folks, that it would be desirable to have a marker in sysfs telling us that the rport is stable (ie no scanning in progress). However, this cannot be at the rport level (as the rport itself might be going away), but rather at some higher level (eg fc_host). But this has nothing to do with the patchset, right? We're just disabling the (existing) scan callback, and retrigger it once the sysfs attribute has been cleared. We don't change the behaviour during scanning with this patchset. Cheers, Hannes -- Dr. Hannes Reinecke zSeries & Storage h...@suse.de +49 911 74053 688 SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg GF: J. Hawn, J. Guild, F. Imendörffer, HRB 16746 (AG Nürnberg) -- To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH 0/2][RESEND] scsi_transport_fc: LUN masking
Hi Hannes, How do you know that a request for an async scan is complete (I'm assuming that you get add or change udev events)? Assuming that someone has manually started a scan on something (e.g. some newly presented devices after boot) and all scans are going to be async how do you when it is complete rather than waiting in a work queue? An example may be a sysfs file that contains unscanned, pending, scanning, scanned so you know when it's complete at the appropriate level in sysfs (the hba and the rports) so you know when can continue if you're polling the status (e.g. checking as part of system admin work with newly presented rports so you can then do something with them). Thanks Shane > -Original Message- > From: linux-scsi-ow...@vger.kernel.org [mailto:linux-scsi- > ow...@vger.kernel.org] On Behalf Of Hannes Reinecke > Sent: Monday, February 22, 2016 6:51 PM > To: Martin K . Petersen > Cc: Christoph Hellwig; James Bottomley; Johannes Thumshirn; linux- > s...@vger.kernel.org; Hannes Reinecke > Subject: [PATCH 0/2][RESEND] scsi_transport_fc: LUN masking > > Hi all, > > having been subjected to the pain of trying to bootstrap a really large > machine with systemd I decided to implement LUN masking in > scsi_transport_fc. > The principle is simple: disallow the automated LUN scanning when > discovering a rport, and create udev rules which selectively enable individual > LUNs by echoing the relevant values in the 'scan' > attribute of the SCSI host. > With that I'm able to boot an arbitrary large machine without running into any > udev or systemd imposed timeout. > To _disable_ LUN masking and restoring the original behaviour I've noticed > that the 'scan' sysfs attribute is actually synchronous, ie the calling > process > will be blocked until the entire LUN scan is completed. > So I've added another module parameter 'async_user_scan' to move the > scanning onto the existing scan workqueue, and unblock the calling process. > > As usual, comments and reviews are welcome. > > Hannes Reinecke (2): > scsi_transport_fc: implement 'disable_target_scan' module parameter > scsi_transport_fc: Implement 'async_user_scan' module parameter > > drivers/scsi/scsi_transport_fc.c | 47 > +--- > 1 file changed, 44 insertions(+), 3 deletions(-) > > -- > 2.6.2 > > -- > To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the > body of a message to majord...@vger.kernel.org More majordomo info at > http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
