On Tue, 31 Jul 2012, David Boyes wrote:
> Florian's original post.
> Corroborating posts from other users (Mark Post, etc)
> My data (on average 3 out of 100 tests fail)
>
> I'd be happy to send you more examples. Are you looking for something
> specific? The script recently posted here (by you, I
Hello list,
Florian wrote about a .1 second sleep time - what a concept! I've never
thought to sleep for less than a second.
David wrote:
> ... Inserting a wait of a few (variable between 1 and 30 seconds,
> depending on load) seconds reduces, but does not eliminate, the
> failures. Introducing
> On Sun, 29 Jul 2012, David Boyes wrote:
> > Since we have ample data from multiple sources that this DOES NOT
> operate reliably, the original question still stands.
>
> Would you mind sharing some of this ample data? Are this all cases where
> dasdfmt complains about other users after "udevadm
On Sun, 29 Jul 2012, David Boyes wrote:
> Since we have ample data from multiple sources that this DOES NOT operate
> reliably, the original question still stands.
Would you mind sharing some of this ample data? Are this all cases where
dasdfmt complains about other users after "udevadm settle" r
> On Sunday, 07/29/2012 at 05:14 EDT, David Boyes
>
> wrote:
> > In any case, I think Mike's question is a good one: if chccwdev needs
> > a 'udevadm settle' to operate correctly, why isn't it doing it itself?
> > It
> seems
> > like we should be able to rely on chccwdev operations being atomic.
>
On Sunday, 07/29/2012 at 05:14 EDT, David Boyes
wrote:
> In any case, I think Mike's question is a good one: if chccwdev needs a
> 'udevadm settle' to operate correctly, why isn't it doing it itself? It
seems
> like we should be able to rely on chccwdev operations being atomic.
This seems like th
> Since dasdfmt does the low-level formating stuff it tries to make sure it's
> the
> only user of the device. But in your case it looks like sometimes it's not the
> only user and it's likely that's because some worker of udev is not finished
> and still has a file descriptor to this device node
On Sat, 28 Jul 2012, Michael MacIsaac wrote:
> function enableDevice { chccwdev -e $1; udevadm settle; }
>
> and always call that function instead chccwdev -e. So my question is
> still: "If a udevadm settle is always required after a chccwdev -e, then
> why is it not just built into the command?
Sebastian,
> So I still think it is sufficient to do:
> chccwdev -e xxx ;udevadm settle ;dasdfmt xxx
... which is somewhat the conclusion I came to with the previous test
script. So everyone wanting to script with chccwdev -e could write a
function such as:
function enableDevice { chccwdev -e
On Fri, 27 Jul 2012, Florian Bilek wrote:
> I can confirm that the udev settle is returning always with zero. I have
> the timeout set to even to 60 sec and an exit if the device node is
> available. And that is stlll not enough because udev exits. Without exit I
> had set the timeout to 30 secs. O
"Never attribute to malice, that which can be adequately explained by
stupidity"
- Hanlon's Razor
> Original Message ----
> Subject: Re: Synchronous option for chccwdev -- was there a resolution
> ?
> From: David Boyes
> Date: Fri, July 27, 2012 11:17 am
>>> On 7/27/2012 at 01:26 PM, Michael MacIsaac wrote:
> Nice test case! I modified it a bit :))
I have two SLES10 SP4 systems. One is on a fairly loaded box, and one is on a
fairly idle box. On the loaded box, the failure rate of the chccwdev -e
command was fairly high, even with a 2 second
Dear all,
I can confirm that the udev settle is returning always with zero. I have
the timeout set to even to 60 sec and an exit if the device node is
available. And that is stlll not enough because udev exits. Without exit I
had set the timeout to 30 secs. Only running the loop two times the chan
> I believe that's the piece that's missing (for most people). I can easily
> reproduce the problem on my SLES11 SP2 system with this script:
> vmcp define vfb-512 302 2000
> date +%H:%M:%S.%N
> chccwdev -e 0.0.0302
> mkswap /dev/disk/by-path/ccw-0.0.0302-part1
Yeah, that's pretty much guaranteed
>>> On 7/27/2012 at 01:26 PM, Michael MacIsaac wrote:
> I never got the chccwdev to fail.
If you did the test on SLES11 or later, I don't think that command will fail
since it uses /proc/cio_settle.
Mark Post
--
For LINUX-39
Mark,
> I can easily reproduce the problem on my SLES11 SP2 system with this
script:
> ...
Nice test case! I modified it a bit :)) I never got the chccwdev to fail.
I did see the mkswap fail regularly. Then I randomly added a "udevadm
settle" after the chccwdev -e. Every time the udevadm settl
On Friday, 07/27/2012 at 11:33 EDT, Sebastian Ott
wrote:
> The process of setting the device online involves generic path
> verification work done by the Common IO Layer and device specific
> online processing done by the device driver (DASD in this case). Once
> the DASD driver finished its work
> We have a set of scripts that Setup the WHOLE multipath SAN disk for us.
> From the chccwdev, zfcp_*, to fdisk
> and format and multipath setup and mount (Yes the WHOLE thing). We
> have found by placing sleep for 15 seconds between commands , especially
> the hardware level ones, increased our
>>> On 7/27/2012 at 11:15 AM, Sebastian Ott wrote:
> Once
> the DASD driver finished its work and created a block device, userspace
> is informed about this via uevents. After that chccwdev returns. The
> only thing that's missing now is udev creating a device node and that's
> covered via udev s
>Once the DASD driver finished
> its work and created a block device, userspace is informed about this via
> uevents. After that chccwdev returns. The only thing that's missing now is
> udev creating a device node and that's covered via udev settle.
Thanks for the walkthrough. The problem appears
our reliability for success.
Ben Duncan - Business Network Solutions, Inc. 336 Elton Road Jackson
MS, 39212
"Never attribute to malice, that which can be adequately explained by
stupidity"
- Hanlon's Razor
> Original Message ----
> Subject: Re: Synchronous option for
On Fri, 27 Jul 2012, David Boyes wrote:
> > On which distro do you have problems with chccwdev?
> > [snip]
> > ..which appears to work fine.
>
> It's not a distribution issue; it's a timing-dependent issue that has to do
> with how quickly your hardware responds. Your script will work *most* of th
> On which distro do you have problems with chccwdev?
> [snip]
> ..which appears to work fine.
It's not a distribution issue; it's a timing-dependent issue that has to do
with how quickly your hardware responds. Your script will work *most* of the
time -- except when it doesn't.
Easy way to rep
On Thu, 26 Jul 2012, David Boyes wrote:
> A week or two back, someone (I think it was Florian Bilek) asked why there
> was a delay between invoking chccwdev and the device becoming available, and
> whether there was an option or command that would exit only when the device
> was actually availab
U] On Behalf Of Florian
Bilek
Sent: Friday, July 27, 2012 6:28 AM
To: LINUX-390@VM.MARIST.EDU
Subject: Re: Synchronous option for chccwdev -- was there a resolution?
Hi David,
Thank you for bringing up this topic again. No, unfortunately there was no
other solution than to rerun the commands.
I thi
Hi David,
Thank you for bringing up this topic again. No, unfortunately there was no
other solution than to rerun the commands.
I think there should be an option for chccwdev to wait till DE/CE is
received and not to terminate with device busy.
Kind regards,
Florian
On Thu, Jul 26, 2012 at 6:52
A week or two back, someone (I think it was Florian Bilek) asked why there was
a delay between invoking chccwdev and the device becoming available, and
whether there was an option or command that would exit only when the device was
actually available. There was some discussion of the --settle op
27 matches
Mail list logo
