Re: Fwd: [releng_7 tinderbox] failure on amd64/amd64
on 20/05/2011 04:30 Jeremy Chadwick said the following: - Forwarded message from FreeBSD Tinderbox tinder...@freebsd.org - http://tinderbox.freebsd.org/tinderbox-releng_7-RELENG_7-amd64-amd64.full Specific to RELENG_7. Andriy, any fixes committed which haven't shown up on cvsweb yet? If so sorry for jumping the gun. http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/dev/sound/pcm/dsp.c Thank you for drawing my attention to the report. I have acted sloppy again :( Should be fixed in r222113 now. -- Andriy Gapon ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: 8.1R possible zfs snapshot livelock?
On Wed, 2011-05-18 at 14:05 +0200, Borja Marcos wrote: On May 17, 2011, at 1:29 PM, Jeremy Chadwick wrote: * ZFS send | ssh zfs recv results in ZFS subsystem hanging; 8.1-RELEASE; February 2011: http://lists.freebsd.org/pipermail/freebsd-fs/2011-February/010602.html I found a reproducible deadlock condition actually. If you keep some I/O activity on a dataset on which you are receiving a ZFS incremental snapshot at the same time, it can deadlock. Imagine this situation: Two servers, A and B. A dataset on server A is replicated at regular intervals to B, so that you keep a reasonably up to date copy. Something like: (Runnning on server A): zfs snapshot thepool/thedataset@thistime zfs send -Ri thepooll/thedataser@previoustime hepool/thedataset@thistime | ssh serverB zfs receive -d thepool It works, but I suffered a deadlock when one of the periodic daily scripts was running. Doing some tests, I saw that ZFS can deadlock if you do a zfs receive onto a dataset which has some read activity. Disabling atime didn't help either. But if you make sure *not* to access the replicated dataset it works, I haven´t seen it failing otherwise. If you wish to reproduce it, try creating a dataset for /usr/obj, running make buildworld on it, replicating at, say, 30 or 60 second intervals, and keep several scripts (or rsync) reading the target dataset files and just copying them to another place in the usual, classic way. (example: tar cf - . | ( cd /destination tar xf -) Is there a PR for this? I'd like to see it addressed, since read-only I/O on a dataset which is being updated by `zfs recv` is an important part of what we plan to do with ZFS on FreeBSD. -- Best Regards, Luke Marsden CTO, Hybrid Logic Ltd. Web: http://www.hybrid-cluster.com/ Hybrid Web Cluster - cloud web hosting Phone: +447791750420 ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: Heads up: you'll need to do a fresh config KERNEL etc
On 05/19/11 18:53, Rick Macklem wrote: On 05/14/11 20:05, Rick Macklem wrote: Hi, Just a heads up that after a commit going into stable/8 in a few minutes, you'll need to do a fresh kernel build, starting at config GENERIC, including rebuilding the NFS related modules. rick ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org Sensational! With this update, I finally get NFS client performance as good as (or better than) 7.x, and I have a warm, fuzzy feeling about 8.x at last. (Except for SCHED_ULE, which gives terrible performance on a single-core machine with a compute-bound process running in the background.) Thanks! -- George Mitchell There's a weird (and you need to have a weird sense of humour to enjoy it) flick called Stranger than Paradise. Anyhow, the above sounds like good news, although the commit it was related to should have had no effect on perf, from what I can see. Assuming that you are using the regular 8.n client (and not the new one), there have been some commits related to krpc bugs that could have fixed cases which would have caused poor perf., although all of those (except one where a client would hang on a TCP reconnect attempt) are in 8.2. So, happy to hear it works for you now, but have no idea why;-) rick Full disclosure: I was upgrading from 8.2-PRERELEASE, so it might well have been some earlier change instead of this one. -- George ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
