From: Douglas G. <dgi...@in...> - 2009-01-27 03:53:37
|
Bruce Allen wrote: > Hi Ed, > > A few comments: > > (1) The problem of addressing a device which is actually a RAID set with > more than one disk drive is important. I hope we could find a solution > which handles this well. > > (2) The 'problem' of addressing a device which is actually file backed > is one that I don't think we should try to solve. In this case I think > it would be OK to simply produce a warning error message. The problem > of addressing the device beneath the file and file system needs to be > solved in some other way, in my opinion. > > (3) In fact the most useful SMART functions are the ability to run self > tests and examine the ATA error log and SMART self-test logs, and to > monitor Attribute values. Any solution should address these points. So > it's not enough for example to simply be able to return a single 'smart > status' for a RAID set, which tells you if any of the devices have a > failing SMART status. > > I think that this problem (tunneling SMART and/or ATA commands over AoE) > has some similarities to the problem of tunneling SMART commands through > a SCSI / ATA Translation (SAT) layer. The t10 SAT draft addresses this > problem, but only for a single disk. As here, addressing multiple disks > behind a single virtual device is not considered. > > We do have at least one develper, Doug Gilbert, who was involved in the > drafting the SAT standard, and incorporating it into smartmontools. He > might have some thoughts about the questions that you've asked. Bruce and Ed, Well I think Bruce wrote pretty well exactly what I was thinking ... sounds like SAT all over again. Ed, I guess it is a bit much to expect but can SCSI commands be carried over an AoE transport? To be useful there would need to be some mapping between SCSI's LUs and physical drives in the AoE target. Does AoE on a target preclude TCP/IP? If they can co-exist then a small footprint web server on the target could display (via http) the physical devices with buttons to issue common smartctl commands and show the results in a text box. I thought about this when I was recently using ssh to a NAS box to run smartmontools commands on its physical disks. BTW Part of the fun with smartmontools development is circumventing various layering schemes :-) Doug Gilbert > On Mon, 26 Jan 2009, Ed L. Cashin wrote: > >> Bruce Allen has let me know that there has been a significant ongoing >> interest in using smartmontools with ATA over Ethernet, and I would >> like to solicit ideas here about how SMART can or cannot fit with the >> abstraction that is an AoE storage target. I will present some of my >> own thoughts on the issue. >> >> One of the things about AoE devices is that they are not always >> associated with a single disk. In the beginning (back when aoeping >> was created) an AoE target was always associated with a single >> physical PATA drive, because the PATA EtherDrive blade was the only >> AoE target around. Since then, they are more often associated with an >> abstraction. For example, the vblade might be file backed. The >> Coraid SR Appliance exports AoE targets that are backed by RAIDs over >> SATA disks. >> >> When sending a SMART command to an AoE target, any knowledge of what >> is "under the covers" is "out of band" in that the AoE protocol itself >> is agnostic about what kind of storage is behind the AoE target. In >> fact, that agnosticism is a key part of the protocol's simplicity and >> flexibility. >> >> If you are interested in using SMART to perform inquiries on an AoE >> target, what do you expect to occur on the AoE target? With an SR do >> you expect "error threshold exceeded" to be reported when *any* >> underlying disk's error threshold has been exceeded, or do you have >> some other expectation? With a vblade do you expect the SMART >> commands to be passed through the vblade to the localhost's disks? >> What if a disk isn't being exported by the vblade but a file in a >> filesystem on a disk? >> >> In that case especially, I'm not sure that the violation of system >> layers would be warranted. The admin could just run a SMART query on >> the disk itself instead of on the vblade's AoE target. Similarly, on >> an SR, the admin could run "show -s" to access SMART information about >> each SATA disk. Doing that would be more natural and straightforward, >> since each real disk is being asked directly for its SMART answers, so >> there's no potential for confusion about the meaning of the response. >> >> For abstractions that are not physical disks, we would have to create >> a mapping from SMART response information to facts about the >> underlying storage, and the mapping would be a bit arbitrary. Instead >> it seems more straightforward to use the existing SMART facilities >> directly. >> >> But those issues aside, it would probably make sense for the aoe >> driver in Linux to pass SMART commands on to AoE targets when >> possible. Not all SMART commands and responses can go into AoE >> packets, but some could. If the aoe driver passed them through, then >> the remote device could respond or not as it was able, and the user >> could interpret the results in whatever way seemed appropriate. >> >> What do you think? >> >> Please Cc me on responses. Thank you. >> >> > |