On Tue, 25 Jul 2000, Stephen Frost wrote:
> 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.
I'd rather have it disconnected from the host system for the upgrade,
personally. Just imagine if that new RAID array firmware b0rks, flooding
the host's SCSI bus with random crap...
> > > 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?
It shouldn't be a large patch - little more than an if statement - and the
things in question are not potentially bad - they are DEFINED to be bad,
with a single rare exception.
> > > > 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.
That new firmware is a very low-level operation. Any problems with it, and
you just broke the system.
> > 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.
That's because I think your method is a bad thing in itself. I do NOT want
to see things like this tied to any particular OS, Linux included. Nor do
I like the idea of attempting low-level procedures online on a production
system, but that's another issue.
Anyway, the whole matter is largely void now - Andre expects the vendors
to block these commands at the drive level anyway.
James.
-
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