From owner-freebsd-stable@FreeBSD.ORG Sun Jun 7 21:26:17 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 272E21065670 for ; Sun, 7 Jun 2009 21:26:17 +0000 (UTC) (envelope-from 000.fbsd@quip.cz) Received: from elsa.codelab.cz (elsa.codelab.cz [94.124.105.4]) by mx1.freebsd.org (Postfix) with ESMTP id D8BED8FC15 for ; Sun, 7 Jun 2009 21:26:16 +0000 (UTC) (envelope-from 000.fbsd@quip.cz) Received: from localhost (localhost.codelab.cz [127.0.0.1]) by elsa.codelab.cz (Postfix) with ESMTP id 4276919E023; Sun, 7 Jun 2009 23:26:13 +0200 (CEST) Received: from [192.168.1.2] (r5bb235.net.upc.cz [86.49.61.235]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by elsa.codelab.cz (Postfix) with ESMTPSA id D4D4919E019; Sun, 7 Jun 2009 23:26:10 +0200 (CEST) Message-ID: <4A2C3073.3020700@quip.cz> Date: Sun, 07 Jun 2009 23:26:11 +0200 From: Miroslav Lachman <000.fbsd@quip.cz> User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.12) Gecko/20050915 X-Accept-Language: cz, cs, en, en-us MIME-Version: 1.0 To: claudiu vasadi References: <4f760c6a0906071130k7fb7d738hcd0d109868fd9631@mail.gmail.com> <4f760c6a0906071306g129a0b81sd41a2f84000c2609@mail.gmail.com> In-Reply-To: <4f760c6a0906071306g129a0b81sd41a2f84000c2609@mail.gmail.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-stable@freebsd.org Subject: Re: IBM TSM server X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 07 Jun 2009 21:26:17 -0000 claudiu vasadi wrote: > On Sun, Jun 7, 2009 at 9:38 PM, Wojciech Puchar < > wojtek@wojtek.tensor.gdynia.pl> wrote: > > >>Jun 7 21:10:47 da1 kernel: ad6: detached >> >>>Jun 7 21:10:47 da1 kernel: g_vfs_done():ad6s1d[READ(offset=86540058624, >>>length=16384)]error = 6 >>>Jun 7 21:10:47 da1 kernel: g_vfs_done():ad6s1e[READ(offset=63203147776, >>>length=16384)]error = 6 >>>Jun 7 21:10:47 da1 kernel: g_vfs_done():ad6s1d[READ(offset=86539010048, >>>length=16384)]error = 6 >>> >> >> >>isn;t it trying to read past the end of disk? >> > > > Hmm.. I guess you are correct. The question is why is it doing this ? It can be caused by wrong disk label (partitioning). Some partition made bigger then real media [disk]. You can see the label by command disklabel ad6s1 and then compare size & offset values with `diskinfo -v ad6` > And on both drives ? > > > Feels to me a problem for the developers. HDD's didn't give me one problem > since the day the got installed. I'm not saing that they are very good HDD's > (in fact they are quite cheap ones) but fail all of a sudden ? And leaving > this asside, they dnt give one error on masive transfers and still have very > good transfer speed. What I'm saing is that hdd failure could be a > posibility of course, but a unlikely one at this point. > > My problem is that I do not know what tehnik TSM server uses for creating > those files because at some point it fails. Strainge thing is that it goes > over 1G. First it creates the file and then it populates the file up until > the given limit (25G in this case). > > I will try something tomorow. I will again start the tsm server to add the > space (the 25G free space) to the pool and will monitor the file size up > until the OS crashes. I'm very curious what's the size of the file when the > OS crashes.