Re: [OpenIndiana-discuss] SMR disks
On 1 May 2015 at 07:13, Nick Tan wrote: > Has anyone tried using SMR disks with ZFS? I bought a Seagate 8TB SMR disk > and put it in a esata enclosure for my backups. I found that zfs send > would cause the disk to go offline. My guess is that zfs send is too fast > and fills the drive write cache. I've been using one of those disks for about a month now with ZFS on Linux. It's part of a set of three mirror vdevs; the initial resilver took about two or three times as long as I would have expected for a traditional drive (it's hard to be sure exactly how long it would have taken with a traditional drive since my pool is a lot different compared to my last resilver: fuller and more fragmented), which if anything is better than I was expecting, since the sustained and fairly random write workload of a resilver is about the worst case scenario for an SMR drive. Since then, I've not noticed any performance issues, though the pool does not see heavy usage, and nearly never sees significant random writes. Overall, I've actually been surprised at how well it's been working: I was fully prepared for the possibility that ZFS would present a pathological use case rendering the drive almost useless, but in practice I've had no trouble at all. It is possible that Linux handles drive delays in such a way as to lower the chance of the disk going offline, although I've actually read about *more* problems with drive timeouts with ZFS on Linux than on Illumos (because there are multiple points in the stack that will wait for a timeout before reporting an error up), so I'm not sure. Currently my drive is paired with another 4TB drive, so it's effectively 100% over-provisioned. I don't think this should make a difference, but it's worth mentioning just in case. Note that the random access on-disk cache (ie, non-shingled section that acts as a persistent cache for random writes until they are written into place) is 25GB on this drive, so if you find that the first 25GB or so goes at great speed and then performance drops off a cliff and the drive starts hanging for several seconds at a time, that will be why (though I've not actually experienced any of that worst-case behaviour myself). This paper has some experimental analysis of SMR performance, specifically including measurements on the Seagate Archive drives: https://www.usenix.org/conference/fast15/technical-sessions/presentation/aghayev ___ openindiana-discuss mailing list openindiana-discuss@openindiana.org http://openindiana.org/mailman/listinfo/openindiana-discuss
Re: [OpenIndiana-discuss] zabbix-agent
On 6 November 2014 12:11, Edward Ned Harvey (openindiana) wrote: >> From: Pawel Stefanski [mailto:pejo...@gmail.com] >> >> here you have complete instruction >> https://www.zabbix.com/wiki/howto/install/solaris/opensolaris > > I know. I described that as Plan B. See: > > >> > Plan A is to get it from a standard package >> > repository, and Plan B is to get the solaris binaries from zabbix.com. > > If Plan A doesn't exist, that's ok. I just thought zabbix-agent was in some > standard package repository because of Adam Stevko's and Andrzej Szeszo's > emails discussing it in the package repo. Andrzej is apparently the > maintainer of http://wiki.openindiana.org/oi/Package+Repositories so... > That led to credible belief that I should expect to find the package in > there... I couldn't find it in any of the standard repos when I looked earlier in the year, but it is in OpenCSW and that's what I ended up using. ___ openindiana-discuss mailing list openindiana-discuss@openindiana.org http://openindiana.org/mailman/listinfo/openindiana-discuss
Re: [OpenIndiana-discuss] OI-151a9
On 19 February 2014 18:18, Tim Mooney wrote: > In regard to: [OpenIndiana-discuss] OI-151a9, Marc Lobelle said (at > 7:11pm...: > > >> I see that a new version 0I-151a9 is available, but the version to >> download at http://openindiana.org/download/ is still 151a8. Where can I >> find the ISO for 151a9 ? Is it smoother that 151a8 that had many small >> inconvenients (gnome unusual behaviours etc.). > > > Check the archives for this list. Differences between 151a8 and 151a9 > and some of the problems that people have run into have been discussed > quite a bit in the past few weeks. > > My personal experience is that 151a9 is better than 151a8, especially > from a JDS perspective, but there are plenty of people that haven't > had the same experience. For my part I've found that a9 has problems running KVM with a Windows guest - it will usually boot, but will crash within a couple of minutes. Historically, updating KVM on OI has always been problematic - most versions have been broken in one way or another - so a9 isn't especially bad in that regard. With any luck I'll be able to just keep running the old version of system/qemu/kvm, rather than having to hold back from a9 altogether, but I won't be able to try that out for a few weeks. Other than that, everything appeared to look fine. I don't use any of the graphical packages that some people seem to have problems with though. ___ OpenIndiana-discuss mailing list OpenIndiana-discuss@openindiana.org http://openindiana.org/mailman/listinfo/openindiana-discuss
Re: [OpenIndiana-discuss] OI 1.8 /dev: need help (missing feature for read 'org.illumos:lz4_compress')
On 27 January 2014 10:05, Saso Kiselkov wrote: > Then the USB is broken and is trying to boot your disks, not the USB > (it's probably confusing the two also). You could also try using the > OmniOS USB - it's possible the OI GRUB stage2 is outdated and the > shipped version doesn't include LZ4 support (would be surprised, but > better make sure). > It definitely does on the ISO version (and has done for at least a few months) - I used an OI disc to solve this problem myself a while back. Unfortunately I don't recall the precise steps I followed, so I can't give any specific help other than to confirm that it is possible to solve the problem by booting from the OI disc and reinstalling grub from there. ___ OpenIndiana-discuss mailing list OpenIndiana-discuss@openindiana.org http://openindiana.org/mailman/listinfo/openindiana-discuss
Re: [OpenIndiana-discuss] Opinions on LSI RAID vs. ZFS
On 9 October 2013 14:37, Edward Ned Harvey (openindiana) wrote: >> From: Christopher Chan [mailto:christopher.c...@bradbury.edu.hk] >> Sent: Tuesday, October 08, 2013 8:42 PM >> >> Er...isn't hotswap capability PART of the specs whether the drives are >> SAS or SATA? I can do this on a cheap desktop motherboard but you cannot >> on a server board with getting a HBA? > > Maybe you're using a different bios, or maybe you're hotswapping like for > like drives that coincidentally work in your situation or something, but ... > > In BIOS, I have the option to enable/disable SATA port 0, 1,2,3. If the port > is enabled and nothing connected, it throws and error during POST. If > something is connected, it's identified as a 1TB or whatever drive, and > presented to the OS as c1t1d1 or whatever. Later if I disconnect that drive > while the OS is running, the OS still thinks c1t1d1 exists, but if I try to > access it, I'll get an IO error. If it were truly hot plug, then the OS > should get a drive disconnected signal, and c1t1d1 should not exist anymore. Is this in IDE emulation mode per-chance? If your controller acts this way in AHCI mode, it's defective and should be replaced, but most BIOSes default to IDE emulation where hotplugging is not supported (although it will probably work in practice, if you can persuade your OS to rescan the hardware). I hotplug SATA with wild abandon, even on the nastiest of cheap tat controllers - including the kind that comes as a PCI card for a few pounds and is bloody awful - and I've never seen one where hotplug wasn't completely reliable. Your point about taking you data into your own hands is valid, but if you're using hardware that you suspect to be that monumentally crap, you're already juggling eggs. ___ OpenIndiana-discuss mailing list OpenIndiana-discuss@openindiana.org http://openindiana.org/mailman/listinfo/openindiana-discuss
Re: [OpenIndiana-discuss] shell script mutex locking or process signaling
On 30 May 2013 15:29, Laurent Blume wrote:
> On 30/05/13 16:15, Edward Ned Harvey (openindiana) wrote:
>
>
>> I see there are a bunch of C constructs available ... mutex_init,
>> etc. Surely there must be a wrapper application around this kind of
>> thing, right?
>
>
> I spent some time looking for a lock in shell some time ago. The overall
> conclusion was that the only atomic operation in pure shell is mkdir.
I don't know about pure/POSIX shell, but at least bash and ksh support
noclobber, which should do the trick. I've been using the following
idiom for some time without problems:
#!/bin/bash
GLOBAL_LOCKFILE=/var/run/whatever.lock
function get_lock {
( set -o noclobber; echo "$$" > "$1") 2> /dev/null
return $?
}
function have_lock {
[ -f $1 ] && [ $(cat $1) = $$ ]
return $?
}
function release_lock {
if have_lock $1; then
rm -f $1
fi
return 0
}
function cleanup {
# Whatever cleanup required
release_lock $GLOBAL_LOCKFILE
return $1
}
trap 'cleanup $?' INT TERM EXIT
if get_lock $GLOBAL_LOCKFILE; then
# Do stuff
fi
NB: I hacked that out of a larger and more complex script; I hope I've
selected the relevant bits, but I haven't actually tested it.
(This locking looks sane to me, and it's been working in practice for
months, but if anyone does see any obvious blunders do point them
out.)
___
OpenIndiana-discuss mailing list
OpenIndiana-discuss@openindiana.org
http://openindiana.org/mailman/listinfo/openindiana-discuss
Re: [OpenIndiana-discuss] Problem with Dell iDRAC
On 22 April 2013 20:25, Rich wrote: > What NIC does the machine have? > > My solution on Rx10 with the BCM NICs was to grab the bnx driver blob from > Joyent [ > https://github.com/joyent/smartos-live/tree/master/overlay/generic/kernel/drv/amd64/bnx] > and throw that in /kernel/drv/amd64/bnx, bootadm update-archive, and > reboot. The BMC works great with that driver loaded and not the stock one. > > [I have a ticket about this for Dell R815s - > https://www.illumos.org/issues/1552 ] Thanks for posting this. I also have a T610, and I've just been leaving the bnx interface unplumbed. Not having tested with any other OSes, I wasn't sure if it was even supposed to work. ___ OpenIndiana-discuss mailing list OpenIndiana-discuss@openindiana.org http://openindiana.org/mailman/listinfo/openindiana-discuss
Re: [OpenIndiana-discuss] building a new box soon- HDD concerns and recommendations for virtual serving
On 17 April 2013 03:53, Carl Brewer wrote: > Further to my original post, I have a new (desktop, I know ... but I am on a > tight budget) Intel MB with an i5-3750 CPU and 32 GB of desktop RAM. > Booting the 151a7 live DVD shows that it thinks it's a 32 bit system (huh?). > It regognises almost all the devices when I run the device manager, but > doesn't see any HDD's. they're just not there at all. At boot time it says > they're too big for a 32 bit kernel. Why is it booting a 32 bit kernel > anyway? Maybe some BIOS thing I need to set? I booted the first (default) > image that the live CD displays. I don't know why it always boots the 32-bit version (I have a hard time imagining why anyone would *ever* want to boot a 32-bit kernel on a 64-bit machine, let alone enough for it to be the default), but you can tell it not to: When you boot from the live cd, at the grub prompt choose the option to edit the boot command line, and change $ISADIR to amd64. > As well as thinking it's 32 bit, it also doesn't see any drives at all. I > have a single new Seagate 2TB (4k blocks?) ST2000DM001 in it that the live > CD doesn't see at all. That's normal; the 32-bit environment can't access 2TB+ drives. If you boot the 64-bit kernel it'll see it just fine. BTW, is there a particular reason for the choice of Virtualbox over KVM? ___ OpenIndiana-discuss mailing list OpenIndiana-discuss@openindiana.org http://openindiana.org/mailman/listinfo/openindiana-discuss
Re: [OpenIndiana-discuss] ZFS and AVS guru $500
On 24 July 2012 17:11, Jason Matthews wrote: > > are you missing a zero to the left of the decimal place? For a couple of hours' work? ___ OpenIndiana-discuss mailing list OpenIndiana-discuss@openindiana.org http://openindiana.org/mailman/listinfo/openindiana-discuss
Re: [OpenIndiana-discuss] How to mount ISO image on boot?
On 18 July 2012 13:30, Michael Stapleton wrote: > I have one more idea that is more fun... Very nice! This works perfectly. Thank you very much for this. ___ OpenIndiana-discuss mailing list OpenIndiana-discuss@openindiana.org http://openindiana.org/mailman/listinfo/openindiana-discuss
Re: [OpenIndiana-discuss] How to mount ISO image on boot?
On 17 July 2012 17:50, Michael Stapleton wrote: > Or a job for autofs. > > Check out the man page for automount. > Thanks for the suggestion. The automount option does sound cleaner, although the init script option has the advantage of being very, very simple. I'll look into exactly how the automounter works - thank you both for the suggestions. ___ OpenIndiana-discuss mailing list OpenIndiana-discuss@openindiana.org http://openindiana.org/mailman/listinfo/openindiana-discuss
[OpenIndiana-discuss] How to mount ISO image on boot?
Hello all, >From the command line, I can mount an iso image using mount directly (without having to invoke lofiadm): # mount -F hsfs /path/to/my.iso /mountpath I've tried adding a line to /etc/vfstab to have this done automatically on boot: /path/to/my.iso - /mountpath hsfs - yes - But when I try to mount it I get: mount: Invalid argument Have I just got the vfstab entry wrong, or can this not be done? What's the recommended way to achieve the goal of having the iso mounted on boot? Thanks, Nye ___ OpenIndiana-discuss mailing list OpenIndiana-discuss@openindiana.org http://openindiana.org/mailman/listinfo/openindiana-discuss
Re: [OpenIndiana-discuss] KVM guests hang at boot on oi_151a4
On 27 June 2012 15:02, Aneurin Price wrote: > On 27 June 2012 13:28, Jonathan Adams wrote: >> mine stopped working after u2 ... there is a "fix" on this issue: >> >> https://www.illumos.org/issues/2626 >> >> # pkg uninstall driver/i86pc/kvm system/qemu system/qemu/kvm >> # pkg install system/qemu@0.15.0,5.11-0.151.1.2:20120209T223057Z \ >> system/qemu/kvm@0.0.1.20110813,5.11-0.151.1.2:20120209T223223Z \ >> driver/i86pc/kvm@0.0.1.20110820,5.11-0.151.1.2:20120209T214555Z >> > > Interesting; I don't think that's the same problem - the basic > symptoms sound similar, but I'm not getting any error message as in > that report. Also, it doesn't seem to affect the same versions. > > Based on that bug thread, I've tried different version combinations of > driver/i86pc/kvm, system/qemu, and system/qemu/kvm. > > The result is that driver/i86pc/kvm and system/qemu don't show the > problem in any version I've tried, but it manifests when upgrading > system/qemu/kvm from 0.0.1.20110813-0.151.1.2 to > 0.0.1.20120229-0.151.1.3 or later. Just to update: the same problem exists in oi_151a5, with system/qemu/kvm at 0.0.1.20120622-0.151.1.5. Reverting to 0.0.1.20110813-0.151.1.2 'solves' it once again. ___ OpenIndiana-discuss mailing list OpenIndiana-discuss@openindiana.org http://openindiana.org/mailman/listinfo/openindiana-discuss
Re: [OpenIndiana-discuss] KVM guests hang at boot on oi_151a4
On 27 June 2012 13:28, Jonathan Adams wrote: > mine stopped working after u2 ... there is a "fix" on this issue: > > https://www.illumos.org/issues/2626 > > # pkg uninstall driver/i86pc/kvm system/qemu system/qemu/kvm > # pkg install system/qemu@0.15.0,5.11-0.151.1.2:20120209T223057Z \ > system/qemu/kvm@0.0.1.20110813,5.11-0.151.1.2:20120209T223223Z \ > driver/i86pc/kvm@0.0.1.20110820,5.11-0.151.1.2:20120209T214555Z > Interesting; I don't think that's the same problem - the basic symptoms sound similar, but I'm not getting any error message as in that report. Also, it doesn't seem to affect the same versions. Based on that bug thread, I've tried different version combinations of driver/i86pc/kvm, system/qemu, and system/qemu/kvm. The result is that driver/i86pc/kvm and system/qemu don't show the problem in any version I've tried, but it manifests when upgrading system/qemu/kvm from 0.0.1.20110813-0.151.1.2 to 0.0.1.20120229-0.151.1.3 or later. I've also tested using parameters like Piotr Jasiukajtis gave as working configuration for him - same problem. I can keep system/qemu/kvm at the working version for now, but obviously that's not a solution long-term. Any ideas? ___ OpenIndiana-discuss mailing list OpenIndiana-discuss@openindiana.org http://openindiana.org/mailman/listinfo/openindiana-discuss
[OpenIndiana-discuss] KVM guests hang at boot on oi_151a4
Hello all, I have a machine which was running some KVM guests successfully on oi_151a3, but no longer since updating to oi_151a4. I've tried a Windows 8 VM - when I connect to the qemu VNC display I just get a black screen, which I believe indicates it's hanging at the beginning of the Windows boot process. I've also tried booting pxelinux - that successfully gets the boot image via TFTP, but hangs immediately after that point. Both of these work fine with oi_151a3 using the same configuration. When it happens, one CPU core is permanently pegged at 100%, and kvmstat gives output like the following: pid vcpu | exits : haltx irqx irqwxiox mmiox | irqs emul eptv 7570 | 396890 : 0 6 18 18 0 | 18 0 0 7571 | 0 : 0 0 0 0 0 | 0 0 0 Has anyone else seen anything like this? I'm not certain what information I can provide which might be of relevance, and I'm not sure what my next step should be in trying to debug this; perhaps somebody can give me some pointers? Thanks for your time, Nye ___ OpenIndiana-discuss mailing list OpenIndiana-discuss@openindiana.org http://openindiana.org/mailman/listinfo/openindiana-discuss
Re: [OpenIndiana-discuss] 'pkg image-update' and BEs
On 25 June 2012 15:44, Michael Schuster wrote: > Hi Aneurin, > > I'd expect one of the design goals of the whole image-update process was to > work with as little interruption as possible (we had this in live upgrade > as well, so the historical precedent is fairly clear, IMO anyway): you > could run your update, watch it finish, analyse logs etc., all while the > machine (think "big server") was up and running *completely unchanged*. > Only when/if you're satisfied that the update did what you expected it to > do, you could (schedule a) reboot. IMO that's a much safer approach than > what you describe. Ah, that way of working is new to me, but it does make a lot of sense. Thank you both for your quick replies - it seems a lot clearer now, especially with the distinction between a backup BE and a new BE. ___ OpenIndiana-discuss mailing list OpenIndiana-discuss@openindiana.org http://openindiana.org/mailman/listinfo/openindiana-discuss
[OpenIndiana-discuss] 'pkg image-update' and BEs
Hi folks, I have a basic newbie question: can somebody help me to understand how exactly the boot environments created by 'pkg image-update' work? Lets say I start with the BE 'mysystem'. My initial expectation - obviously incorrect - was that performing the update would take a snapshot (call it 'mysystem-1'), and create a corresponding BE, then apply the relevant updates to the *currently active* BE. Then I would immediately have access to updates that don't require a restart (new application software versions etc.); I can reboot to get the new kernel version, or I can reboot and choose the mysystem-1 BE if anything went wrong. In short, I was expecting the operation to be roughly equivalent to snapshot creation, followed by 'apt-get dist-upgrade'. That obviously isn't the case, but I can't find a clear explanation anywhere of how the process actually works. From observation it appears to be the following: a snapshot and corresponding BE are created, and the update process is applied to that *new* BE. Thus newly installed updates aren't available until rebooting into that new BE. The current BE effectively acts as the 'backup' snapshot, so any other changes to the system (applied to the running environment) not only won't apply to the new BE, but are basically modifying the backup. Hence, updating should be the *very last* thing to do before a reboot, and rebooting ASAP after performing the update is *extremely* important. Is that understanding correct? Assuming so, is it possible to make pkg behave more like my initial expectation? I suppose I could create a snapshot myself using beadm, then tell pkg not to create a new environment, but is that likely to bite me in some nasty way? I'd like a better understanding of why the system works the way it does before trying to fight it :P. Thanks for your time. (PS: Apologies if this list is inappropriate for basic questions like this; let me know if that's the case.) ___ OpenIndiana-discuss mailing list OpenIndiana-discuss@openindiana.org http://openindiana.org/mailman/listinfo/openindiana-discuss
