Peter Dunlap writes: > It seemed wrong to take the workaround from the (already code reviewed) > ON component without taking the comment with it. > > Look, this is the exact reason I explicitly sought feedback from > networking. It sounds like this is something we need to dig into and > understand further. We will remove the workaround and re-test with the > current ON bits. Maybe this was a problem with an older version of ON. > If it behaves as it did before (badly) we will file a bug and solicit > help from the networking team. Is that acceptable?
Yes ... though I'd think that regressing TX is a fairly serious issue. > I think I made it clear in a separate e-mail that we are committed to > resolving your review comments. My mention of the CIFS server is not > intended to be an excuse nor am I waving it around like a free pass. My > point is that if this change breaks something then that something is > *already* broken. Fair point. I agree it's broken. > So we should probably file a fairly high priority bug > against CIFS server right? Yes. For what it's worth, I think there are a couple of crucial differences here. An important one is that the CIFS server is an optional feature that is somewhat unlikely to be used in a TX environment, and in a crisis, we'd have alternatives, such as SAMBA and even NFS. Using iSCSI storage, though, seems much less flexible: we'd have to tell customers that they can plan their data centers around iSCSI _or_ use TX, but not both. -- James Carlson, Solaris Networking <[EMAIL PROTECTED]> Sun Microsystems / 35 Network Drive 71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677 _______________________________________________ networking-discuss mailing list [email protected]
