> Does 1. really need to be fixed? > I'm not suggesting that it's currently broken I'm just asking if it would be reasonable to special case our usage a little bit in order to avoid unnecessary alarm to users. This will be seen as a fit and finish/polish issue. If it's easy to address that then we should try to. I accept that it may not be as straight forward as I hope however.
Perhaps time-slider could set a reserved property on the mirrored zpool to indicate to ZFS that this "mirror" device could get unplugged a lot and simply tailor the status message and leave everything else as is? I don't personally see it as a blocker though, but definitely a nice to have. > I ask this since I imagine there will be some > resistance from the ZFS team to essentially breaking > the spec for the sake of not confusing some users. I'm not expecting the existing spec to be broken, I'm asking if an augmentation to the spec would be possible. I too would be opposed to any changes that would break the existing spec since what we want for time-slider is special case usage. > > I would argue that anybody who knows enough to run > "zpool status" is also capable of learning what a > mirror is and how it works, and that this is then > more a training / documentation / expectations issue. > In your documentation for this feature, include a > section for advanced users explaining what "zpool > status" will show and I don't see any problem. > That might be an acceptable solution too, if addressing 1. is not feasible. > What I would suggest is that since this is end user / > desktop functionality, why don't you create a desktop > GUI for reporting on the status of the "backup" > mirror? That would seem to make more sense to me > than modifying ZFS. You could create a nice simple > GUI that shows whether the device is connected or > not, and gives a rough estimate to the user of how > far through the resilver process it is. > > You could even have it live in the system tray, with > the icon showing whether the device is connected, > disconnected or resilvering, with the tooltip > reporting the resilver status. > Yep, we're considering this also, exactly along the lines you suggest. >From my own observations it seems that the resilver completion estimates are rather inaccurate. We may have to restrict the scope of notification to simple event responses (connected:uptodate -> disconnected -> reconnected:resilvering, connected:uptodate) > That sounds a lot nice for end users than having them > try to interpret "zpool status". It does, but it's generally bad form to have the CLI and GUI in disagreement with each other or be inconsistent about how they inform the user. One other question I have about using mirrors is potential performance implications. In a common scenario the user might be using the main S(ATA) attached disk and a USB external disk as a mirror configuration. Could the slower disk become a bottleneck because of it's lower I/O read/write speeds? Would a system write block until ZFS had written the data to both sides of the mirror? Similarly, could the detached mirror device slow down reads/writes because it's doing extra work to cope with the missing mirror device? Thanks, Niall. -- This message posted from opensolaris.org _______________________________________________ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
