All of lore.kernel.org
 help / color / mirror / Atom feed
From: Hannes Reinecke <hare@suse.de>
To: "Jeremy Linton" <jlinton@tributary.com>,
	"\"Kai Mäkisara (Kolumbus)\"" <kai.makisara@kolumbus.fi>
Cc: James Bottomley <jbottomley@parallels.com>,
	Kay Sievers <kay@vrfy.org>,
	"linux-scsi@vger.kernel.org" <linux-scsi@vger.kernel.org>,
	Doug Gilbert <dgilbert@interlog.com>
Subject: Re: [PATCH] st: Do not rewind for SG_IO
Date: Mon, 03 Feb 2014 16:06:20 +0100	[thread overview]
Message-ID: <52EFB06C.8010101@suse.de> (raw)
In-Reply-To: <52EFACA4.6060001@tributary.com>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 02/03/2014 03:50 PM, Jeremy Linton wrote:
> On 2/2/2014 5:42 AM, Hannes Reinecke wrote:
>> This is due to the strictly sequential design udev has.
>> Essentially udev spawns a worker for every device which gets
>> created (= udev receives a uevent for).
>  The part I fail to see in this explanation is why the
> nst/st/st*a/st*m/etc handles are being treated as separate
> devices. They aren't. They are all the same physical tape
> device, so why are the nst devices being handled separately 
> from the st ones?
> 
That's due to udev.
Udev is getting events for each device it should create a device
node for.
So for 'st' it'll get a series of events for 'stX', and another
series of
events for 'nstX'.
Udev will treat each of these events separately, with distinct worker
programs handling them. Each of those workers run fully asynchronous
and cannot access information from other workers.
Udev cannot and should not make assumptions about any correlations
between events; if you need this then you have to explicitly gate
events via the 'collect' mechanism.
But even then you can only access information from the currently
running
process/event; you cannot modify information from prior events.

So when trying to generate unique IDs for tape devices you either
have to

a) modify the program generating the Unique ID to redirect the call
   to a different device node
or

b) to modify the driver to not rewind the tape

We tried approach a) when using the scsi_id program. But as this
program
is rather old and doesn't have a maintainer I'm working on using
'sg_inq' as a replacement. And these kind of hacks really do not
belong in a generic program.
(It would involve create a temporary device node, call SG_IO on
that, and remove the temporary device node again).
So now we're shooting for b).

Unless you have a better idea ...

Cheers,

Hannes
- -- 
Dr. Hannes Reinecke		      zSeries & Storage
hare@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)
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.19 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIcBAEBAgAGBQJS77BsAAoJEGz4yi9OyKjPQz8P/1cY+k9KtEezXC2ovuzJmy9T
BjQaoxcTgHbaXykFyEoJeiNQ09XrjAl7IlVOOF9jX3XqC4kYQiBZCThUnC8O3D69
vaZrA6+VR9AoTXbfNzBUdHzEKWTlz5X2ThLzrLPogXS6v5hiw0iBcLq5mvlJxlkc
DBHJrV+ujlKOM/JibNwUNldeYAFnrrzCCH50arJ/Eqa6BcLZ2uXTksACqIVybUoI
nW1yfVzJdsxI5YwPp0N5bnuAPIg3N7zBTcFCVYqTHUiAmrS4HYkHRrC501yuopCA
PS9Gv1KznctEIGudoP5S0Lwn+g/aVSuzOTpo3uUWAa1BNyyvRMRUSzSIUfm2WdAj
+o1mswhhX6NZMM9rFrM35dbiky2Nv/pvc2zcD4pvizsLiHkoQER7GQ9FCaBNXP7d
eK0OF2jJeEPV6LSC97wxH27Vybv/c89wp0HGDaJc+kd8+WZFIvkLbvY7K3BSA2ut
YvuebI59veIYNZEJVEdAGYQ3IEUG8uukbdpqf3Kdr17PQEms/gTW+xYWPo1+hBR7
V58ojgghBxPdVwGRyiSgKgjY/vHLFunm9H83LDrHKdQsKs8JGiTCflPhJEMwwsDo
mhlmd5Ihw20Cyh46sd3Uu1onH0L5Rg0hfDqT913ShUFYi5Y+XvtHEezYn73OxYDr
JoUo9HYfT843MabEympC
=c45s
-----END PGP SIGNATURE-----
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

  reply	other threads:[~2014-02-03 15:06 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-01-31  8:46 [PATCH] st: Do not rewind for SG_IO Hannes Reinecke
2014-01-31 16:36 ` Jeremy Linton
2014-01-31 16:43 ` Jeremy Linton
2014-02-01 14:06   ` Hannes Reinecke
2014-02-01 15:23     ` "Kai Mäkisara (Kolumbus)"
2014-02-02 11:42       ` Hannes Reinecke
2014-02-02 19:15         ` "Kai Mäkisara (Kolumbus)"
2014-02-03  6:55           ` Hannes Reinecke
2014-02-03 14:50         ` Jeremy Linton
2014-02-03 15:06           ` Hannes Reinecke [this message]
2014-02-03 15:08             ` Jeremy Linton
2014-02-03 20:51               ` Kay Sievers
2014-02-03 21:11                 ` James Bottomley
2014-02-03 21:58                 ` Jeremy Linton
2014-02-03 22:15                   ` Kay Sievers
2014-02-03 22:26                     ` Jeremy Linton
2014-02-06 13:10                   ` Hannes Reinecke
2014-02-06 13:21                     ` Martin K. Petersen
2014-02-06 13:26                       ` Hannes Reinecke
2014-02-06 13:50                         ` Martin K. Petersen
2014-02-06 14:38                           ` James Bottomley
2014-02-06 15:13                             ` Hannes Reinecke
2014-02-06 19:21                               ` Douglas Gilbert
2014-02-03 21:16               ` Douglas Gilbert
2014-02-03 21:24                 ` Kay Sievers

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=52EFB06C.8010101@suse.de \
    --to=hare@suse.de \
    --cc=dgilbert@interlog.com \
    --cc=jbottomley@parallels.com \
    --cc=jlinton@tributary.com \
    --cc=kai.makisara@kolumbus.fi \
    --cc=kay@vrfy.org \
    --cc=linux-scsi@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.