From owner-freebsd-fs@FreeBSD.ORG Sun Jul 1 19:51:25 2007 Return-Path: X-Original-To: freebsd-fs@freebsd.org Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id ED68A16A400 for ; Sun, 1 Jul 2007 19:51:25 +0000 (UTC) (envelope-from raaf@zen.mooo.com) Received: from smtp-2.orange.nl (smtp-2.orange.nl [193.252.22.242]) by mx1.freebsd.org (Postfix) with ESMTP id 7900513C45B for ; Sun, 1 Jul 2007 19:51:24 +0000 (UTC) (envelope-from raaf@zen.mooo.com) Received: from smtp-2.orange.nl (mwinf6106 [172.22.153.34]) by mwinf6105.orange.nl (SMTP Server) with ESMTP id 6AA53200028A for ; Sun, 1 Jul 2007 21:24:41 +0200 (CEST) Received: from me-wanadoo.net (localhost [127.0.0.1]) by mwinf6106.orange.nl (SMTP Server) with ESMTP id 3060A700008B for ; Sun, 1 Jul 2007 21:24:39 +0200 (CEST) Received: from zen.mooo.com (s559292f8.adsl.wanadoo.nl [85.146.146.248]) by mwinf6106.orange.nl (SMTP Server) with ESMTP id 152C77000084; Sun, 1 Jul 2007 21:24:38 +0200 (CEST) X-ME-UUID: 20070701192439868.152C77000084@mwinf6106.orange.nl Received: from zen.mooo.com (zen.mooo.com [127.0.0.1]) by zen.mooo.com (Postfix) with ESMTP id F211D21; Sun, 1 Jul 2007 21:24:37 +0200 (CEST) Message-ID: <4687FF75.3000108@zen.mooo.com> Date: Sun, 01 Jul 2007 21:24:37 +0200 From: Raaf User-Agent: Thunderbird 1.5.0.9 (X11/20070103) MIME-Version: 1.0 To: freebsd-stable@freebsd.org, freebsd-fs@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Subject: Cannot mount Sony Ericsson mobile phone, msdosfs too restrictive? 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: Sun, 01 Jul 2007 19:51:26 -0000 Hi, i got a Sony Ericsson mobile phone that came with a pre-formatted memory stick that i'm unable to mount in FreeBSD (it mounts fine in Linux). After investigating i found out that the FreeBSD msdsofs driver bails out on the following code (the pmp->pm_Heads being zero): ---------------------------------- if (!pmp->pm_BytesPerSec || !SecPerClust || !pmp->pm_Heads #ifdef PC98 || !pmp->pm_SecPerTrack || pmp->pm_SecPerTrack > 255) { #else || !pmp->pm_SecPerTrack || pmp->pm_SecPerTrack > 63) { #endif error = EINVAL; goto error_exit; } ---------------------------------- Removing the check for pmp->pm_Heads fixes it for me. Is the check for pmp->pm_Heads really necessary? Grepping through the msdosfs sources i can only see it being used for validation and not used in any calculation (the same applies for the pmp->pm_SecPerTrack value) --- sys/fs/msdosfs/msdosfs_vfsops.c.orig Sun Jul 1 20:42:14 2007 +++ sys/fs/msdosfs/msdosfs_vfsops.c Sun Jul 1 20:46:57 2007 @@ -483,7 +483,6 @@ /* XXX - We should probably check more values here */ if (!pmp->pm_BytesPerSec || !SecPerClust - || !pmp->pm_Heads #ifdef PC98 || !pmp->pm_SecPerTrack || pmp->pm_SecPerTrack > 255) { #else From owner-freebsd-fs@FreeBSD.ORG Sun Jul 1 20:33:39 2007 Return-Path: X-Original-To: freebsd-fs@freebsd.org Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 4B24516A468 for ; Sun, 1 Jul 2007 20:33:39 +0000 (UTC) (envelope-from dennis.melentyev@gmail.com) Received: from wa-out-1112.google.com (wa-out-1112.google.com [209.85.146.181]) by mx1.freebsd.org (Postfix) with ESMTP id 25FDC13C4BF for ; Sun, 1 Jul 2007 20:33:39 +0000 (UTC) (envelope-from dennis.melentyev@gmail.com) Received: by wa-out-1112.google.com with SMTP id j37so2035261waf for ; Sun, 01 Jul 2007 13:33:39 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=pa42MFIQvTpt1gGtJS99CT0c+E+Qi/xTJirXaKUiBTUelm5NZtB87ppOM8ChN+Fv1V3gUaYm8kWmDLTDN4JSMXKB/QXZkb9Pwf7F9HYCcHLfFtJCZUzwNpyXzrZWvc1pHHHDHW4r4c7uW2U83VVAk10ZBDVG4HTb5WIC4lFLWKs= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=U30M+bjG8lk+3wbFR7TI9QwsY4mVZ71F2C3ikXewnkanz4D1xLOQHAxZc8VYGKu3NeDJnLoP1S20yAi4dFvBKj+C7+npkzY11uwVXkyaYbHh/jfAtsrbW9DyW62vpWc9XlkcoLt2rBrKxv2u2uV2RzwIlJvHPH+xaL4iQKEXx5g= Received: by 10.114.192.1 with SMTP id p1mr4492453waf.1183320307012; Sun, 01 Jul 2007 13:05:07 -0700 (PDT) Received: by 10.115.78.2 with HTTP; Sun, 1 Jul 2007 13:05:06 -0700 (PDT) Message-ID: Date: Sun, 1 Jul 2007 23:05:06 +0300 From: "Dennis Melentyev" To: Raaf In-Reply-To: <4687FF75.3000108@zen.mooo.com> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <4687FF75.3000108@zen.mooo.com> Cc: freebsd-fs@freebsd.org, freebsd-stable@freebsd.org Subject: Re: Cannot mount Sony Ericsson mobile phone, msdosfs too restrictive? 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: Sun, 01 Jul 2007 20:33:39 -0000 Well, had the same problem. For me, it looks like SE is using FAT12 (!!!Not 16!!!) on a devive larger than 32MB. Could have something slipped off my mind, but quite close. It is a BROKEN msdosfs on a stick. Just re-formated 1Gb flash with FAT32 using card reader and both K750i and FreeBSD are happy. 2007/7/1, Raaf : > Hi, i got a Sony Ericsson mobile phone that came with a pre-formatted > memory stick that i'm unable to mount in FreeBSD (it mounts fine in > Linux). > > After investigating i found out that the FreeBSD msdsofs driver bails > out on the following code (the pmp->pm_Heads being zero): > > ---------------------------------- > if (!pmp->pm_BytesPerSec || !SecPerClust > || !pmp->pm_Heads > #ifdef PC98 > || !pmp->pm_SecPerTrack || pmp->pm_SecPerTrack > 255) { > #else > || !pmp->pm_SecPerTrack || pmp->pm_SecPerTrack > 63) { > #endif > error = EINVAL; > goto error_exit; > } > ---------------------------------- > > Removing the check for pmp->pm_Heads fixes it for me. > > Is the check for pmp->pm_Heads really necessary? > > Grepping through the msdosfs sources i can only see it being used for > validation and not used in any calculation (the same applies for the > pmp->pm_SecPerTrack value) > > > --- sys/fs/msdosfs/msdosfs_vfsops.c.orig Sun Jul 1 20:42:14 2007 > +++ sys/fs/msdosfs/msdosfs_vfsops.c Sun Jul 1 20:46:57 2007 > @@ -483,7 +483,6 @@ > > /* XXX - We should probably check more values here */ > if (!pmp->pm_BytesPerSec || !SecPerClust > - || !pmp->pm_Heads > #ifdef PC98 > || !pmp->pm_SecPerTrack || pmp->pm_SecPerTrack > 255) { > #else > > > _______________________________________________ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" > -- Dennis Melentyev From owner-freebsd-fs@FreeBSD.ORG Sun Jul 1 22:07:40 2007 Return-Path: X-Original-To: freebsd-fs@freebsd.org Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id E21AC16A400 for ; Sun, 1 Jul 2007 22:07:40 +0000 (UTC) (envelope-from raaf@zen.mooo.com) Received: from smtp-4.orange.nl (smtp-4.orange.nl [193.252.22.249]) by mx1.freebsd.org (Postfix) with ESMTP id A220113C489 for ; Sun, 1 Jul 2007 22:07:40 +0000 (UTC) (envelope-from raaf@zen.mooo.com) Received: from me-wanadoo.net (localhost [127.0.0.1]) by mwinf6302.orange.nl (SMTP Server) with ESMTP id 1CD1D700008D for ; Mon, 2 Jul 2007 00:07:39 +0200 (CEST) Received: from zen.mooo.com (s559292f8.adsl.wanadoo.nl [85.146.146.248]) by mwinf6302.orange.nl (SMTP Server) with ESMTP id 076D37000085; Mon, 2 Jul 2007 00:07:38 +0200 (CEST) X-ME-UUID: 20070701220739304.076D37000085@mwinf6302.orange.nl Received: from zen.mooo.com (zen.mooo.com [127.0.0.1]) by zen.mooo.com (Postfix) with ESMTP id 176616F; Mon, 2 Jul 2007 00:07:38 +0200 (CEST) Message-ID: <468825A9.80200@zen.mooo.com> Date: Mon, 02 Jul 2007 00:07:37 +0200 From: Raaf User-Agent: Thunderbird 1.5.0.9 (X11/20070103) MIME-Version: 1.0 To: Brian Chu References: <4687FF75.3000108@zen.mooo.com> <47a4f3080707011454m6e06c97bu4764b32a65160ad6@mail.gmail.com> In-Reply-To: <47a4f3080707011454m6e06c97bu4764b32a65160ad6@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Dennis Melentyev , freebsd-stable@freebsd.org, freebsd-fs@freebsd.org Subject: Re: Cannot mount Sony Ericsson mobile phone, msdosfs too restrictive? 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: Sun, 01 Jul 2007 22:07:41 -0000 Brian Chu wrote: > Raaf, > > What's the size of the memory stick? Is it 32MB like Dennis has? > It's a 64MB memory stick using FAT12. > The check for the field that affected you isn't critical to msdosfs' > operation, but the field itself is specified to be non-zero. > Konstantin, is it alright to remove this field? > It seems there are more people having problems with the sanity checking code of msdosfs, see also this related pr: http://www.freebsd.org/cgi/query-pr.cgi?pr=93860 From owner-freebsd-fs@FreeBSD.ORG Sun Jul 1 22:21:25 2007 Return-Path: X-Original-To: freebsd-fs@freebsd.org Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id E0E4B16A400 for ; Sun, 1 Jul 2007 22:21:25 +0000 (UTC) (envelope-from soc@hbar.us) Received: from ug-out-1314.google.com (ug-out-1314.google.com [66.249.92.172]) by mx1.freebsd.org (Postfix) with ESMTP id 81B1913C489 for ; Sun, 1 Jul 2007 22:21:25 +0000 (UTC) (envelope-from soc@hbar.us) Received: by ug-out-1314.google.com with SMTP id o4so773118uge for ; Sun, 01 Jul 2007 15:21:24 -0700 (PDT) Received: by 10.78.180.16 with SMTP id c16mr2658034huf.1183326898799; Sun, 01 Jul 2007 14:54:58 -0700 (PDT) Received: by 10.78.138.5 with HTTP; Sun, 1 Jul 2007 14:54:58 -0700 (PDT) Message-ID: <47a4f3080707011454m6e06c97bu4764b32a65160ad6@mail.gmail.com> Date: Sun, 1 Jul 2007 17:54:58 -0400 From: "Brian Chu" To: Raaf , "Kostik Belousov" In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <4687FF75.3000108@zen.mooo.com> Cc: freebsd-fs@freebsd.org, Dennis Melentyev , freebsd-stable@freebsd.org Subject: Re: Cannot mount Sony Ericsson mobile phone, msdosfs too restrictive? 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: Sun, 01 Jul 2007 22:21:26 -0000 Raaf, What's the size of the memory stick? Is it 32MB like Dennis has? The check for the field that affected you isn't critical to msdosfs' operation, but the field itself is specified to be non-zero. Konstantin, is it alright to remove this field? Brian On 7/1/07, Dennis Melentyev wrote: > Well, had the same problem. > For me, it looks like SE is using FAT12 (!!!Not 16!!!) on a devive > larger than 32MB. Could have something slipped off my mind, but quite > close. It is a BROKEN msdosfs on a stick. > > Just re-formated 1Gb flash with FAT32 using card reader and both K750i > and FreeBSD are happy. > > 2007/7/1, Raaf : > > Hi, i got a Sony Ericsson mobile phone that came with a pre-formatted > > memory stick that i'm unable to mount in FreeBSD (it mounts fine in > > Linux). > > > > After investigating i found out that the FreeBSD msdsofs driver bails > > out on the following code (the pmp->pm_Heads being zero): > > > > ---------------------------------- > > if (!pmp->pm_BytesPerSec || !SecPerClust > > || !pmp->pm_Heads > > #ifdef PC98 > > || !pmp->pm_SecPerTrack || pmp->pm_SecPerTrack > 255) { > > #else > > || !pmp->pm_SecPerTrack || pmp->pm_SecPerTrack > 63) { > > #endif > > error = EINVAL; > > goto error_exit; > > } > > ---------------------------------- > > > > Removing the check for pmp->pm_Heads fixes it for me. > > > > Is the check for pmp->pm_Heads really necessary? > > > > Grepping through the msdosfs sources i can only see it being used for > > validation and not used in any calculation (the same applies for the > > pmp->pm_SecPerTrack value) > > > > > > --- sys/fs/msdosfs/msdosfs_vfsops.c.orig Sun Jul 1 20:42:14 2007 > > +++ sys/fs/msdosfs/msdosfs_vfsops.c Sun Jul 1 20:46:57 2007 > > @@ -483,7 +483,6 @@ > > > > /* XXX - We should probably check more values here */ > > if (!pmp->pm_BytesPerSec || !SecPerClust > > - || !pmp->pm_Heads > > #ifdef PC98 > > || !pmp->pm_SecPerTrack || pmp->pm_SecPerTrack > 255) { > > #else > > > > > > _______________________________________________ > > freebsd-stable@freebsd.org mailing list > > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > > To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" > > > > > -- > Dennis Melentyev > _______________________________________________ > 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" > From owner-freebsd-fs@FreeBSD.ORG Mon Jul 2 03:30:24 2007 Return-Path: X-Original-To: freebsd-fs@freebsd.org Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 1413516A421; Mon, 2 Jul 2007 03:30:24 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from relay02.kiev.sovam.com (relay02.kiev.sovam.com [62.64.120.197]) by mx1.freebsd.org (Postfix) with ESMTP id 9A52D13C46E; Mon, 2 Jul 2007 03:30:23 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from [89.162.146.170] (helo=skuns.kiev.zoral.com.ua) by relay02.kiev.sovam.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.67) (envelope-from ) id 1I5CcF-0009Gr-4G; Mon, 02 Jul 2007 06:30:21 +0300 Received: from deviant.kiev.zoral.com.ua (root@deviant.kiev.zoral.com.ua [10.1.1.148]) by skuns.kiev.zoral.com.ua (8.14.1/8.14.1) with ESMTP id l623U20U083904 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 2 Jul 2007 06:30:02 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: from deviant.kiev.zoral.com.ua (kostik@localhost [127.0.0.1]) by deviant.kiev.zoral.com.ua (8.14.1/8.14.1) with ESMTP id l623U7V1015921; Mon, 2 Jul 2007 06:30:07 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by deviant.kiev.zoral.com.ua (8.14.1/8.14.1/Submit) id l623U7Dn015920; Mon, 2 Jul 2007 06:30:07 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: deviant.kiev.zoral.com.ua: kostik set sender to kostikbel@gmail.com using -f Date: Mon, 2 Jul 2007 06:30:07 +0300 From: Kostik Belousov To: Brian Chu Message-ID: <20070702033007.GN2268@deviant.kiev.zoral.com.ua> References: <4687FF75.3000108@zen.mooo.com> <47a4f3080707011454m6e06c97bu4764b32a65160ad6@mail.gmail.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="i7uJIdOrCTgA6ZgY" Content-Disposition: inline In-Reply-To: <47a4f3080707011454m6e06c97bu4764b32a65160ad6@mail.gmail.com> User-Agent: Mutt/1.4.2.2i X-Virus-Scanned: ClamAV version 0.90.2, clamav-milter version 0.90.2 on skuns.kiev.zoral.com.ua X-Virus-Status: Clean X-Spam-Status: No, score=-1.4 required=5.0 tests=ALL_TRUSTED autolearn=failed version=3.1.8 X-Spam-Checker-Version: SpamAssassin 3.1.8 (2007-02-13) on skuns.kiev.zoral.com.ua X-Scanner-Signature: 6bd56f30920205a35a58b455a86ead09 X-DrWeb-checked: yes X-SpamTest-Envelope-From: kostikbel@gmail.com X-SpamTest-Group-ID: 00000000 X-SpamTest-Header: Not Detected X-SpamTest-Info: Profiles 1187 [June 28 2007] X-SpamTest-Info: helo_type=3 X-SpamTest-Method: none X-SpamTest-Rate: 0 X-SpamTest-Status: Not detected X-SpamTest-Status-Extended: not_detected X-SpamTest-Version: SMTP-Filter Version 3.0.0 [0255], KAS30/Release Cc: freebsd-fs@freebsd.org, Dennis Melentyev , Raaf , freebsd-stable@freebsd.org Subject: Re: Cannot mount Sony Ericsson mobile phone, msdosfs too restrictive? 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: Mon, 02 Jul 2007 03:30:24 -0000 --i7uJIdOrCTgA6ZgY Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sun, Jul 01, 2007 at 05:54:58PM -0400, Brian Chu wrote: > Raaf, >=20 > What's the size of the memory stick? Is it 32MB like Dennis has? >=20 > The check for the field that affected you isn't critical to msdosfs' > operation, but the field itself is specified to be non-zero. > Konstantin, is it alright to remove this field? >=20 Brian, I would expect to get the answer from you. In any case, you could do this on your branch and have tested it for some time. >=20 > On 7/1/07, Dennis Melentyev wrote: > >Well, had the same problem. > >For me, it looks like SE is using FAT12 (!!!Not 16!!!) on a devive > >larger than 32MB. Could have something slipped off my mind, but quite > >close. It is a BROKEN msdosfs on a stick. > > > >Just re-formated 1Gb flash with FAT32 using card reader and both K750i > >and FreeBSD are happy. > > > >2007/7/1, Raaf : > >> Hi, i got a Sony Ericsson mobile phone that came with a pre-formatted > >> memory stick that i'm unable to mount in FreeBSD (it mounts fine in > >> Linux). > >> > >> After investigating i found out that the FreeBSD msdsofs driver bails > >> out on the following code (the pmp->pm_Heads being zero): > >> > >> ---------------------------------- > >> if (!pmp->pm_BytesPerSec || !SecPerClust > >> || !pmp->pm_Heads > >> #ifdef PC98 > >> || !pmp->pm_SecPerTrack || pmp->pm_SecPerTrack > 255) { > >> #else > >> || !pmp->pm_SecPerTrack || pmp->pm_SecPerTrack > 63) { > >> #endif > >> error =3D EINVAL; > >> goto error_exit; > >> } > >> ---------------------------------- > >> > >> Removing the check for pmp->pm_Heads fixes it for me. > >> > >> Is the check for pmp->pm_Heads really necessary? > >> > >> Grepping through the msdosfs sources i can only see it being used for > >> validation and not used in any calculation (the same applies for the > >> pmp->pm_SecPerTrack value) > >> > >> > >> --- sys/fs/msdosfs/msdosfs_vfsops.c.orig Sun Jul 1 20:42:14 20= 07 > >> +++ sys/fs/msdosfs/msdosfs_vfsops.c Sun Jul 1 20:46:57 2007 > >> @@ -483,7 +483,6 @@ > >> > >> /* XXX - We should probably check more values here */ > >> if (!pmp->pm_BytesPerSec || !SecPerClust > >> - || !pmp->pm_Heads > >> #ifdef PC98 > >> || !pmp->pm_SecPerTrack || pmp->pm_SecPerTrack > 255) { > >> #else > >> > >> > >> _______________________________________________ > >> freebsd-stable@freebsd.org mailing list > >> http://lists.freebsd.org/mailman/listinfo/freebsd-stable > >> To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.o= rg" > >> > > > > > >-- > >Dennis Melentyev > >_______________________________________________ > >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" > > --i7uJIdOrCTgA6ZgY Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (FreeBSD) iD8DBQFGiHE+C3+MBN1Mb4gRApbfAKCaA1pTDGVdHHE1CtrNwwwTwV8aBQCghmdz UcrUYg0NkjVUAKekgDV4ow0= =JLhH -----END PGP SIGNATURE----- --i7uJIdOrCTgA6ZgY-- From owner-freebsd-fs@FreeBSD.ORG Mon Jul 2 06:01:54 2007 Return-Path: X-Original-To: freebsd-fs@freebsd.org Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id C9C8916A46F for ; Mon, 2 Jul 2007 06:01:54 +0000 (UTC) (envelope-from soc@hbar.us) Received: from wx-out-0506.google.com (wx-out-0506.google.com [66.249.82.229]) by mx1.freebsd.org (Postfix) with ESMTP id 9228B13C480 for ; Mon, 2 Jul 2007 06:01:54 +0000 (UTC) (envelope-from soc@hbar.us) Received: by wx-out-0506.google.com with SMTP id i29so645801wxd for ; Sun, 01 Jul 2007 23:01:52 -0700 (PDT) Received: by 10.78.81.20 with SMTP id e20mr2714721hub.1183356111624; Sun, 01 Jul 2007 23:01:51 -0700 (PDT) Received: by 10.78.138.5 with HTTP; Sun, 1 Jul 2007 23:01:51 -0700 (PDT) Message-ID: <47a4f3080707012301q200c27efo8115f13ac1339d3@mail.gmail.com> Date: Mon, 2 Jul 2007 02:01:51 -0400 From: "Brian Chu" To: Raaf , "Dennis Melentyev" In-Reply-To: <468825A9.80200@zen.mooo.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <4687FF75.3000108@zen.mooo.com> <47a4f3080707011454m6e06c97bu4764b32a65160ad6@mail.gmail.com> <468825A9.80200@zen.mooo.com> Cc: freebsd-fs@freebsd.org, freebsd-stable@freebsd.org Subject: Re: Cannot mount Sony Ericsson mobile phone, msdosfs too restrictive? 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: Mon, 02 Jul 2007 06:01:54 -0000 Raaf, Dennis, I've taken pmp->pm_Heads out my branch, but it's not ready for a commit. Raaf, if you could give me a hexdump of the bootsector, I'd appreciate it. `hexdump -Cn1024 /dev/...` should do. Thanks, Brian On 7/1/07, Raaf wrote: > Brian Chu wrote: > > Raaf, > > > > What's the size of the memory stick? Is it 32MB like Dennis has? > > > > It's a 64MB memory stick using FAT12. > > > The check for the field that affected you isn't critical to msdosfs' > > operation, but the field itself is specified to be non-zero. > > Konstantin, is it alright to remove this field? > > > > It seems there are more people having problems with the sanity checking > code of msdosfs, see also this related pr: > > http://www.freebsd.org/cgi/query-pr.cgi?pr=93860 > > From owner-freebsd-fs@FreeBSD.ORG Mon Jul 2 11:48:59 2007 Return-Path: X-Original-To: freebsd-fs@freebsd.org Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 05C0816A41F for ; Mon, 2 Jul 2007 11:48:59 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [209.31.154.42]) by mx1.freebsd.org (Postfix) with ESMTP id A4FD713C457 for ; Mon, 2 Jul 2007 11:48:58 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from fledge.watson.org (fledge.watson.org [209.31.154.41]) by cyrus.watson.org (Postfix) with ESMTP id C4B3A47D39; Mon, 2 Jul 2007 07:27:17 -0400 (EDT) Date: Mon, 2 Jul 2007 12:27:17 +0100 (BST) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: Brian Chu In-Reply-To: <47a4f3080707011454m6e06c97bu4764b32a65160ad6@mail.gmail.com> Message-ID: <20070702122548.K29272@fledge.watson.org> References: <4687FF75.3000108@zen.mooo.com> <47a4f3080707011454m6e06c97bu4764b32a65160ad6@mail.gmail.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-fs@freebsd.org, Raaf , freebsd-stable@freebsd.org, Dennis Melentyev Subject: Re: Cannot mount Sony Ericsson mobile phone, msdosfs too restrictive? 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: Mon, 02 Jul 2007 11:48:59 -0000 On Sun, 1 Jul 2007, Brian Chu wrote: > What's the size of the memory stick? Is it 32MB like Dennis has? > > The check for the field that affected you isn't critical to msdosfs' > operation, but the field itself is specified to be non-zero. Konstantin, is > it alright to remove this field? It turns out that quite a bit of our historical sanity checking on msdosfs is too conservative when applied to the highly diverse set of FAT file systems in the field. I think it would be useful for someone(tm) to compare the sanity checks in our version of msdosfs and the checks in the Darwin version and see what they've had to remove. Robert N M Watson Computer Laboratory University of Cambridge > > Brian > > On 7/1/07, Dennis Melentyev wrote: >> Well, had the same problem. >> For me, it looks like SE is using FAT12 (!!!Not 16!!!) on a devive >> larger than 32MB. Could have something slipped off my mind, but quite >> close. It is a BROKEN msdosfs on a stick. >> >> Just re-formated 1Gb flash with FAT32 using card reader and both K750i >> and FreeBSD are happy. >> >> 2007/7/1, Raaf : >> > Hi, i got a Sony Ericsson mobile phone that came with a pre-formatted >> > memory stick that i'm unable to mount in FreeBSD (it mounts fine in >> > Linux). >> > >> > After investigating i found out that the FreeBSD msdsofs driver bails >> > out on the following code (the pmp->pm_Heads being zero): >> > >> > ---------------------------------- >> > if (!pmp->pm_BytesPerSec || !SecPerClust >> > || !pmp->pm_Heads >> > #ifdef PC98 >> > || !pmp->pm_SecPerTrack || pmp->pm_SecPerTrack > 255) { >> > #else >> > || !pmp->pm_SecPerTrack || pmp->pm_SecPerTrack > 63) { >> > #endif >> > error = EINVAL; >> > goto error_exit; >> > } >> > ---------------------------------- >> > >> > Removing the check for pmp->pm_Heads fixes it for me. >> > >> > Is the check for pmp->pm_Heads really necessary? >> > >> > Grepping through the msdosfs sources i can only see it being used for >> > validation and not used in any calculation (the same applies for the >> > pmp->pm_SecPerTrack value) >> > >> > >> > --- sys/fs/msdosfs/msdosfs_vfsops.c.orig Sun Jul 1 20:42:14 2007 >> > +++ sys/fs/msdosfs/msdosfs_vfsops.c Sun Jul 1 20:46:57 2007 >> > @@ -483,7 +483,6 @@ >> > >> > /* XXX - We should probably check more values here */ >> > if (!pmp->pm_BytesPerSec || !SecPerClust >> > - || !pmp->pm_Heads >> > #ifdef PC98 >> > || !pmp->pm_SecPerTrack || pmp->pm_SecPerTrack > 255) { >> > #else >> > >> > >> > _______________________________________________ >> > freebsd-stable@freebsd.org mailing list >> > http://lists.freebsd.org/mailman/listinfo/freebsd-stable >> > To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" >> > >> >> >> -- >> Dennis Melentyev >> _______________________________________________ >> 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" >> > _______________________________________________ > 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" > From owner-freebsd-fs@FreeBSD.ORG Mon Jul 2 16:33:42 2007 Return-Path: X-Original-To: freebsd-fs@freebsd.org Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id CEBA316A469 for ; Mon, 2 Jul 2007 16:33:42 +0000 (UTC) (envelope-from soc@hbar.us) Received: from ik-out-1112.google.com (ik-out-1112.google.com [66.249.90.183]) by mx1.freebsd.org (Postfix) with ESMTP id 692C113C4AD for ; Mon, 2 Jul 2007 16:33:42 +0000 (UTC) (envelope-from soc@hbar.us) Received: by ik-out-1112.google.com with SMTP id c21so1258093ika for ; Mon, 02 Jul 2007 09:33:41 -0700 (PDT) Received: by 10.78.181.13 with SMTP id d13mr3036099huf.1183394020777; Mon, 02 Jul 2007 09:33:40 -0700 (PDT) Received: by 10.78.138.5 with HTTP; Mon, 2 Jul 2007 09:33:40 -0700 (PDT) Message-ID: <47a4f3080707020933v745a00c9s756f46e59fc2b947@mail.gmail.com> Date: Mon, 2 Jul 2007 12:33:40 -0400 From: "Brian Chu" To: "Robert Watson" In-Reply-To: <20070702122548.K29272@fledge.watson.org> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <4687FF75.3000108@zen.mooo.com> <47a4f3080707011454m6e06c97bu4764b32a65160ad6@mail.gmail.com> <20070702122548.K29272@fledge.watson.org> Cc: freebsd-fs@freebsd.org, Raaf , freebsd-stable@freebsd.org, Dennis Melentyev Subject: Re: Cannot mount Sony Ericsson mobile phone, msdosfs too restrictive? 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: Mon, 02 Jul 2007 16:33:42 -0000 Robert, > the field. I think it would be useful for someone(tm) to compare the sanity > checks in our version of msdosfs and the checks in the Darwin version and see > what they've had to remove. Will do. Thanks, Brian From owner-freebsd-fs@FreeBSD.ORG Mon Jul 2 20:30:58 2007 Return-Path: X-Original-To: freebsd-fs@freebsd.org Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 0DC2016A421 for ; Mon, 2 Jul 2007 20:30:58 +0000 (UTC) (envelope-from dennis.melentyev@gmail.com) Received: from wa-out-1112.google.com (wa-out-1112.google.com [209.85.146.176]) by mx1.freebsd.org (Postfix) with ESMTP id DA42213C465 for ; Mon, 2 Jul 2007 20:30:57 +0000 (UTC) (envelope-from dennis.melentyev@gmail.com) Received: by wa-out-1112.google.com with SMTP id j37so2454014waf for ; Mon, 02 Jul 2007 13:30:57 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=Qe3H5MH5oDikfkYSkRpoccZCC1LyhGoWvWZl6uHUGYjTslX9bS1f2MqwDjXzegCRfJGaBClD3Fi0or8c5HRHNj5+/PGmOLADAJliLn3PXmcrD+5oEPahBGfmQ+XVBnT7/yHYKABQXMAtO6N8HJljGs5B2L0FX10ddBkUzrz3FOg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=B39OU6H4NXG6GsLsJLOxHxQFbG+NYK/5gbSUJrnq0dfoXy4n+Ao+sQ8683wIOJQpXOBkaR695dul9YqEtdcSerTPF4W3pK2Ma2+lwd+lgrujbDBWQbjGo9cQuf+ER6Tpnur/lFw5mdYYmXkDBnyeoo7kW3EvA242L5EgbLLayK4= Received: by 10.114.92.2 with SMTP id p2mr5449197wab.1183408257653; Mon, 02 Jul 2007 13:30:57 -0700 (PDT) Received: by 10.115.78.2 with HTTP; Mon, 2 Jul 2007 13:30:57 -0700 (PDT) Message-ID: Date: Mon, 2 Jul 2007 23:30:57 +0300 From: "Dennis Melentyev" To: Raaf In-Reply-To: <468825A9.80200@zen.mooo.com> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <4687FF75.3000108@zen.mooo.com> <47a4f3080707011454m6e06c97bu4764b32a65160ad6@mail.gmail.com> <468825A9.80200@zen.mooo.com> Cc: freebsd-stable@freebsd.org, freebsd-fs@freebsd.org Subject: Re: Cannot mount Sony Ericsson mobile phone, msdosfs too restrictive? 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: Mon, 02 Jul 2007 20:30:58 -0000 Hi! 2007/7/2, Raaf : > Brian Chu wrote: > > Raaf, > > > > What's the size of the memory stick? Is it 32MB like Dennis has? It was 64MB card also. :) AFAIR, FAT12 is just not correct format for disks larger than 32Mb. It has to use clusters not handled by original MSDOS in this case. So, my answer is: SE just use wrong FAT. But, meanwile, it should be ok to allow this insanity be handled. Despite I'd rather use smaller clusters for such a tiny drive. > > > > It's a 64MB memory stick using FAT12. MSDOS 3.3 will go crazy with that :) > > > The check for the field that affected you isn't critical to msdosfs' > > operation, but the field itself is specified to be non-zero. > > Konstantin, is it alright to remove this field? > > > > It seems there are more people having problems with the sanity checking > code of msdosfs, see also this related pr: > > http://www.freebsd.org/cgi/query-pr.cgi?pr=93860 > > -- Dennis Melentyev From owner-freebsd-fs@FreeBSD.ORG Mon Jul 2 20:33:01 2007 Return-Path: X-Original-To: freebsd-fs@freebsd.org Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 2B04E16A481 for ; Mon, 2 Jul 2007 20:33:01 +0000 (UTC) (envelope-from dennis.melentyev@gmail.com) Received: from nz-out-0506.google.com (nz-out-0506.google.com [64.233.162.232]) by mx1.freebsd.org (Postfix) with ESMTP id B4B5113C458 for ; Mon, 2 Jul 2007 20:33:00 +0000 (UTC) (envelope-from dennis.melentyev@gmail.com) Received: by nz-out-0506.google.com with SMTP id l8so851604nzf for ; Mon, 02 Jul 2007 13:33:00 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=DTDYIfVq6CdTycv/0K/gCOIpSJGrtTIulwsI4vMPVrxiT1iOHu6efr6xOgl2GOe6x73TJbnOMkmySA4OTyfnAmTlQU7X+ffsLI5GdcFyuPn+1Uf29kRRnqPSEbplgXUDokadwXzl/FgfqAhICjIHTo6ie9x7dphk1iK5IUagzQQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=DLh8EYN0eFqMM2cqNy2NLDXxecOHmrKOWg0Vl0mSneUiIu+drh0cW8jVhpr+m3yXzPbUywlS9dXR7qHe7cv4U3p26TAhUv5jCtOtZc4vbvdI6xim4qWSRE1j/gFfctGH20yv2AllQHtPgxguBtZykHROvgK+2JfKSKl6ARf3O7w= Received: by 10.114.130.1 with SMTP id c1mr5477544wad.1183408379819; Mon, 02 Jul 2007 13:32:59 -0700 (PDT) Received: by 10.115.78.2 with HTTP; Mon, 2 Jul 2007 13:32:59 -0700 (PDT) Message-ID: Date: Mon, 2 Jul 2007 23:32:59 +0300 From: "Dennis Melentyev" To: Raaf In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <4687FF75.3000108@zen.mooo.com> <47a4f3080707011454m6e06c97bu4764b32a65160ad6@mail.gmail.com> <468825A9.80200@zen.mooo.com> Cc: freebsd-stable@freebsd.org, freebsd-fs@freebsd.org Subject: Re: Cannot mount Sony Ericsson mobile phone, msdosfs too restrictive? 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: Mon, 02 Jul 2007 20:33:01 -0000 Can't confirm, but it seems like formating card with phone will give you FAT12 even on 1Gb card. (Not volunteering to reformat my "player") :) 2007/7/2, Dennis Melentyev : > Hi! > > 2007/7/2, Raaf : > > Brian Chu wrote: > > > Raaf, > > > > > > What's the size of the memory stick? Is it 32MB like Dennis has? > It was 64MB card also. :) > AFAIR, FAT12 is just not correct format for disks larger than 32Mb. > It has to use clusters not handled by original MSDOS in this case. > > So, my answer is: SE just use wrong FAT. > > But, meanwile, it should be ok to allow this insanity be handled. > Despite I'd rather use smaller clusters for such a tiny drive. > > > > > > > > It's a 64MB memory stick using FAT12. > > MSDOS 3.3 will go crazy with that :) > > > > > > The check for the field that affected you isn't critical to msdosfs' > > > operation, but the field itself is specified to be non-zero. > > > Konstantin, is it alright to remove this field? > > > > > > > It seems there are more people having problems with the sanity checking > > code of msdosfs, see also this related pr: > > > > http://www.freebsd.org/cgi/query-pr.cgi?pr=93860 > > > > > > > -- > Dennis Melentyev > -- Dennis Melentyev From owner-freebsd-fs@FreeBSD.ORG Tue Jul 3 03:17:49 2007 Return-Path: X-Original-To: freebsd-fs@freebsd.org Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 3C6EA16A41F; Tue, 3 Jul 2007 03:17:49 +0000 (UTC) (envelope-from anderson@freebsd.org) Received: from ns.trinitel.com (186.161.36.72.static.reverse.layeredtech.com [72.36.161.186]) by mx1.freebsd.org (Postfix) with ESMTP id 071F713C489; Tue, 3 Jul 2007 03:17:48 +0000 (UTC) (envelope-from anderson@freebsd.org) Received: from proton.local (r74-193-81-203.pfvlcmta01.grtntx.tl.dh.suddenlink.net [74.193.81.203]) (authenticated bits=0) by ns.trinitel.com (8.14.1/8.14.1) with ESMTP id l6332tMY050472; Mon, 2 Jul 2007 22:02:57 -0500 (CDT) (envelope-from anderson@freebsd.org) Message-ID: <4689BC5C.90909@freebsd.org> Date: Mon, 02 Jul 2007 22:02:52 -0500 From: Eric Anderson User-Agent: Thunderbird 2.0.0.4 (Macintosh/20070604) MIME-Version: 1.0 To: Dennis Melentyev References: <4687FF75.3000108@zen.mooo.com> <47a4f3080707011454m6e06c97bu4764b32a65160ad6@mail.gmail.com> <468825A9.80200@zen.mooo.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=ham version=3.1.8 X-Spam-Checker-Version: SpamAssassin 3.1.8 (2007-02-13) on ns.trinitel.com Cc: freebsd-fs@freebsd.org, Raaf , freebsd-stable@freebsd.org Subject: Re: Cannot mount Sony Ericsson mobile phone, msdosfs too restrictive? 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, 03 Jul 2007 03:17:49 -0000 Dennis Melentyev wrote: > Can't confirm, but it seems like formating card with phone will give > you FAT12 even on 1Gb card. (Not volunteering to reformat my "player") > :) It would be useful to some people to have access to a FAT12 formatted file system that is >32MB. Can you (or someone else) dd the flash to a file (the 64MB file is file), and then gzip it? Preferably a freshly formatted fat12 would be best. Eric > 2007/7/2, Dennis Melentyev : >> Hi! >> >> 2007/7/2, Raaf : >> > Brian Chu wrote: >> > > Raaf, >> > > >> > > What's the size of the memory stick? Is it 32MB like Dennis has? >> It was 64MB card also. :) >> AFAIR, FAT12 is just not correct format for disks larger than 32Mb. >> It has to use clusters not handled by original MSDOS in this case. >> >> So, my answer is: SE just use wrong FAT. >> >> But, meanwile, it should be ok to allow this insanity be handled. >> Despite I'd rather use smaller clusters for such a tiny drive. >> >> > > >> > >> > It's a 64MB memory stick using FAT12. >> >> MSDOS 3.3 will go crazy with that :) >> >> > >> > > The check for the field that affected you isn't critical to msdosfs' >> > > operation, but the field itself is specified to be non-zero. >> > > Konstantin, is it alright to remove this field? >> > > >> > >> > It seems there are more people having problems with the sanity checking >> > code of msdosfs, see also this related pr: >> > >> > http://www.freebsd.org/cgi/query-pr.cgi?pr=93860 >> > >> > >> >> >> -- >> Dennis Melentyev >> > > From owner-freebsd-fs@FreeBSD.ORG Tue Jul 3 07:01:38 2007 Return-Path: X-Original-To: freebsd-fs@freebsd.org Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 11C2416A41F; Tue, 3 Jul 2007 07:01:38 +0000 (UTC) (envelope-from david.cecil@nokia.com) Received: from mgw-ext14.nokia.com (smtp.nokia.com [131.228.20.173]) by mx1.freebsd.org (Postfix) with ESMTP id B784613C447; Tue, 3 Jul 2007 07:01:36 +0000 (UTC) (envelope-from david.cecil@nokia.com) Received: from esebh107.NOE.Nokia.com (esebh107.ntc.nokia.com [172.21.143.143]) by mgw-ext14.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l636gMNo013766; Tue, 3 Jul 2007 09:42:39 +0300 Received: from siebh102.NOE.Nokia.com ([172.30.195.29]) by esebh107.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 3 Jul 2007 09:42:19 +0300 Received: from syebe101.NOE.Nokia.com ([172.30.128.65]) by siebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 3 Jul 2007 14:41:48 +0800 Received: from [172.30.10.247] ([172.30.10.247]) by syebe101.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 3 Jul 2007 16:41:47 +1000 Message-ID: <4689EFAA.4080009@nokia.com> Date: Tue, 03 Jul 2007 16:41:46 +1000 From: David Cecil User-Agent: Thunderbird 1.5.0.12 (Windows/20070509) MIME-Version: 1.0 To: ext Kostik Belousov References: <45F776AE.8090702@nokia.com> <20070314161041.GI7847@garage.freebsd.pl> <45F8EE27.6070208@nokia.com> <20070315090031.GB80993@deviant.kiev.zoral.com.ua> In-Reply-To: <20070315090031.GB80993@deviant.kiev.zoral.com.ua> X-OriginalArrivalTime: 03 Jul 2007 06:41:47.0151 (UTC) FILETIME=[3A4391F0:01C7BD3D] X-Nokia-AV: Clean Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-fs@freebsd.org, Pawel Jakub Dawidek Subject: Re: FFS writes to read-only mount 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, 03 Jul 2007 07:01:38 -0000 Hi, in March I mailed the list about errors I'm seeing that look something like this: g_vfs_done():mirror/gmroots1f[WRITE(offset=1349091328, length=16384)]error = 1 (Note that gmroots1f is not a complete mirror set, just one disk ,and was never part of a complete mirror set. Also, partition f is the root partition.) The problem comes about because the underlying geom object has had its access permissions changed so that g_io_check fails due to acw being 0 (as per my original message at the end of this email). This problem is most easily reproducible when during boot if the root filesystem is changed from rw to ro mount. Our code is now 6.1-based. I have recently returned to this problem, but so far I have not been able to determine why this buffer was not sync'ed along with the others at the time the filesystem was remounted ro. I have included some information that was requested by Kostik back in March, in the hope it might trigger something useful. I have caused the system to panic in g_io_check when an illegal write attempt is found: #9 0x8057a3df in panic (fmt=0x80743c24 "Illegal write attempt!\n") at ../../../kern/kern_shutdown.c:572 #10 0x8052f0f0 in g_io_check (bp=0x866dbab0) at ../../../geom/geom_io.c:205 ---Type to continue, or q to quit--- #11 0x8052f5da in g_io_schedule_down (tp=0x852bd7d0) at ../../../geom/geom_io.c:387 #12 0x8052fb4a in g_down_procbody () at ../../../geom/geom_kern.c:118 #13 0x80564a08 in fork_exit (callout=0x8052faf0 , arg=0x0, frame=0xda68dd38) at ../../../kern/kern_fork.c:805 #14 0x806ebd7c in fork_trampoline () at ../../../i386/i386/exception.s:208 I have used bp to get the vnode, dirty buffer header, and buffer data. vnode: (kgdb) p *((struct buf *)(bp->bio_caller2))->b_bufobj->__bo_vnode $5 = {v_type = VCHR, v_tag = 0x807419d2 "devfs", v_op = 0x80fbb5a0, v_data = 0x866b5680, v_mount = 0x8664f000, v_nmntvnodes = { tqe_next = 0x866b1104, tqe_prev = 0x866b8118}, v_un = { vu_mount = 0x8664cb00, vu_socket = 0x8664cb00, vu_cdev = 0x8664cb00, vu_fifoinfo = 0x8664cb00}, v_hashlist = {le_next = 0x0, le_prev = 0x0}, v_hash = 0, v_cache_src = {lh_first = 0x0}, v_cache_dst = {tqh_first = 0x0, tqh_last = 0x866b8030}, v_dd = 0x0, v_cstart = 0, v_lasta = 0, v_lastw = 0, v_clen = 0, v_lock = {lk_interlock = 0x80fed128, lk_flags = 128, lk_sharecount = 0, lk_waitcount = 0, lk_exclusivecount = 0, lk_prio = 80, lk_wmesg = 0x807419d2 "devfs", lk_timo = 51, lk_lockholder = 0xffffffff, lk_newlock = 0x0}, v_interlock = {mtx_object = {lo_name = 0x80750688 "vnode interlock", lo_type = 0x80750688 "vnode interlock", lo_flags = 16973824, lo_witness_data = {lod_list = {stqe_next = 0x80ffd508}, lod_witness = 0x80ffd508}}, mtx_lock = 4, mtx_recurse = 0}, v_vnlock = 0x866b8058, v_holdcnt = 46, v_usecount = 1, v_iflag = 0, v_vflag = 0, v_writecount = 0, v_freelist = {tqe_next = 0x0, tqe_prev = 0x0}, v_bufobj = {bo_mtx = 0x866b807c, bo_clean = {bv_hd = { tqh_first = 0xcd364fc8, tqh_last = 0xcd365290}, bv_root = 0xcd38b060, bv_cnt = 44}, bo_dirty = {bv_hd = {tqh_first = 0x0, tqh_last = 0x866b80c8}, bv_root = 0x0, bv_cnt = 0}, bo_numoutput = 1, bo_flag = 0, bo_ops = 0x80fda81c, bo_bsize = 512, bo_object = 0x8186d7c0, bo_synclist = {le_next = 0x867d0ce4, le_prev = 0x860c21c4}, bo_private = 0x8667f040, __bo_vnode = 0x866b8000}, v_pollinfo = 0x0, v_label = 0x0} bufobj and buf: (kgdb) p *((struct buf *)(bp->bio_caller2))->b_bufobj $6 = {bo_mtx = 0x866b807c, bo_clean = {bv_hd = {tqh_first = 0xcd364fc8, tqh_last = 0xcd365290}, bv_root = 0xcd38b060, bv_cnt = 44}, bo_dirty = { bv_hd = {tqh_first = 0x0, tqh_last = 0x866b80c8}, bv_root = 0x0, bv_cnt = 0}, bo_numoutput = 1, bo_flag = 0, bo_ops = 0x80fda81c, bo_bsize = 512, bo_object = 0x8186d7c0, bo_synclist = {le_next = 0x867d0ce4, le_prev = 0x860c21c4}, bo_private = 0x8667f040, __bo_vnode = 0x866b8000} (kgdb) p *((struct buf *)(bp->bio_caller2)) $7 = {b_bufobj = 0x866b80b4, b_bcount = 16384, b_caller1 = 0x0, b_data = 0xce0ab000 "\001", b_error = 0, b_iocmd = 2 '\002', b_ioflags = 2 '\002', b_iooffset = 1541685248, b_resid = 0, b_iodone = 0, b_blkno = 3011104, b_offset = 1541685248, b_bobufs = {tqe_next = 0xcd38ac88, tqe_prev = 0xcd383828}, b_left = 0xcd3837f0, b_right = 0xcd369b60, b_vflags = 1, b_freelist = {tqe_next = 0xcd36c318, tqe_prev = 0xcd389ae4}, b_qindex = 2, b_flags = 2684485668, b_xflags = 2 '\002', b_lock = { lk_interlock = 0x80fed170, lk_flags = 262144, lk_sharecount = 0, lk_waitcount = 0, lk_exclusivecount = 1, lk_prio = 80, lk_wmesg = 0x8075476d "bufwait", lk_timo = 0, lk_lockholder = 0xfffffffe, lk_newlock = 0x0}, b_bufsize = 16384, b_runningbufspace = 16384, b_kvabase = 0xce0ab000 "\001", b_kvasize = 16384, b_lblkno = 3011104, b_vp = 0x866b8000, b_dirtyoff = 0, b_dirtyend = 0, b_rcred = 0x0, b_wcred = 0x0, b_saveaddr = 0xce0ab000, b_pager = {pg_reqpage = 0}, b_cluster = {cluster_head = {tqh_first = 0x0, tqh_last = 0x0}, cluster_entry = {tqe_next = 0x0, tqe_prev = 0x0}}, b_pages = {0x8253ce28, 0x8251bb70, 0x824ff9b8, 0x8251c500, 0x0 }, b_npages = 4, b_dep = {lh_first = 0x0}} data: (kgdb) x/32x 0xce0ab000 0xce0ab000: 0x0001a1ed 0x00000000 0x00000000 0x00000000 0xce0ab010: 0x00000010 0x00000000 0x00000000 0x00000000 0xce0ab020: 0x00000000 0x00000000 0x4689bfd2 0x00000000 0xce0ab030: 0x4689d40d 0x00000000 0x4689bfd2 0x00000000 0xce0ab040: 0x00000000 0x00000000 0x00000000 0x00000000 0xce0ab050: 0x76688876 0x00000000 0x00000000 0x00000000 0xce0ab060: 0x00000000 0x00000000 0x00000000 0x00000000 0xce0ab070: 0x5f696c63 0x746d7373 0x6f732e70 0x302e322e I appreciate any thoughts you have that might help me solve this issue. Also, in looking at a few geom related issues, I have a couple of changes that are generally applicable to FreeBSD that I plan to send for your comments soon. Thanks, Dave ext Kostik Belousov wrote: > On Thu, Mar 15, 2007 at 04:56:39PM +1000, David Cecil wrote: > >> Hi Pawel, >> >> here is what I've found. Note that this problem doesn't occur >> frequently, but does happen often enough to be a problem. I am still >> debugging the live system. >> >> I put breakpoints in g_print_bio and g_io_request. I then continued >> until the breakpoint at g_print_bio breakpoint was hit, but each time >> g_io_request was hit, I printed the backtrace. Then, at g_print_bio I >> could identify the struct bio * and look for the corresponding >> g_io_request trace with a matching struct bio *. >> >> That trace looks like this: >> db> bt >> Tracing pid 47 tid 100050 td 0x860d0640 >> g_io_request(864258c4,860ec440,a0020024,98b92188,a5281bf0,...) at >> g_io_request+0x107 >> g_vfs_strategy(86104ce4,98b92188,a0020024,98b92188,86104c30,...) at >> g_vfs_strategy+0x63 >> ffs_geom_strategy(86104ce4,98b92188) at ffs_geom_strategy+0x129 >> bufwrite(98b92188,4000,98b92188,a5281c54,805b20c1,...) at bufwrite+0x146 >> ffs_bufwrite(98b92188) at ffs_bufwrite+0x282 >> vfs_bio_awrite(98b92188) at vfs_bio_awrite+0x221 >> vop_stdfsync(a5281cbc,a5281cbc,a5281c98,806eff3e,a5281cbc,...) at >> vop_stdfsync+0x121 >> > It would be helpful, at this frame, to print the actual vnode, as well as > the dirty buffer header together with dump of buffer data. It seems that > the easiest way to do that would be to obtain coredump and then use kgdb. > > >> devfs_fsync(a5281cbc) at devfs_fsync+0x23 >> VOP_FSYNC_APV(80795080,a5281cbc) at VOP_FSYNC_APV+0x7e >> sync_vnode(86104ce4,860d0640) at sync_vnode+0x100 >> sched_sync(0,a5281d38,0,805c068c,0,...) at sched_sync+0x1ed >> fork_exit(805c068c,0,a5281d38) at fork_exit+0xa0 >> fork_trampoline() at fork_trampoline+0x8 >> >> From ps, it identifies pid 47 as "syncer". >> >> So it appears that all I've discovered is that the syncer thread is >> writing all the dirty buffers for gm0s1a to the disk :-( I guess the >> question is, why are there any dirty buffers for the read-only >> partition? I think the partition was mounted rw for a short while >> during the boot process. Maybe something there that didn't get >> flushed? Or is it something internal to FFS? >> >> The output of ps is listed below. Note that some processes might differ >> from a standard FreeBSD system as we're modifying the code. As this >> problem seems to be generic to some FreeBSD systems, I thought it valid >> to pursue the problem here. I hope that's okay, and anticipate the fix >> would apply to FBSD, as I've seen what appears to be the same problem >> logged elsewhere. >> >> db> ps >> pid ppid pgrp uid state wmesg wchan cmd >> 856 841 856 0 S+ ttyin 0x858bd810 csh >> 841 1 841 0 Ss+ wait 0x8612f800 login >> 791 551 791 0 Ss select 0x8081231c sshd-x >> 790 551 790 0 Ss nanslp 0x807c6400 cron >> 789 551 789 0 Ss select 0x8081231c monitord >> 788 551 788 0 Ss select 0x8081231c snmpd >> 787 551 787 0 Ss select 0x8081231c clishd >> 785 551 785 0 Ss select 0x8081231c inetd >> 731 727 727 80 S accept 0x861cde7e httpd >> 730 727 727 80 S accept 0x861cde7e httpd >> 729 551 729 0 Ss select 0x8081231c ifm >> 728 551 728 0 Ss select 0x8081231c xpand >> 727 551 727 0 Ss select 0x8081231c httpd >> 725 551 725 0 Ss select 0x8081231c ipsrd >> 559 551 559 0 Ss select 0x8081231c syslogd >> 551 1 551 0 Ss select 0x8081231c pm >> 49 0 0 0 SL - 0xa5071d04 [schedcpu] >> 48 0 0 0 SL sdflush 0x808ca6cc [softdepflush] >> 47 0 0 0 SL syncer 0x807c5da4 [syncer] >> 46 0 0 0 SL vlruwt 0x860ce600 [vnlru] >> 45 0 0 0 SL psleep 0x8081276c [bufdaemon] >> 44 0 0 0 SL pgzero 0x808cb41c [pagezero] >> 43 0 0 0 SL psleep 0x808caf84 [vmdaemon] >> 42 0 0 0 SL psleep 0x808caf40 [pagedaemon] >> 41 0 0 0 SL m:w1 0x860a1800 [g_mirror gm0s1] >> 40 0 0 0 SL ip_inp 0x80854c00 [ip_in_0] >> 39 0 0 0 SL ip6_inpu 0x808c9560 [ip6 input [1]] >> 38 0 0 0 SL ip6_inpu 0x808c9560 [ip6 input [0]] >> 37 0 0 0 WL [swi0: sio] >> 36 0 0 0 WL [irq17: ichsmb0] >> 35 0 0 0 WL [irq18: atapci1] >> 34 0 0 0 WL [irq15: ata1] >> 33 0 0 0 WL [irq14: ata0] >> 32 0 0 0 SL usbevt 0x84b7d210 [usb2] >> 31 0 0 0 WL [irq23: ehci0] >> 30 0 0 0 SL usbevt 0x8588c210 [usb1] >> 29 0 0 0 WL [irq19: uhci1] >> 28 0 0 0 SL usbtsk 0x807c2c64 [usbtask] >> 27 0 0 0 SL usbevt 0x8587a210 [usb0] >> 26 0 0 0 WL [irq16: uhci0] >> 25 0 0 0 WL [irq144: cavium0] >> 24 0 0 0 SL cbb cv 0x84b7dbe4 [cbb1] >> 23 0 0 0 SL cbb cv 0x84b7f3e4 [cbb0] >> 22 0 0 0 WL [irq96: cbb0 cbb1] >> 21 0 0 0 WL [irq9: acpi0] >> 20 0 0 0 WL [swi5: +] >> 9 0 0 0 SL - 0x84b56bc0 [thread taskq] >> 19 0 0 0 WL [swi6: +] >> 18 0 0 0 WL [swi6: task queue] >> 8 0 0 0 SL - 0x84b56d00 [acpi_task2] >> 7 0 0 0 SL - 0x84b56d00 [acpi_task1] >> 6 0 0 0 SL - 0x84b56d00 [acpi_task0] >> 17 0 0 0 WL [swi2: cambio] >> 5 0 0 0 SL - 0x84b56e80 [kqueue taskq] >> 16 0 0 0 SL - 0x807c2440 [yarrow] >> 4 0 0 0 SL - 0x807c335c [g_down] >> 3 0 0 0 RL CPU 0 [g_up] >> 2 0 0 0 SL - 0x807c3350 [g_event] >> 15 0 0 0 WL [swi1: net] >> 14 0 0 0 WL [swi3: vm] >> 13 0 0 0 WL [swi4: clock sio] >> 12 0 0 0 RL [idle: cpu0] >> 11 0 0 0 RL CPU 1 [idle: cpu1] >> 1 0 1 0 SLs wait 0x84ac8e00 [init] >> 10 0 0 0 SL ktrace 0x807c4610 [ktrace] >> 0 0 0 0 WLs [swapper] >> >> One list member asked if I have mounted the root partition with noatime >> as well as ro. I have not specified noatime. It's worth noting that >> files in / are regularly read/accessed, as you'd expect, but this bug >> only occurs once a week or so on a number of machines. >> >> Thanks a lot for your time. >> >> Regards, >> Dave >> >> ext Pawel Jakub Dawidek wrote: >> >>> On Wed, Mar 14, 2007 at 02:14:38PM +1000, David Cecil wrote: >>> >>> >>>> Hi, >>>> >>>> I have seen the following message (or equivalent) occasionally on a >>>> FreeBSD 6.1 system: >>>> g_vfs_done():mirror/gm0s1a[WRITE(offset=1349091328, length=16384)]error = >>>> 1 >>>> >>>> The partition in question is the root partition, and it is mounted >>>> read-only. I have verified that the problem occurs due to the write >>>> request returning EPERM due to the check in g_io_check: >>>> case BIO_WRITE: >>>> case BIO_DELETE: >>>> if (cp->acw == 0) >>>> return (EPERM); >>>> >>>> I have been trying to determine what within FFS would be trying to write >>>> to the partition. The "bio_from" in the bio structure indicates (in the >>>> geom) that it's ffs.mirror/gm0s1a that's trying to write. The contents >>>> of the buffer looks somewhat like a directory (lots of files listed, but >>>> comparison to the actual directory that contians these files reveals it's >>>> somewhat different), followed by a binary (ELF header). However, I'm at >>>> a loss to understand who's actually doing the writing. Is it coming from >>>> within FFS or is there an application that's done the write? (I can't >>>> understand how an application would be permitted to do it though.) >>>> >>>> I have seen this sort of problem (same error number) reported on the >>>> Internet occasionally, but it doesn't seem it's been satisfactorily >>>> resolved in all instances. >>>> >>>> Any help you can provide would be much appreciated. >>>> >>>> >>> Will be good if you could place kdb_enter() into g_vfs_done() error path >>> and once in DDB try which processes wait for I/O and collect their >>> backtraces or just put output of 'alltrace' on some web page. >>> >>> >>> >> -- >> Software Engineer >> Secure and Mobile Connectivity >> Nokia Enterprise Solutions >> +61 7 5553 8307 (office) >> +61 412 728 222 (cell) >> >> _______________________________________________ >> 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" >> From owner-freebsd-fs@FreeBSD.ORG Tue Jul 3 21:09:29 2007 Return-Path: X-Original-To: freebsd-fs@freebsd.org Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 0486F16A46B for ; Tue, 3 Jul 2007 21:09:29 +0000 (UTC) (envelope-from SRS0=90BM=MB=DSLextreme.com=SamQ@srs.perfora.net) Received: from mout.perfora.net (mout.perfora.net [74.208.4.195]) by mx1.freebsd.org (Postfix) with ESMTP id D1FA513C4BF for ; Tue, 3 Jul 2007 21:09:28 +0000 (UTC) (envelope-from SRS0=90BM=MB=DSLextreme.com=SamQ@srs.perfora.net) Received: from [68.183.47.123] (helo=netblock-68-183-17-229.dslextreme.com) by mrelay.perfora.net (node=mrus1) with ESMTP (Nemesis), id 0MKpCa-1I5pQT08in-0001di; Tue, 03 Jul 2007 16:56:56 -0400 From: "Sam Q - DATOptic" To: "freebsd-fs" Date: Tue, 3 Jul 2007 13:56:34 -0700 Organization: DATOptic Inc MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Message-ID: <0MKpCa-1I5pQT08in-0001di@mrelay.perfora.net> X-Provags-ID: V01U2FsdGVkX1+WYoRiSS9s/lU09hpfXcu0nR2NLx07e20WfAm q0BIJ7OvazM4uPQ+Zv4xJYqOVjCVlnv+xWjdL5JJ7ds3LGtAd/ x4bYh5fNieXhx474X5rN6O0afbPGCVk Subject: New message 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, 03 Jul 2007 21:09:29 -0000 Dear Value Partners Please find the our new RAID_PM Hardware RAID Port Multiplier bridge up to FIVE SATA ports - SiI-4723 Feature: - Hot Plug support; Compatible with NCQ drives - eSATA signal level support (1m and 2m PHY (compliant) - Supports PM aware hosts and non-PM aware - Less than 1% Host CPU loading during rebuild - Fast rebuild of 100GB/hour - Easy configuration using GUI applet - Drive Performance Aggregation (RAID 0) - Hardware RAID 0, 1, 10 with hot spare, Mirrored and spanning with spare, Spanning and JBOD http://www.datoptic.com/cgi-bin/web.cgi?search=yes&exact_match=on&detail=true&product=RAID_PM Availability: Now shipping Please feel free to contact me Best Regards Sam Q 714 558 1808 www.datoptic.com ===================================== CONFIDENTIALITY NOTICE: This email may contain confidential and privileged material of DATOptic for the sole use of the intended recipient. Any review or distribution by others is strictly prohibited. If you are not the intended recipient please contact the sender and delete all copies. Port Multiplier with hardware RAID subj From owner-freebsd-fs@FreeBSD.ORG Wed Jul 4 01:08:41 2007 Return-Path: X-Original-To: freebsd-fs@freebsd.org Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 35C3C16A400 for ; Wed, 4 Jul 2007 01:08:41 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: from mail03.syd.optusnet.com.au (mail03.syd.optusnet.com.au [211.29.132.184]) by mx1.freebsd.org (Postfix) with ESMTP id C85E113C44C for ; Wed, 4 Jul 2007 01:08:40 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: from c220-239-235-248.carlnfd3.nsw.optusnet.com.au (c220-239-235-248.carlnfd3.nsw.optusnet.com.au [220.239.235.248]) by mail03.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id l6418aXY006573 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 4 Jul 2007 11:08:38 +1000 Date: Wed, 4 Jul 2007 11:08:36 +1000 (EST) From: Bruce Evans X-X-Sender: bde@delplex.bde.org To: David Cecil In-Reply-To: <4689EFAA.4080009@nokia.com> Message-ID: <20070704102358.W95084@delplex.bde.org> References: <45F776AE.8090702@nokia.com> <20070314161041.GI7847@garage.freebsd.pl> <45F8EE27.6070208@nokia.com> <20070315090031.GB80993@deviant.kiev.zoral.com.ua> <4689EFAA.4080009@nokia.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-fs@freebsd.org, Pawel Jakub Dawidek Subject: Re: FFS writes to read-only mount 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: Wed, 04 Jul 2007 01:08:41 -0000 On Tue, 3 Jul 2007, David Cecil wrote: > in March I mailed the list about errors I'm seeing that look something like > this: > g_vfs_done():mirror/gmroots1f[WRITE(offset=1349091328, length=16384)]error = > 1 > (Note that gmroots1f is not a complete mirror set, just one disk ,and was > never part of a complete mirror set. Also, partition f is the root > partition.) > > The problem comes about because the underlying geom object has had its access > permissions changed so that g_io_check fails due to acw being 0 (as per my > original message at the end of this email). This problem is most easily > reproducible when during boot if the root filesystem is changed from rw to ro > mount. Our code is now 6.1-based. At least -current seems to have the opposite problem -- that acw is not changed to 0 on mount -o ro, as shown by: boot use the system a bit # fsck -p / # fails of course since / is rw # mount -u -o ro / # fails with EBUSY # # I don't want to try mount -f ... / # kill -TERM 1 # shut down to single user mode to run fsck safely # umount -A # old bug: this still doesn't remount / ro # not so old bug: it now tries to unmount devfs; this # fails of course # mount -u -o ro / # finish unmounting / (works according to mount status) # fsck -p / # fails, apparently since acw is still nonzero In some non-current versions of FreeBSD, I have debugging code in ffs_update() that complains about attempts to update inodes on read-only file systems. Such attempts certainly occur, due to historical mistakes. They are supposed to be handled (starting sometime in 4.x) by silently ignoring the problem and clearing the IN_MODIFIED flag and related flags so that the update is not retried later. I don't know of any cases where this doesn't work. Bruce From owner-freebsd-fs@FreeBSD.ORG Wed Jul 4 01:52:09 2007 Return-Path: X-Original-To: freebsd-fs@freebsd.org Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id A93DE16A400; Wed, 4 Jul 2007 01:52:09 +0000 (UTC) (envelope-from gpalmer@freebsd.org) Received: from noop.in-addr.com (noop.in-addr.com [208.58.23.51]) by mx1.freebsd.org (Postfix) with ESMTP id 79C2E13C447; Wed, 4 Jul 2007 01:52:09 +0000 (UTC) (envelope-from gpalmer@freebsd.org) Received: from gjp by noop.in-addr.com with local (Exim 4.54 (FreeBSD)) id 1I5tsb-000KEC-Oe; Tue, 03 Jul 2007 21:42:05 -0400 Date: Tue, 3 Jul 2007 21:42:05 -0400 From: Gary Palmer To: Bruce Evans Message-ID: <20070704014205.GA53564@in-addr.com> Mail-Followup-To: Bruce Evans , David Cecil , freebsd-fs@freebsd.org, Pawel Jakub Dawidek References: <45F776AE.8090702@nokia.com> <20070314161041.GI7847@garage.freebsd.pl> <45F8EE27.6070208@nokia.com> <20070315090031.GB80993@deviant.kiev.zoral.com.ua> <4689EFAA.4080009@nokia.com> <20070704102358.W95084@delplex.bde.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20070704102358.W95084@delplex.bde.org> Cc: freebsd-fs@freebsd.org, Pawel Jakub Dawidek Subject: Re: FFS writes to read-only mount 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: Wed, 04 Jul 2007 01:52:09 -0000 On Wed, Jul 04, 2007 at 11:08:36AM +1000, Bruce Evans wrote: > On Tue, 3 Jul 2007, David Cecil wrote: > > >in March I mailed the list about errors I'm seeing that look something > >like this: > >g_vfs_done():mirror/gmroots1f[WRITE(offset=1349091328, length=16384)]error > >= 1 > >(Note that gmroots1f is not a complete mirror set, just one disk ,and was > >never part of a complete mirror set. Also, partition f is the root > >partition.) > > > >The problem comes about because the underlying geom object has had its > >access permissions changed so that g_io_check fails due to acw being 0 (as > >per my original message at the end of this email). This problem is most > >easily reproducible when during boot if the root filesystem is changed > >from rw to ro mount. Our code is now 6.1-based. > > At least -current seems to have the opposite problem -- that acw is not > changed to 0 on mount -o ro, as shown by: > > boot > use the system a bit > # fsck -p / # fails of course since / is rw > # mount -u -o ro / # fails with EBUSY > # # I don't want to try mount -f ... / > # kill -TERM 1 # shut down to single user mode to run fsck safely > # umount -A # old bug: this still doesn't remount / ro > # not so old bug: it now tries to unmount devfs; this > # fails of course > # mount -u -o ro / # finish unmounting / (works according to mount status) > # fsck -p / # fails, apparently since acw is still nonzero > > In some non-current versions of FreeBSD, I have debugging code in > ffs_update() that complains about attempts to update inodes on read-only > file systems. Such attempts certainly occur, due to historical mistakes. > They are supposed to be handled (starting sometime in 4.x) by silently > ignoring the problem and clearing the IN_MODIFIED flag and related flags > so that the update is not retried later. I don't know of any cases where > this doesn't work. Does silently clearing that flag mean data could be lost? Or are these just async metadata updates and all the file content is properly flushed prior to the FS going RO? Thanks, Gary From owner-freebsd-fs@FreeBSD.ORG Wed Jul 4 05:25:35 2007 Return-Path: X-Original-To: freebsd-fs@freebsd.org Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 1094E16A473; Wed, 4 Jul 2007 05:25:35 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: from mail13.syd.optusnet.com.au (mail13.syd.optusnet.com.au [211.29.132.194]) by mx1.freebsd.org (Postfix) with ESMTP id 9FCE213C487; Wed, 4 Jul 2007 05:25:34 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: from besplex.bde.org (c220-239-235-248.carlnfd3.nsw.optusnet.com.au [220.239.235.248]) by mail13.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id l645PKsO001222 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 4 Jul 2007 15:25:26 +1000 Date: Wed, 4 Jul 2007 15:25:20 +1000 (EST) From: Bruce Evans X-X-Sender: bde@besplex.bde.org To: Gary Palmer In-Reply-To: <20070704014205.GA53564@in-addr.com> Message-ID: <20070704133335.I16373@besplex.bde.org> References: <45F776AE.8090702@nokia.com> <20070314161041.GI7847@garage.freebsd.pl> <45F8EE27.6070208@nokia.com> <20070315090031.GB80993@deviant.kiev.zoral.com.ua> <4689EFAA.4080009@nokia.com> <20070704102358.W95084@delplex.bde.org> <20070704014205.GA53564@in-addr.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-fs@freebsd.org, Pawel Jakub Dawidek Subject: Re: FFS writes to read-only mount 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: Wed, 04 Jul 2007 05:25:35 -0000 On Tue, 3 Jul 2007, Gary Palmer wrote: > On Wed, Jul 04, 2007 at 11:08:36AM +1000, Bruce Evans wrote: >> In some non-current versions of FreeBSD, I have debugging code in >> ffs_update() that complains about attempts to update inodes on read-only >> file systems. Such attempts certainly occur, due to historical mistakes. >> They are supposed to be handled (starting sometime in 4.x) by silently >> ignoring the problem and clearing the IN_MODIFIED flag and related flags >> so that the update is not retried later. I don't know of any cases where >> this doesn't work. > > Does silently clearing that flag mean data could be lost? Or are these > just async metadata updates and all the file content is properly > flushed prior to the FS going RO? I think at most some timestamps were lost, and then maybe only for the short time while transitioning from rw to ro. Timestamps related only to that transition period _should_ be lost, since it isn't worth restarting the transition to pick up changes to timestamps alone. Now it looks like the hack in ufs_itimes() to write out timestamps related to before the transition (but not yet finalized) never worked and has been lost. Maybe I just don't understand the code and everything now works without hacks. I think what should happen for MNT_UPDATE is: o first call vn_start_write(). Hopefully this prevents all writes from userland during the transition. Writes from the kernel must be permitted so as to sync old writes from userland. o sync all old writes using something a synchronous ffs_sync(), but more forceful so as not to forget syncing IN_LAZYMOD inodes. o set MNT_RDONLY in the vnode for the mount point. I think this alone was supposed to prevent writes from userland. It works poorly for this since it also prevents some writes from the kernel. E.g., in ufs_itimes() it now prevents ufs_itimes() changing anything, so if timestamps haven't already been finalized and flushed then there is a bug. Some old versions of ufs_timestamp() starting with ufs_vnops.c 1.182 handled this problem badly by setting IN_MODIFIED before checking any readonly flag, but I think this did less than nothing since these versions proceeded to check MNT_RDONLY and make null changes to the timestamps if that flag is set; thus they broke assertions obout no writes to read-only file systems without actually syncing old timestamps. o for ffs, set fs_ronly in the superblock to prevent all writes via the file system. ffs_update() checks this, and this is supposed to permit the kernel to update timestamps between the setting of MNT_RDONLY and the setting of fs_ronly, but this never worked right. There are related problems with IN_LAZYMOD and IN_LAZYACCESS. IN_LAZYMOD inodes are only fully synced by going through ufs_reclaim() (for ffs). I think this doesn't happen early enough (if at all) to work for the rw -> ro transition (it works for unmount()). This problem is moot in -current since IN_LAZYMOD is only used for cdevs and there are no cdevs on ffs. (I also use it for atime updates but don't test it much since I also use -noatime for almost all file systems). Problems with IN_LAZYACCESS are similar, but are more likely to be all fixed since they are serious if they occur. Writes of even atimes by the kernel must be prevented while taking snapshots. This is handled by delaying the atime updates; all other writes are supposed to be prevented by something like vn_start_write(). Concerning fsck not working after "mount -u -o ro /": fsck generally doesn't work on mounted file systems, even if the mount is ro. It works for the root file system after plain mount only because ffs_mountfs() has an extra g_access() call to make it work. This call is missing for mount -u. Bruce From owner-freebsd-fs@FreeBSD.ORG Fri Jul 6 00:50:59 2007 Return-Path: X-Original-To: freebsd-fs@FreeBSD.org Delivered-To: freebsd-fs@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id B205616A400 for ; Fri, 6 Jul 2007 00:50:59 +0000 (UTC) (envelope-from tony@crosswinds.net) Received: from out-mx1.crosswinds.net (out-mx1.crosswinds.net [216.18.117.38]) by mx1.freebsd.org (Postfix) with ESMTP id 8E4E413C455 for ; Fri, 6 Jul 2007 00:50:59 +0000 (UTC) (envelope-from tony@crosswinds.net) Received: from admin.crosswinds.net (out-mx1.crosswinds.net [216.18.117.38]) by out-mx1.crosswinds.net (Postfix) with ESMTP id 4FA1B2C2E5 for ; Thu, 5 Jul 2007 20:35:03 -0400 (EDT) Received: by admin.crosswinds.net (Postfix, from userid 1001) id 3C485403D; Thu, 5 Jul 2007 20:35:03 -0400 (EDT) Date: Thu, 5 Jul 2007 20:35:03 -0400 From: Tony Holmes To: freebsd-fs@FreeBSD.org Message-ID: <20070706003503.GA35917@crosswinds.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.2.1i Cc: Subject: Adding gjournal to existing disks? 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: Fri, 06 Jul 2007 00:50:59 -0000 I have a question about gjournal. I have a system that I can not reparition/newfs and was wondering if it is possible to add gjournal to the existing filesystems? The system is i386, RELENG_6 and the disk are using gmirror and gstripe. The partition I'm most interested in journaling is the gstripe parition. Here's my fstab as a reference: /dev/mirror/gm0s1b none swap sw 0 0 /dev/mirror/gm1s1b none swap sw 0 0 /dev/mirror/gm0s1a / ufs rw 1 1 /dev/mirror/gm1s1d /tmp ufs rw 2 2 /dev/mirror/gm0s1d /usr ufs rw 2 2 /dev/mirror/gm1s1e /var ufs rw 2 2 /dev/stripe/home /usr/home ufs rw,userquota,noauto 2 2 df -k: Filesystem 1K-blocks Used Avail Capacity Mounted on /dev/mirror/gm0s1a 2026030 104708 1759240 6% / devfs 1 1 0 100% /dev /dev/mirror/gm1s1d 2026030 13052 1850896 1% /tmp /dev/mirror/gm0s1d 8122126 3859922 3612434 52% /usr /dev/mirror/gm1s1e 8122126 1070764 6401592 14% /var /dev/stripe/home 287190090 167354816 96860068 63% /usr/home procfs 4 4 0 100% /proc So lots of space free on the stripe. I read the man page for 7-Current but it is unclear if a both the journal and data can exist in the same partition. BTW, I've been using FreeBSD for almost 14 years now and I LOVE where 6 and 7 are going. -- Tony Holmes Ph: (416) 993-1219 Founder and Senior Systems Architect Crosswinds Internet Communications Inc. From owner-freebsd-fs@FreeBSD.ORG Fri Jul 6 01:39:27 2007 Return-Path: X-Original-To: freebsd-fs@freebsd.org Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 29E4216A400; Fri, 6 Jul 2007 01:39:27 +0000 (UTC) (envelope-from david.cecil@nokia.com) Received: from mgw-ext14.nokia.com (smtp.nokia.com [131.228.20.173]) by mx1.freebsd.org (Postfix) with ESMTP id 8FCF313C45B; Fri, 6 Jul 2007 01:39:26 +0000 (UTC) (envelope-from david.cecil@nokia.com) Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-ext14.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l661dEEQ025363; Fri, 6 Jul 2007 04:39:23 +0300 Received: from siebh102.NOE.Nokia.com ([172.30.195.29]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 6 Jul 2007 04:38:58 +0300 Received: from syebe101.NOE.Nokia.com ([172.30.128.65]) by siebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 6 Jul 2007 09:38:55 +0800 Received: from [172.30.67.16] ([172.30.67.16]) by syebe101.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 6 Jul 2007 11:38:54 +1000 Message-ID: <468D9D2D.7010105@nokia.com> Date: Fri, 06 Jul 2007 11:38:53 +1000 From: David Cecil User-Agent: Thunderbird 1.5.0.12 (Windows/20070509) MIME-Version: 1.0 To: ext Bruce Evans References: <45F776AE.8090702@nokia.com> <20070314161041.GI7847@garage.freebsd.pl> <45F8EE27.6070208@nokia.com> <20070315090031.GB80993@deviant.kiev.zoral.com.ua> <4689EFAA.4080009@nokia.com> <20070704102358.W95084@delplex.bde.org> <20070704014205.GA53564@in-addr.com> <20070704133335.I16373@besplex.bde.org> In-Reply-To: <20070704133335.I16373@besplex.bde.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 06 Jul 2007 01:38:54.0356 (UTC) FILETIME=[69AC5D40:01C7BF6E] X-Nokia-AV: Clean Cc: freebsd-fs@freebsd.org, Pawel Jakub Dawidek Subject: Re: FFS writes to read-only mount 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: Fri, 06 Jul 2007 01:39:27 -0000 Here's a little more information about the problem. (g_vfs_done():mirror/gmroots1f[WRITE(offset=1541668864, length=16384)]error = 1) I am able to reproduce this problem relatively easily by reinstalling our system (it often occurs < 10 installations (thank you expect :-)). As long as I don't change the kit too much, the offset is always the same. I discovered that running fsck makes the problem go away. For example, if I run "fsck_ufs /" (the partition on which it's happening) the messages no longer appear. The next logical question is, is the buffer written to disk, or just tossed? So I added a test to ad_strategy to call kdb_enter if the bio's bio_pblkno matched that for the buffer above (I divided by 512, the sector size). The breakpoint wasn't entered. So it appears the buffer is just being tossed when fsck is run. fsck_ufs / ** /dev/mirror/gmroots1f (NO WRITE) ** Last Mounted on / ** Root file system ** Phase 1 - Check Blocks and Sizes ** Phase 2 - Check Pathnames ** Phase 3 - Check Connectivity ** Phase 4 - Check Reference Counts ** Phase 5 - Check Cyl groups 2859 files, 81957 used, 934739 free (131 frags, 116826 blocks, 0.0% fragmentation) The other point is, that means it didn't read it from the disk either, even though ffs_reload was called. It's almost as if this buffer should have been discarded in the first instance, not written to disk. Can anyone tell me where I should look to see if this buffer has been removed before the call to ffs_reload? I'm assuming there a list(s) I can traverse and look for matching block device offset. I see a few lists but I'm concerned that I don't find it but I haven't looked in the right place. Thanks, Dave ext Bruce Evans wrote: > On Tue, 3 Jul 2007, Gary Palmer wrote: > >> On Wed, Jul 04, 2007 at 11:08:36AM +1000, Bruce Evans wrote: > >>> In some non-current versions of FreeBSD, I have debugging code in >>> ffs_update() that complains about attempts to update inodes on >>> read-only >>> file systems. Such attempts certainly occur, due to historical >>> mistakes. >>> They are supposed to be handled (starting sometime in 4.x) by silently >>> ignoring the problem and clearing the IN_MODIFIED flag and related >>> flags >>> so that the update is not retried later. I don't know of any cases >>> where >>> this doesn't work. >> >> Does silently clearing that flag mean data could be lost? Or are these >> just async metadata updates and all the file content is properly >> flushed prior to the FS going RO? > > I think at most some timestamps were lost, and then maybe only for the > short time while transitioning from rw to ro. Timestamps related only > to that transition period _should_ be lost, since it isn't worth > restarting the transition to pick up changes to timestamps alone. Now > it looks like the hack in ufs_itimes() to write out timestamps related > to before the transition (but not yet finalized) never worked and has > been lost. Maybe I just don't understand the code and everything now > works without hacks. I think what should happen for MNT_UPDATE is: > > o first call vn_start_write(). Hopefully this prevents all writes from > userland during the transition. Writes from the kernel must be > permitted > so as to sync old writes from userland. > o sync all old writes using something a synchronous ffs_sync(), but more > forceful so as not to forget syncing IN_LAZYMOD inodes. > o set MNT_RDONLY in the vnode for the mount point. I think this alone > was > supposed to prevent writes from userland. It works poorly for this > since > it also prevents some writes from the kernel. E.g., in ufs_itimes() it > now prevents ufs_itimes() changing anything, so if timestamps haven't > already been finalized and flushed then there is a bug. Some old > versions > of ufs_timestamp() starting with ufs_vnops.c 1.182 handled this problem > badly by setting IN_MODIFIED before checking any readonly flag, but I > think this did less than nothing since these versions proceeded to > check > MNT_RDONLY and make null changes to the timestamps if that flag is set; > thus they broke assertions obout no writes to read-only file systems > without actually syncing old timestamps. > o for ffs, set fs_ronly in the superblock to prevent all writes via the > file system. ffs_update() checks this, and this is supposed to permit > the kernel to update timestamps between the setting of MNT_RDONLY and > the setting of fs_ronly, but this never worked right. > > There are related problems with IN_LAZYMOD and IN_LAZYACCESS. IN_LAZYMOD > inodes are only fully synced by going through ufs_reclaim() (for ffs). > I think this doesn't happen early enough (if at all) to work for the > rw -> ro transition (it works for unmount()). This problem is moot > in -current since IN_LAZYMOD is only used for cdevs and there are no > cdevs on ffs. (I also use it for atime updates but don't test it much > since I also use -noatime for almost all file systems). Problems with > IN_LAZYACCESS are similar, but are more likely to be all fixed since > they are serious if they occur. Writes of even atimes by the kernel > must be prevented while taking snapshots. This is handled by delaying > the atime updates; all other writes are supposed to be prevented by > something like vn_start_write(). > > Concerning fsck not working after "mount -u -o ro /": fsck generally > doesn't work on mounted file systems, even if the mount is ro. It > works for the root file system after plain mount only because > ffs_mountfs() has an extra g_access() call to make it work. This > call is missing for mount -u. > > Bruce > From owner-freebsd-fs@FreeBSD.ORG Fri Jul 6 10:38:30 2007 Return-Path: X-Original-To: freebsd-fs@freebsd.org Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 7A67116A469 for ; Fri, 6 Jul 2007 10:38:30 +0000 (UTC) (envelope-from freebsd-fs@m.gmane.org) Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by mx1.freebsd.org (Postfix) with ESMTP id 343D313C459 for ; Fri, 6 Jul 2007 10:38:29 +0000 (UTC) (envelope-from freebsd-fs@m.gmane.org) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1I6lCi-0003wD-Vo for freebsd-fs@freebsd.org; Fri, 06 Jul 2007 12:38:25 +0200 Received: from lara.cc.fer.hr ([161.53.72.113]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 06 Jul 2007 12:38:24 +0200 Received: from ivoras by lara.cc.fer.hr with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 06 Jul 2007 12:38:24 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-fs@freebsd.org From: Ivan Voras Date: Fri, 06 Jul 2007 12:38:10 +0200 Lines: 36 Message-ID: References: <20070706003503.GA35917@crosswinds.net> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigB4BC036A2DE7A334AD628FC7" X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: lara.cc.fer.hr User-Agent: Thunderbird 1.5.0.12 (X11/20060911) In-Reply-To: <20070706003503.GA35917@crosswinds.net> X-Enigmail-Version: 0.94.2.0 Sender: news Subject: Re: Adding gjournal to existing disks? 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: Fri, 06 Jul 2007 10:38:30 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigB4BC036A2DE7A334AD628FC7 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable Tony Holmes wrote: > So lots of space free on the stripe. I read the man page for 7-Current = but > it is unclear if a both the journal and data can exist in the same part= ition. Only if the file system was created like that (because it's a hack - the = journal is still not a part of the file system but exists in the space=20 between the end of the file system and the end of the slice/partition). If you want to add it later, you need to create a separate=20 slice/partition and put gjournal on it. --------------enigB4BC036A2DE7A334AD628FC7 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (GNU/Linux) Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org iD8DBQFGjhuZldnAQVacBcgRAkF5AKCi/pC2cg/9+oFSVi4yXtfSB5oqwwCg3tC1 vNivtZgRieBOLBOOrDfPRro= =oq/5 -----END PGP SIGNATURE----- --------------enigB4BC036A2DE7A334AD628FC7-- From owner-freebsd-fs@FreeBSD.ORG Fri Jul 6 12:33:44 2007 Return-Path: X-Original-To: freebsd-fs@freebsd.org Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id E792716A468 for ; Fri, 6 Jul 2007 12:33:44 +0000 (UTC) (envelope-from tony@crosswinds.net) Received: from out-mx1.crosswinds.net (out-mx1.crosswinds.net [216.18.117.38]) by mx1.freebsd.org (Postfix) with ESMTP id C143013C455 for ; Fri, 6 Jul 2007 12:33:44 +0000 (UTC) (envelope-from tony@crosswinds.net) Received: from admin.crosswinds.net (out-mx1.crosswinds.net [216.18.117.38]) by out-mx1.crosswinds.net (Postfix) with ESMTP id 7817C2EB5E for ; Fri, 6 Jul 2007 08:34:04 -0400 (EDT) Received: by admin.crosswinds.net (Postfix, from userid 1001) id 4F8F7403D; Fri, 6 Jul 2007 08:34:04 -0400 (EDT) Date: Fri, 6 Jul 2007 08:34:04 -0400 From: Tony Holmes To: freebsd-fs@freebsd.org Message-ID: <20070706123404.GE76785@crosswinds.net> References: <20070706003503.GA35917@crosswinds.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.1i Subject: Re: Adding gjournal to existing disks? 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: Fri, 06 Jul 2007 12:33:45 -0000 On +Jul 06, Ivan Voras wrote: > Tony Holmes wrote: > > >So lots of space free on the stripe. I read the man page for 7-Current but > >it is unclear if a both the journal and data can exist in the same > >partition. > > Only if the file system was created like that (because it's a hack - the > journal is still not a part of the file system but exists in the space > between the end of the file system and the end of the slice/partition). > > If you want to add it later, you need to create a separate > slice/partition and put gjournal on it. Thanks for the quick answer! I was hoping this wasn't the case but I had to be 100% certain. Are there any tools to shrink a partition? :) When I lost power on this system the mirrors weren't synced so the gmirror sync + fsync kept the system down for 1.5 hours - that hurt. -- Tony Holmes Ph: (416) 993-1219 Founder and Senior Systems Architect Crosswinds Internet Communications Inc. From owner-freebsd-fs@FreeBSD.ORG Fri Jul 6 15:24:33 2007 Return-Path: X-Original-To: freebsd-fs@freebsd.org Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 7972416A41F for ; Fri, 6 Jul 2007 15:24:33 +0000 (UTC) (envelope-from aristeu.jr@gmail.com) Received: from ug-out-1314.google.com (ug-out-1314.google.com [66.249.92.172]) by mx1.freebsd.org (Postfix) with ESMTP id 1416C13C45A for ; Fri, 6 Jul 2007 15:24:32 +0000 (UTC) (envelope-from aristeu.jr@gmail.com) Received: by ug-out-1314.google.com with SMTP id o4so825992uge for ; Fri, 06 Jul 2007 08:24:32 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition; b=TmXT1cxI7HJIjE7pP9UAhWQEdLBSf9uNXaalGkkbTTstFfOT+p/vpLGWJxwdUCId1BXSm+4WF0+r7pR9BcycTzhNgodzwH1OEod2qHU42Sj6X74EZH5t7J7FS1T/FasyAfI4v/JrZ05HX/+ef9CRoqCf0DBXO3tXUzZK7A1PpS8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition; b=q1AZ7EY74ClAIoYIsvz4SqufYFkA16PE50Tf2QjlPcp32oOaXYhafg+wu+81j4glnc3+QpXor1WuMAcp0dKKCUaq2j32AvtpfP5IAjkgmloSr9Jr8oBBbA/L2YGbfU6kEMqKF0/fivA73/cBFFbhxypLd7SBMDUu15v+ct7pNrc= Received: by 10.82.158.12 with SMTP id g12mr1906538bue.1183734008603; Fri, 06 Jul 2007 08:00:08 -0700 (PDT) Received: by 10.82.189.12 with HTTP; Fri, 6 Jul 2007 08:00:08 -0700 (PDT) Message-ID: <2c84c1de0707060800t21f3f993mfb53f7975a881ed4@mail.gmail.com> Date: Fri, 6 Jul 2007 12:00:08 -0300 From: "Aristeu Gil Alves Jr" To: freebsd-fs@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Subject: Coda-client and kernel panic 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: Fri, 06 Jul 2007 15:24:33 -0000 I'm using a 6.2-RELEASE-p4, updated with freebsd-update. Installed coda-client-6.1.2 from ports. I'm having the same problems that were submitted on April 2006 for 7.0-CURRENT [1]. Coda-server is running apparently fine (I can't test it without the client). Is coda-client usable in ANY freebsd supported versions? Are there any strict userlevel client available (to scape the kernel panic)? Thanks -- Aristeu Gil Alves Jr [1] http://www.freebsd.org/cgi/query-pr.cgi?pr=95891&cat=