Messages in this thread | | | Date | Tue, 25 Jul 2000 15:04:31 -0400 (EDT) | From | Stephen Frost <> | Subject | Re: Does this help explain better?? ATA/IDE Thread |
| |
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/
| |