Jump to content
SNS Users' Forums
  • Announcements

    • Eric Newbauer

      Follow SNS on Twitter!

      Get notifications via Twitter! Looking for instant updates? We're now also announcing new versions and beta programs via Twitter. Follow Studio Network Solutions on Twitter. Thanks!

sommerfeld

Members
  • Content count

    7
  • Joined

  • Last visited

Community Reputation

0 Neutral

About sommerfeld

  • Rank
    Newbie
  1. If you're using iscsi with time machine on MacOS snow leopard, I've found the most recent beta (4.0.0.204_BETA) to be greatly improved over 4.0.0.197_BETA. With 197, time machine was laggy and unpredictable with frequent long pauses. With 204, it's best described as snappy and responsive. In both cases the iscsi target is a ZFS zvol in an opensolaris system running build snv_111; the initiator is a mac mini running 10.6.2; they're connected via wired gigabit ethernet.
  2. I've installed the new initiator. While it's too soon to be sure, it appears to be a big improvement over the previous beta. In particular, time machine seems to be much faster and more responsive now and there isn't a lag after resume before the system becomes responsive. During and shortly after boot I saw the following messages in the kernel log: I have not seen any: since rebooting with the new beta.
  3. Thanks. timestamps from /var/adm/kernel.log shows that "GLO Warning" messages are coming out at a rate of several per minute: are these from the driver? anything you want me to look at with dtrace or other tools?
  4. another new error message (bolded below) in "sudo dmesg" output: Is the target driver attempting to power-manage the remote iscsi disk?
  5. I'm trying a few things now that it seems likely that it's a failure of the iscsi initiator on the mac to recover gracefully from an unexpected close of the tcp connection by the target. This is really in the category of workaround/mitigation rather than a real fix but if it lets us keep using time machine for now.. 1) I set the "Wake for network access" preference in the "energy saver" system preference pane (it was previously not set). 2) I built a custom version of iscsitgtd on solaris which doesn't set the (sadly misnamed) "SO_KEEPALIVE" socket option so it should be more tolerant of an unresponsive peer. It's too soon to tell if this makes a difference. I'll report back in a few days.
  6. Here's some additional information. "sudo dmesg" contains the following messages which seem to relate to the iscsi initiator: and, earlier on the same system: Is there anything else I should look for? error 32 is traditionally EPIPE; I suspect that the iscsi TCP connection is being closed by the target while the mac is asleep and it's not recovering from this.
  7. Shortly before Christmas I installed the snow leopard beta bits (4.0.0.197) on our home mac mini running snow leopard, and connected it to a 60GB zfs zvol on an OpenSolaris server. I'm using the iscsi device exclusively for Time Machine backups. Backups are (mostly) working but we've had to reboot the mac fairly frequently to recover from hangs -- most commonly, we get the "spinning beachball of death" and apps are unresponsive. Sometimes only one or two apps are affected; in other cases, they all lock up. We use fast user switching extensively (between two users -- me and my wife) and I've seen the lockup occur when the system wakes up and I immediately user-switch to my account. I realise that this bug report is woefully incomplete. What information can I collect at this point to help you diagnose the problem? I'm an experienced unix/bsd/solaris kernel developer (and so is my wife) but don't have macos-specific experience.
×