Re: Does this help explain better?? ATA/IDE Thread

From: Stephen Frost (sfrost@ns.snowman.net)
Date: Tue Jul 25 2000 - 14:04:31 EST


On Tue, 25 Jul 2000, James Sutherland wrote:

> > That's very unlikely to be the case. On a large system with lots
> > of users logging in all the time upgrading the flash on a disk not
> > currently in use shouldn't be a cause to reboot the machine. I doubt
> > you'd upgrade the firmware on a disk currently in use, that might be messy,
> > but with the RAID ability we're working towards there is the possiblity
> > that one could slowly go through and upgrade all of the disks without
> > the users knowing anything.
>
> Do you want to do low-level maintenance/diagnostics on a drive in situ, on
> a production machine? I wouldn't. At the very least, I'd prefer to pull
> the drive, plug it into another machine and do the work there. On such a
> machine, the drives will be hot-pluggable, I suspect...

        That is a possibility, though it's also more of a pain. It also
doesn't work in the more general case of other pieces of the system which
can be taken offline and upgraded but perhaps not easily removed.

> > This is the kind of mainframe-like ability large data centers and
> > organizations are likely to find useful. Yes, Linux still has a long way
> > to go, but it's working on it, and hopefully we can keep it nice and clean
> > all the way.
>
> Nice and clean is not a term I'd apply to your approach.

        You'd prefer large patches intended solely to filter a clean
interface better than letting root use a clean interface to do things
which *might* be bad?

> > > I'd rather like to see a nice "Manufacturer's Diagnostics/Update Disk"
> > > available for my hardware. Easier and cheaper for them than supporting
> > > Windows 98/ME, Windows NT/2k, Linux, Solaris/x86, BeOS, MacOS,
> > > Solaris/SPARC, and every other OS which might be used with the drive!
> >
> > This could possibly work as well, and in general is what is done
> > now on small systems, but that doesn't mean we should limit ourselves to
> > it.
>
> You need to take the drive offline anyway. I'd prefer to avoid running any
> low-level diagnostics on a production machine if I can avoid that.

        They aren't low-level diagnostics. A firmware upgrade doesn't go
probing all around the bus looking for stuff like a diagnostic might. Nor
does it probe the drive in funny ways, it uses a known (to the vendor, who
is writing the code) set of commands to pass a new firmware to the drive.

> I certainly don't want to see my hard drive tied to ANY particular OS, or
> group of OSs, which the vendor deigns to support. How could this be
> avoided with your method??

        There likely would be an option for either. My method does not
deny the existance of your method. Your method, however, is intended to
not allow mine.

                Stephen

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/



This archive was generated by hypermail 2b29 : Mon Jul 31 2000 - 21:00:19 EST