Date: Mon, 14 Dec 2009 22:39:26 +0100 From: Martin Matuska <mm@FreeBSD.org> To: Borja Marcos <borjam@sarenet.es> Cc: freebsd-fs@freebsd.org, Pawel Jakub Dawidek <pjd@FreeBSD.org>, Ronald Klop <ronald-freebsd8@klop.yi.org> Subject: Re: zfs receive gives: internal error: Argument list too long Message-ID: <4B26B08E.5000203@FreeBSD.org> In-Reply-To: <495F94EF-8F57-440D-8810-F40E40DE69D5@sarenet.es> References: <op.u2df9msz8527sy@82-170-177-25.ip.telfort.nl> <op.u2dgfwap8527sy@82-170-177-25.ip.telfort.nl> <op.u2i2wknf8527sy@82-170-177-25.ip.telfort.nl> <20091029205121.GB3418@garage.freebsd.pl> <9AA2C968-F09D-473D-BD13-F13B3F94ED60@sarenet.es> <20091214154750.GF1666@garage.freebsd.pl> <495F94EF-8F57-440D-8810-F40E40DE69D5@sarenet.es>
next in thread | previous in thread | raw e-mail | index | archive | help
I was unable to reproduce the panic (with 8.0-RELEASE-p1 + Pawel's patch or with my patch). I can split my patch into two Opensolaris changesets - 8986, that is exactly pjd's patch. The other changeset is 7994. BUG ID 6764159: restore_object() makes a call that can block while having a tx open but not yet committed. So to make life easier, I have split this and use 2 patches (that make together my old patch) a) 6764159_restore_blocking.patch b) zfs_recv_E2BIG.patch I have also encountered a problem with recursive zfs snapshots of previsously transferred datasets. On many of my systems, zfs snapshot -r tank@xyz just did not work with the following error: zfs snapshot -r failed because filesystem was busy Patch links: http://mfsbsd.vx.sk/patches/6764159_restore_blocking.patch http://mfsbsd.vx.sk/patches/6462803_zfs_snapshot_busy.patch http://people.freebsd.org/~pjd/patches/zfs_recv_E2BIG.patch Related OpenSolaris links: http://bugs.opensolaris.org/bugdatabase/view_bug.do?bug_id=6462803 (zfs snapshot busy) http://bugs.opensolaris.org/bugdatabase/view_bug.do?bug_id=6764159 (restore_object blocking) http://bugs.opensolaris.org/bugdatabase/view_bug.do?bug_id=6801979 (zfs receive E2BIG) I am running all three patches on about 30-40 servers with 8 CPU cores, amd64 and intensive zfs snapshot -r, intense zfs send/receive operations for several days. No panics or other problems by now. Borja Marcos wrote / napísal(a): > On Dec 14, 2009, at 4:47 PM, Pawel Jakub Dawidek wrote: > > >> On Tue, Nov 03, 2009 at 12:08:54PM +0100, Borja Marcos wrote: >> >>> On Oct 29, 2009, at 9:51 PM, Pawel Jakub Dawidek wrote: >>> >>> It's caused a panic for me on 8.0-RC2/amd64. Seems a new problem, >>> never saw a panic in this situation before. >>> >>> How to reproduce: With /usr/src and /usr/obj in a dataset, just >>> >>> cd /usr/src >>> make clean >>> >>> Instant panic, in less than 20 seconds. >>> >>> Trying to get panic information, unfortunately I'm running on VMWare >>> Fussion and the silly thing doesn't offer the equivalent of a serial >>> console. >>> >> Martin, this is the panic report I was refering to. Could you please try >> to reproduce it? Maybe first with my patch to confirm it is reproducible >> and then with your patch to confirm it has no such problem? >> I'd be very grateful if you could do that. I don't want something to go >> into the tree if there might be a problem with the patch. >> > > It was me, not Martin :) > > I will try to reproduce again. By the way, any news about the zfs receive deadlock when accessing the target dataset? > > > > > > Borja. > > >
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4B26B08E.5000203>