Re: INITIO scsi driver fails to work properly

2007-12-20 Thread Theodore Tso
On Thu, Dec 20, 2007 at 01:32:02AM -0800, Natalie Protasevich wrote:
  The problem is that it appears to the casual observer as if they can
  then add information to the bug through the web interface.  But that
  information will never be forwarded to the mailing list.  Unless there's
  a way of marking bugs as 'unchangable through the web interface' or 'all
  messages appended to this bug need to be forwarded', Bugzilla just
  doesn't fit our needs.
 
  The Debian BTS fits our way of working much better.  Perhaps somebody
  should investigate a migration.
 
 This is excellent observation by Matthew and James. There is no magic
 in bugzilla not being loved, it is just not the right set of features
 for effective work on a problem. It doesn't support multiple
 developer' collaboration well.

Actually, Bugzilla *could* be configured so that, say, linux-scsi was
copied for all SCSI bugs (linux-scsi could just be added to the cc
list).  The problem though is that Bugzilla will then proceed to cc
linux-scsi for all the Bugzilla state change details which might annoy
the denizens of the linux-scsi list.   

But if new entries on the Bugzilla entry could be set to forward to
the appropriate mailing list with the messaging *looking* a lot more
like a mail message, I suspect it could be acceptable.  One of the
advantages of the Debian BTS is that it's much more integrated into
the e-mail workflow.  (Although it lacks the roll up and reporting
capabilities that are beloved by managers...)

But hey, it could be worse.  We could have chosen the Sourceforge bug
tracker.  :-)

- Ted
-
To unsubscribe from this list: send the line unsubscribe linux-scsi in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: What still uses the block layer?

2007-10-14 Thread Theodore Tso
On Sun, Oct 14, 2007 at 06:45:44PM -0500, Rob Landley wrote:
 I admit a certain amount of personal annoyance that once the SCSI
 layer consumes a category of device (USB, SATA, PATA), they can
 often _only_ be used by going through the SCSI midlayer.  (This
 strikes me as analogous to TCP/IP claiming ethernet and PPP devices
 so thoroughly that you can no longer address them as eth1 or
 /dev/ttyS0.)

That's because modern USB, ATAPI (what was once known as IDE), SATA
really *all* using the SCSI command protocols at the low level, just
as Ethernet and PPP interfaces really are fundamentally the same
thing.  You can rail against it, but that's the mark of someone who
refuses to accept reality.

 This has the annoying effect of bundling together different types of
 devices and making device enumeration unnecessarily difficult: my
 laptop only has one SATA hard drive and can't gain another without a
 soldering iron, but that drive could move from /dev/sda to /dev/sdb
 if I reboot the system with a USB key plugged in.  This seems like a
 regrettable loss of orthogonality to me.  I remember back when
 /dev/usb0 and /dev/hda were separate devices that showed up in /dev,
 but these days it's SCSI seems to trump it's USB, it's ATA, or
 it's SATA.  (Even though none of those are actually SCSI hardware,
 they just send a similar packet protocol across the wire.)

You're showing your ignorance here.  In fact in the past few years,
ATA and SCSI has been converging significantly, with the ATAPI
specification has essentially incorporating the SCSI protocol by
reference and by value --- with the point that SAS was developed by
the SCSI Trade Association, and SAS is effectively a superset of SATA,
to the point where with care, you can actually mix SAS and SATA drives
on the same in enclosure (SAS and SATA are physically compatible on
the connector level).

More to the point, with SATA, hot plugging has been designed in, so
probing order is not going to be well defined, just as with USB
devices.  And there are already relatively common situations where the
same disk can show up via multiple different interfaces.

For example, if you have a modern Thinkpad with an secondary SATA hard
drive in an Ultrabay, and you plug it into the Ultrabay in your T60,
it will show up as a SATA drive.  However, if you plug it into the
Advanced dock, it shows up as a USB device.  And with iSCSI not only
can you encapsulate a SCSI command stream over USB, you can do so over
IP as well.  In any case, regardless of how the physical SATA drive is
attached to the system, you want it to show up as the same device and
be mounted in the same location.

That's why identifying filesystem by UUID's or Labels is so critical.
This is not a new concept; we've had the capability to do this for
over a decade, and I always knew it would be necessary for us to do
this sooner or later --- which is why I added the UUID support to ext2
back in 1996.

 The fact that udev can theoretically unwind this hairball is not an
 excuse for conflating different categories of devices in the first
 place.

See the thinkpad Ultrabay drive example above.  You address hosts by
IP address; it doesn't matter whether you access them via a PPP
interface, or a wireless interface, or a ethernet interface.
Similarly, a disk could in theory be accessible over USB, SATA, or
iSCSI, and the Thinkpad example is only one such where the same
filesystem might be accessible over multiple interfaces.  And with
multipath fiber channel SAN's (and I hate to break it to you, but FC
also uses SCSI protocols) storage is very much looking more and more
like networking.

- Ted
-
To unsubscribe from this list: send the line unsubscribe linux-scsi in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: end to end error recovery musings

2007-02-23 Thread Theodore Tso
On Fri, Feb 23, 2007 at 05:37:23PM -0700, Andreas Dilger wrote:
  Probably the only sane thing to do is to remember the bad sectors and 
  avoid attempting reading them; that would mean marking automatic 
  versus explicitly requested requests to determine whether or not to 
  filter them against a list of discovered bad blocks.
 
 And clearing this list when the sector is overwritten, as it will almost
 certainly be relocated at the disk level.  For that matter, a huge win
 would be to have the MD RAID layer rewrite only the bad sector (in hopes
 of the disk relocating it) instead of failing the whiole disk.  Otherwise,
 a few read errors on different disks in a RAID set can take the whole
 system offline.  Apologies if this is already done in recent kernels...

And having a way of making this list available to both the filesystem
and to a userspace utility, so they can more easily deal with doing a
forced rewrite of the bad sector, after determining which file is
involved and perhaps doing something intelligent (up to and including
automatically requesting a backup system to fetch a backup version of
the file, and if it can be determined that the file shouldn't have
been changed since the last backup, automatically fixing up the
corrupted data block :-).

- Ted
-
To unsubscribe from this list: send the line unsubscribe linux-scsi in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html