From owner-freebsd-fs@FreeBSD.ORG Tue Feb 24 05:31:56 2009 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id EB5D4106564A for ; Tue, 24 Feb 2009 05:31:56 +0000 (UTC) (envelope-from dimitar.vassilev@gmail.com) Received: from yx-out-2324.google.com (yx-out-2324.google.com [74.125.44.28]) by mx1.freebsd.org (Postfix) with ESMTP id A47EC8FC0C for ; Tue, 24 Feb 2009 05:31:56 +0000 (UTC) (envelope-from dimitar.vassilev@gmail.com) Received: by yx-out-2324.google.com with SMTP id 31so862134yxl.13 for ; Mon, 23 Feb 2009 21:31:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=rHXoYHd/417Xs9YC/6miWnRv5oQv6Vu/OjuYkhyfPaY=; b=nY6oU/8QrMQrH5ibyxalbnSiciSm/ZuKb5YMpwJKwFaeaXfVgRqqdCJUWGdV8sfCU5 Kzmk2wRIn8yyYDtw3FmLfzSqtKZh1KpL5+8s3flVNMgsLiUOHE0GDq2GQzxRypRQqOyf ZxW1PFyYR7kROCJJ4Ptx8DsOTYkHm9GdJzW2U= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=QmtmM2zpLGc+dva+tEUiBCnPf8NhaUgkfXrg9IqU7c7/0T9ShYqz7+RWnqTXeO0ag/ NRnPzXkL2C8qscDDbve3DsMACCDrcqg8/VFB11ukajS6mlnO7+ODep42aLCuqHLclZqO mmvpJXesHHNRMay9FAIrd1cUI9FNzwa8nvKYo= MIME-Version: 1.0 Received: by 10.150.225.17 with SMTP id x17mr5995806ybg.248.1235451751207; Mon, 23 Feb 2009 21:02:31 -0800 (PST) In-Reply-To: <49A3357A.7080008@telus.net> References: <49A10626.8060705@telus.net> <49A3357A.7080008@telus.net> Date: Tue, 24 Feb 2009 07:02:31 +0200 Message-ID: <59adc1a0902232102q6c0f6034r354ff9ad3a2b3222@mail.gmail.com> From: Dimitar Vasilev To: Carl Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-fs@freebsd.org, Robert Watson Subject: Re: UFS2 and/or sparse file bug causing copy process to land in 'D'' state? X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Feb 2009 05:31:57 -0000 2009/2/24 Carl > Robert Watson wrote: > >> It would be interesting to get kernel stack traces of the involved >> processes/threads; there are various ways to do this, such as using DDB. If >> you have a kernel.symbols for the kernel, then you can run kgdb on >> kernel.symbols and /dev/mem to generate traces without interrupting >> operation (although if the system is in the throes of deadlocking, that may >> not be a concern or even possible). You can also use procstat -kk to >> retrieve kernel stack traces, with a bit less information (such as no >> arguments) to help narrow things down more. >> >> Unfortunately, debugging this type of problem, as you've intuited, is best >> done with serial console access and a local box so that the debugging >> information can be extracted. It would be interesting to know if you can >> force a crashdump on the box to get the information for post-mortem >> debugging. This may be possible using "reboot -d" -- I've never used this, >> but have every reason to think it will work. >> > > I have both a local and remote box. The problems I'm seeing are all > occurring on the local box because as yet I cannot afford to cause them on a > remote box. > > If you were to guess I've never used DDB or any other kernel debugging, > you'd be spot on. I'm currently running the 7.0-RELEASE GENERIC kernel. I > see a /boot/kernel/kernel.symbols in the filesystem. The system is nominally > headless with a serial console, although I primarily use SSH. Even if I knew > what to do with them, actually collecting kernel dumps is a hit or miss > affair because of gmirror, but this particular problem doesn't cause kernel > core dumps on its own (thankfully, since gmirror resyncs take a long time on > terabyte drives). So, if you were able to clearly spell out the stripped > down steps I should take in conjunction with my earlier truncate sequence > and if it doesn't require rebuilding the kernel, I might be able to > accommodate. Learning all about kernel debugging would be interesting but > doesn't fit in my schedule right now. > > Anyone willing to attempt to reproduce this problem on their system? > > > Carl / K0802647 > _______________________________________________ > freebsd-fs@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-fs > To unsubscribe, send any mail to "freebsd-fs-unsubscribe@freebsd.org" > Hi Carl, How about a soekris board, a USB stick and a null modem cable for collecting data from the local box? Or a laptop with a USB to serial adapter ? Cheers, Dimitar