mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Mike Hayward <hayward@loup.net>
To: hancockrwd@gmail.com
Cc: linux-kernel@vger.kernel.org, mvds.00@gmail.com
Subject: Re: SCSI GENERIC command queueing for block storage is unstable.
Date: Tue, 16 Mar 2010 21:30:07 -0600	[thread overview]
Message-ID: <201003170330.o2H3U7j5011328@alien.loup.net> (raw)
In-Reply-To: <4B9EC36F.8010404@gmail.com> (message from Robert Hancock on Mon, 15 Mar 2010 17:31:59 -0600)

Hi Robert,

 > > After discovering that O_NONBLOCK reads and writes were actually
 > > blocking calls, I attempted to use the SCSI generic driver for
 > > nonblocking io.  The good news is that it is nonblocking; the bad news
 > > is that it is not dependable in any of the systems I have tested with.
 > >
 > > Does anyone know if these defects have been fixed in later kernels?
 > >
 > > 1. When queueing, write can occassionally return errno 12 (ENOMEM, Cannot
 > >     allocate memory).  This is documented in the SCSI GENERIC HOWTO,
 > >     however only for indirect io and it says extremely rare.  I can cause
 > >     it easily within a few hours and it can return even for direct io when
 > >     no io's are queued and 80% of the ram is free or in buffer cache.  The
 > >     fd polls as available for writing, but retrying never clears the error
 > >     and the fd is no longer usable.  This is a complete show stopper.
 > >
 > >     Linux 2.6.22.1-32.fc6 #1 SMP Wed Aug 1 14:30:16 EDT 2007 x86_64 x86_64 x86_64 GNU/Linux
 > 
 > First off, have you tested any of these problems against a newer kernel?

Ok, #1 is also happening on 2.6.32.9-70.fc12.x86_64... this time on
several processes nearly simultaneously, so it appears it isn't just
tied to one fd.  This time instead of ENOMEM though, I got errno ==
Invalid argument(16) when writing the sg_io_hdr.

interface_id S dxfer_direction fffffffe cmd_len a mx_sb_len fc
iovec_count 0 dxfer_len 200000 dxferp 0x7f85e53dd200 cmdp 1f30a38
sbp 1f30a48 timeout 20000 flags 1 pack_id 0 usr_ptr 0x1f30a00

There appears nothing wrong with the sg_io_hdr.  If I can get through
bug #2, my app will normally run constant io for hours before blowing
and it is unlikely three daemons running against separate sg devices
would simultaneously hit this error unless something were wrong in the
sg driver itself.

- Mike

      parent reply	other threads:[~2010-03-17  3:43 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-03-15 18:25 Mike Hayward
2010-03-15 23:31 ` Robert Hancock
2010-03-17  3:09   ` Mike Hayward
2010-03-17  3:30   ` Mike Hayward [this message]

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=201003170330.o2H3U7j5011328@alien.loup.net \
    --to=hayward@loup.net \
    --cc=hancockrwd@gmail.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mvds.00@gmail.com \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®