On Monday October 27, david@xxxxxxxxxxxx wrote: > > I am with Kay here, never force automount. > I put that right up there with the bonehead MSFT rule of trying to write > signatures on disk drives once they appear. By you wouldn't mind if something that looked like it might have once been a raid1 started a resync as soon as you plugged it in? > > Furthermore, don't just delete /dev/md names. That would be even a greater > mistake. LINUX today has storage on SANs, clustering, multi-tasking, multi-pathing, > SAN-management/monitoring software that will be using device paths that you want to > delete. I don't understand. If the md array has been explicitly stopped, why not remove the names from /dev. They have no meaning any more. And nothing can have them open. > > I can't think of a simple fix, but can think of a complicated fix to make this play > nice in such environments, when things are good .. and when things go bad. My outside- > the-box suggestion is to present md target devices as a SCSI RAID controller or > processor device where you use ANSI-defined sense keys/ASC values to allow > apps that are running remotely or even > locally to query immediate state. If the md device is broken, then report the same sense > information not ready, spun down, whatever ... that a physical disk would report for > various partition. > More importantly, use EVPD Inquiry and log pages to query configuration information, of > both the /dev/md device, AND all of the partitions, along with health and anything else. > Enterprise management software wouldn't have to log into the LINUX host and run custom > scripts to see what is going on. Use mode sense to send control/configuration change requests. > > The ANSI provides a mechanism and options for defining a unique naming convention, and you can > even add a UUID in the format you want as a Vendor-specific layout. There is already a foundation > for such work due to the iSCSI logic, but obviously much more work is required. > > Yes, this not a simple & easy fix, but if you want to future-proof everything and make LINUX storage > easy to integrate into heterogeneous environments, then let ANSI be your guide. What I think you are suggesting is that md raid be exportable via iSCSI (or FCOE or AOE or flavor-of-the-month) in such a way that status-query commands 'do the right thing'. Sounds like we want a plug-in for iscsid (or whatever it is that support iscsi service). Is that what you mean? Thanks, NeilBrown -- To unsubscribe from this list: send the line "unsubscribe linux-raid" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
