From owner-freebsd-fs@FreeBSD.ORG Mon Jan 26 22:54:33 2004 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id BD72C16A4CE; Mon, 26 Jan 2004 22:54:33 -0800 (PST) Received: from ftp.bjpu.edu.cn (ftp.bjpu.edu.cn [202.112.78.5]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7830843D45; Mon, 26 Jan 2004 22:54:06 -0800 (PST) (envelope-from delphij@frontfree.net) Received: by ftp.bjpu.edu.cn (Postfix, from userid 426) id BBA105359; Tue, 27 Jan 2004 14:53:32 +0800 (CST) Received: from beastie.frontfree.net (beastie.frontfree.net [218.107.145.7]) by ftp.bjpu.edu.cn (Postfix) with ESMTP id 863375299; Tue, 27 Jan 2004 14:53:32 +0800 (CST) Received: by beastie.frontfree.net (Postfix, from userid 1001) id 43F7611AE7; Tue, 27 Jan 2004 14:53:31 +0800 (CST) To: FreeBSD-gnats-submit@freebsd.org From: Xin LI X-send-pr-version: 3.113 X-GNATS-Notify: Message-Id: <20040127065331.43F7611AE7@beastie.frontfree.net> Date: Tue, 27 Jan 2004 14:53:31 +0800 (CST) X-Mailman-Approved-At: Tue, 27 Jan 2004 05:24:49 -0800 cc: mckusick@FreeBSD.org Subject: [PATCH] bring incompletely initialized magic to UFS1 X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: Xin LI List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Jan 2004 06:54:34 -0000 >Submitter-Id: current-users >Originator: Xin LI >Organization: The FreeBSD Simplified Chinese Project >Confidential: no >Synopsis: [PATCH] bring incompletely initialized magic to UFS1 >Severity: non-critical >Priority: low >Category: bin >Class: change-request >Release: FreeBSD 5.2-RELEASE i386 >Environment: System: FreeBSD beastie.frontfree.net 5.2-RELEASE FreeBSD 5.2-RELEASE #16: Sat Jan 10 15:24:09 CST 2004 delphij@beastie.frontfree.net:/usr/obj/usr/src/sys/BEASTIE i386 >Description: The attached is a proposal patch to make it possible to mark UFS1 as "incompletely initialized" when newfs(8) did not have it actually initialized. To implement this, I have borrowed the "bad UFS2" magic number. Please review this patch. Frankly I am not sure if this is useful in most circumstances, but a "incomplete" flag is really useful for certain needs. >How-To-Repeat: >Fix: Apply the attached patch to src/ tree. --- patch2 begins here --- Index: sbin/fsck_ffs/setup.c =================================================================== RCS file: /home/mirror/freebsd/ncvs/src/sbin/fsck_ffs/setup.c,v retrieving revision 1.46 diff -u -r1.46 setup.c --- sbin/fsck_ffs/setup.c 26 Jan 2004 15:05:30 -0000 1.46 +++ sbin/fsck_ffs/setup.c 27 Jan 2004 03:48:07 -0000 @@ -310,7 +310,7 @@ super = bflag; if ((bread(fsreadfd, (char *)&sblock, super, (long)SBLOCKSIZE))) return (0); - if (sblock.fs_magic == FS_BAD2_MAGIC) { + if (sblock.fs_magic == FS_BAD_MAGIC) { fprintf(stderr, BAD_MAGIC_MSG); exit(11); } @@ -326,7 +326,7 @@ if ((bread(fsreadfd, (char *)&sblock, super, (long)SBLOCKSIZE))) return (0); - if (sblock.fs_magic == FS_BAD2_MAGIC) { + if (sblock.fs_magic == FS_BAD_MAGIC) { fprintf(stderr, BAD_MAGIC_MSG); exit(11); } Index: sbin/newfs/mkfs.c =================================================================== RCS file: /home/mirror/freebsd/ncvs/src/sbin/newfs/mkfs.c,v retrieving revision 1.83 diff -u -r1.83 mkfs.c --- sbin/newfs/mkfs.c 27 Nov 2003 01:19:23 -0000 1.83 +++ sbin/newfs/mkfs.c 27 Jan 2004 04:17:01 -0000 @@ -238,8 +238,14 @@ } sblock.fs_fsbtodb = ilog2(sblock.fs_fsize / sectorsize); sblock.fs_size = fssize = dbtofsb(&sblock, fssize); + + /* + * Before the filesystem is finally initialized, mark it + * as incompletely initialized. + */ + sblock.fs_magic = FS_BAD_MAGIC; + if (Oflag == 1) { - sblock.fs_magic = FS_UFS1_MAGIC; sblock.fs_sblockloc = SBLOCK_UFS1; sblock.fs_nindir = sblock.fs_bsize / sizeof(ufs1_daddr_t); sblock.fs_inopb = sblock.fs_bsize / sizeof(struct ufs1_dinode); @@ -259,7 +265,6 @@ sblock.fs_old_postblformat = 1; sblock.fs_old_nrpos = 1; } else { - sblock.fs_magic = FS_BAD2_MAGIC; sblock.fs_sblockloc = SBLOCK_UFS2; sblock.fs_nindir = sblock.fs_bsize / sizeof(ufs2_daddr_t); sblock.fs_inopb = sblock.fs_bsize / sizeof(struct ufs2_dinode); @@ -457,8 +462,8 @@ } if (Eflag == 2) printf("** Leaving BAD MAGIC on Eflag 2\n"); - else if (Oflag != 1) - sblock.fs_magic = FS_UFS2_MAGIC; + else + sblock.fs_magic = (Oflag != 1) ? FS_UFS2_MAGIC : FS_UFS1_MAGIC; /* * Now build the cylinders group blocks and Index: sys/ufs/ffs/fs.h =================================================================== RCS file: /home/mirror/freebsd/ncvs/src/sys/ufs/ffs/fs.h,v retrieving revision 1.40 diff -u -r1.40 fs.h --- sys/ufs/ffs/fs.h 16 Nov 2003 07:08:27 -0000 1.40 +++ sys/ufs/ffs/fs.h 27 Jan 2004 03:53:58 -0000 @@ -361,7 +361,7 @@ */ #define FS_UFS1_MAGIC 0x011954 /* UFS1 fast filesystem magic number */ #define FS_UFS2_MAGIC 0x19540119 /* UFS2 fast filesystem magic number */ -#define FS_BAD2_MAGIC 0x19960408 /* UFS2 incomplete newfs magic number */ +#define FS_BAD_MAGIC 0x19960408 /* UFS incomplete newfs magic number */ #define FS_OKAY 0x7c269d38 /* superblock checksum */ #define FS_42INODEFMT -1 /* 4.2BSD inode format */ #define FS_44INODEFMT 2 /* 4.4BSD inode format */ --- patch2 ends here --- From owner-freebsd-fs@FreeBSD.ORG Tue Jan 27 09:12:56 2004 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B9AB016A4CE; Tue, 27 Jan 2004 09:12:56 -0800 (PST) Received: from moo.sysabend.org (moo.sysabend.org [66.111.41.70]) by mx1.FreeBSD.org (Postfix) with ESMTP id C1B4643D5E; Tue, 27 Jan 2004 09:12:25 -0800 (PST) (envelope-from ragnar@sysabend.org) Received: by moo.sysabend.org (Postfix, from userid 1004) id CD35073C; Tue, 27 Jan 2004 09:10:56 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by moo.sysabend.org (Postfix) with ESMTP id CC06A49E; Tue, 27 Jan 2004 09:10:56 -0800 (PST) Date: Tue, 27 Jan 2004 09:10:56 -0800 (PST) From: Jamie Bowden To: Robert Watson In-Reply-To: Message-ID: <20040127090628.O78161-100000@moo.sysabend.org> X-representing: Only myself. X-badge: We don't need no stinking badges. X-obligatory-profanity: Fuck X-moo: Moo. MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: Josef Karthauser cc: freebsd-fs@FreeBSD.org cc: current@FreeBSD.org Subject: Re: Problems with NFS (client) under 5.1. X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Jan 2004 17:12:56 -0000 On Tue, 21 Oct 2003, Robert Watson wrote: > On Tue, 21 Oct 2003, Josef Karthauser wrote: > > I'm trying to set a FreeBSD 5.1 machine up as an NFS client. The > > server is on an SGI box. Things are strange: > Any chance you could grab a copy of ethereal and do a bit of on-the-wire > inspection of the RPCs? It would be interesting to know which of the > requests are serviced out of the client cache, and which make it to the > server. It would also be interesting to see if you can see failures in > the wire protocol, or if they're purely an artifact of the client. > Also, can you confirm the Linux and FreeBSD clients are both using the > same version of NFS with similar protocol settings (i.e., NFSv3 over > UDP). Something else here that needs to be looked at. On all my Irix boxes that I export to FBSD, Linux, or any other 32bit system I make sure I export with the following: /export/samba -rw,32bitclients wash-sgi wash-linux wash-freebsd That 32bitclients bit is important. I still have an Irix 5.3 machine here, and it needs it as well as the Freenixes. Jamie Bowden -- "It was half way to Rivendell when the drugs began to take hold" Hunter S Tolkien "Fear and Loathing in Barad Dur" Iain Bowen From owner-freebsd-fs@FreeBSD.ORG Tue Jan 27 13:40:05 2004 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9460216A4CE; Tue, 27 Jan 2004 13:40:05 -0800 (PST) Received: from smtp.omnis.com (smtp.omnis.com [216.239.128.26]) by mx1.FreeBSD.org (Postfix) with ESMTP id AC3B243D73; Tue, 27 Jan 2004 13:39:37 -0800 (PST) (envelope-from wes@softweyr.com) Received: from salty.rapid.stbernard.com (corp-2.ipinc.com [199.245.188.2]) by smtp-relay.omnis.com (Postfix) with ESMTP id C0BA58836C0; Tue, 27 Jan 2004 13:37:56 -0800 (PST) From: Wes Peters Organization: Softweyr.com To: Xin LI , FreeBSD-gnats-submit@freebsd.org Date: Tue, 27 Jan 2004 13:37:30 -0800 User-Agent: KMail/1.5.4 References: <20040127065331.43F7611AE7@beastie.frontfree.net> In-Reply-To: <20040127065331.43F7611AE7@beastie.frontfree.net> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200401271337.30976.wes@softweyr.com> X-Mailman-Approved-At: Wed, 28 Jan 2004 06:15:23 -0800 cc: mckusick@FreeBSD.org Subject: Re: [PATCH] bring incompletely initialized magic to UFS1 X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Jan 2004 21:40:05 -0000 On Monday 26 January 2004 22:53, Xin LI wrote: > >Submitter-Id: current-users > >Originator: Xin LI > >Organization: The FreeBSD Simplified Chinese Project > >Confidential: no > >Synopsis: [PATCH] bring incompletely initialized magic to UFS1 > >Severity: non-critical > >Priority: low > >Category: bin > >Class: change-request > >Release: FreeBSD 5.2-RELEASE i386 > >Environment: > > System: FreeBSD beastie.frontfree.net 5.2-RELEASE FreeBSD 5.2-RELEASE > #16: Sat Jan 10 15:24:09 CST 2004 > delphij@beastie.frontfree.net:/usr/obj/usr/src/sys/BEASTIE i386 > > >Description: > > The attached is a proposal patch to make it possible to mark UFS1 as > "incompletely initialized" when newfs(8) did not have it actually > initialized. To implement this, I have borrowed the "bad UFS2" magic > number. Please review this patch. Frankly I am not sure if this is > useful in most circumstances, but a "incomplete" flag is really > useful for certain needs. I looks OK to me. I assume you've tested it extensively, correct? I'll see if I can locate an extra disk for testing and give this a try at home, then commit it as soon as I've verified it works OK. Thanks for the input. -- "Where am I, and what am I doing in this handbasket?" Wes Peters wes@softweyr.com From owner-freebsd-fs@FreeBSD.ORG Thu Jan 29 05:57:37 2004 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 225DE16A4CE; Thu, 29 Jan 2004 05:57:37 -0800 (PST) Received: from ftp.bjpu.edu.cn (ftp.bjpu.edu.cn [202.112.78.5]) by mx1.FreeBSD.org (Postfix) with ESMTP id B4D4D43D41; Thu, 29 Jan 2004 05:57:18 -0800 (PST) (envelope-from delphij@frontfree.net) Received: by ftp.bjpu.edu.cn (Postfix, from userid 426) id BA4D05358; Thu, 29 Jan 2004 21:57:17 +0800 (CST) Received: from beastie.frontfree.net (beastie.frontfree.net [218.107.145.7]) by ftp.bjpu.edu.cn (Postfix) with ESMTP id 933E75299; Thu, 29 Jan 2004 21:57:17 +0800 (CST) Received: by beastie.frontfree.net (Postfix, from userid 1001) id 3416B1176B; Thu, 29 Jan 2004 21:57:16 +0800 (CST) Date: Thu, 29 Jan 2004 21:57:16 +0800 From: Xin LI To: Wes Peters Message-ID: <20040129135716.GC53644@frontfree.net> References: <20040127065331.43F7611AE7@beastie.frontfree.net> <200401271337.30976.wes@softweyr.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="aT9PWwzfKXlsBJM1" Content-Disposition: inline In-Reply-To: <200401271337.30976.wes@softweyr.com> User-Agent: Mutt/1.4.1i X-GPG-key-ID/Fingerprint: 0xCAEEB8C0 / 43B8 B703 B8DD 0231 B333 DC28 39FB 93A0 CAEE B8C0 X-GPG-Public-Key: http://www.delphij.net/delphij.asc X-Operating-System: FreeBSD beastie.frontfree.net 5.2-RELEASE FreeBSD 5.2-RELEASE #16: Sat Jan 10 15:24:09 CST 2004 delphij@beastie.frontfree.net:/usr/obj/usr/src/sys/BEASTIE i386 X-URL: http://www.delphij.net X-By: delphij@beastie.frontfree.net X-Location: Beijing, China cc: freebsd-fs@FreeBSD.org cc: FreeBSD-gnats-submit@freebsd.org cc: wes@FreeBSD.org cc: mckusick@FreeBSD.org Subject: Re: [PATCH] bring incompletely initialized magic to UFS1 X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Jan 2004 13:57:37 -0000 --aT9PWwzfKXlsBJM1 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Jan 27, 2004 at 01:37:30PM -0800, Wes Peters wrote: > I looks OK to me. I assume you've tested it extensively, correct? I'll= =20 > see if I can locate an extra disk for testing and give this a try at=20 > home, then commit it as soon as I've verified it works OK. Thanks for=20 > the input. I have tested it with newfs -E -E, and a small (3.06GB) slice on a spare box, and it seems to be work well. I just wonder if it's OK to rename the BAD_UFS2 magic to BAD_UFS and I hope the change will not break something depending on the magic number. (I have grep'ed and replaced all BAD_UFS2 instances in the src tree, and tested with a make world/kernel build and everything seems goes ok). Thank you for the timely response. Cheers, -- Xin LI http://www.delphij.net/ See complete headers for GPG key and other information. --aT9PWwzfKXlsBJM1 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (FreeBSD) iD8DBQFAGRE7OfuToMruuMARAvMdAJ9p07Z3mEZsy+t03g/cRM3J+BldegCfQ4HC vuiKFUbQIgpiSs/P1Nd+vlY= =XmVp -----END PGP SIGNATURE----- --aT9PWwzfKXlsBJM1 Content-Type: text/plain Scanned by evaluation version of Dr.Web antivirus Daemon http://drweb.ru/unix/ --aT9PWwzfKXlsBJM1-- From owner-freebsd-fs@FreeBSD.ORG Thu Jan 29 13:39:46 2004 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1941E16A4CE for ; Thu, 29 Jan 2004 13:39:46 -0800 (PST) Received: from lakemtao06.cox.net (lakemtao06.cox.net [68.1.17.115]) by mx1.FreeBSD.org (Postfix) with ESMTP id DC78543D46 for ; Thu, 29 Jan 2004 13:39:44 -0800 (PST) (envelope-from kitbsdlist2@HotPOP.com) Received: from vixen42 ([68.109.49.234]) by lakemtao06.cox.net (InterMail vM.5.01.06.05 201-253-122-130-105-20030824) with SMTP id <20040129213944.XAEN24575.lakemtao06.cox.net@vixen42> for ; Thu, 29 Jan 2004 16:39:44 -0500 Date: Thu, 29 Jan 2004 15:38:21 -0600 From: Vulpes Velox To: freebsd-fs@freebsd.org Message-Id: <20040129153821.37df0392@vixen42.> X-Mailer: Sylpheed version 0.9.8claws (GTK+ 1.2.10; i386-portbld-freebsd4.9) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Subject: vinum and processor question X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Jan 2004 21:39:46 -0000 How much power do I need for vinum to run well? Currently looking at putting together a 1.4TB raid5 using it and then either sata or ata133. It will be transfering 100 to 200Mbps and on rare occasions 300Mbps. The board I am currently looking at is dual xeon. From owner-freebsd-fs@FreeBSD.ORG Thu Jan 29 17:04:22 2004 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6EF6916A4CE for ; Thu, 29 Jan 2004 17:04:22 -0800 (PST) Received: from ozlabs.org (ozlabs.org [203.10.76.45]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7124643D53 for ; Thu, 29 Jan 2004 17:04:20 -0800 (PST) (envelope-from grog@lemis.com) Received: from blackwater.lemis.com (blackwater.lemis.com [192.109.197.80]) by ozlabs.org (Postfix) with ESMTP id 64C882BD7B for ; Fri, 30 Jan 2004 12:04:18 +1100 (EST) Received: by blackwater.lemis.com (Postfix, from userid 1004) id 4985151205; Fri, 30 Jan 2004 11:34:15 +1030 (CST) Date: Fri, 30 Jan 2004 11:34:15 +1030 From: Greg 'groggy' Lehey To: Vulpes Velox Message-ID: <20040130010415.GS49973@wantadilla.lemis.com> References: <20040129153821.37df0392@vixen42.> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="uQ3BaAlxDi9XKvis" Content-Disposition: inline In-Reply-To: <20040129153821.37df0392@vixen42.> User-Agent: Mutt/1.4.1i Organization: The FreeBSD Project Phone: +61-8-8388-8286 Fax: +61-8-8388-8725 Mobile: +61-418-838-708 WWW-Home-Page: http://www.FreeBSD.org/ X-PGP-Fingerprint: 9A1B 8202 BCCE B846 F92F 09AC 22E6 F290 507A 4223 cc: freebsd-fs@freebsd.org Subject: Re: vinum and processor question X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Jan 2004 01:04:22 -0000 --uQ3BaAlxDi9XKvis Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Thursday, 29 January 2004 at 15:38:21 -0600, Vulpes Velox wrote: > How much power do I need for vinum to run well? Almost none. > Currently looking at putting together a 1.4TB raid5 using it and > then either sata or ata133. It will be transfering 100 to 200Mbps > and on rare occasions 300Mbps. The board I am currently looking at > is dual xeon. It'll be almost impossible to transfer those kind of rates for any extended period of time. About the only time when Vinum uses significant amounts of CPU time is during the parity calculations for RAID-5 writes. When developing it, on a 486-66, I was able to detect measurable amounts of CPU time usage, about 10% under those circumstances. That's probably still the case with your config: both processor and disks are faster by about the same proportion. But I don't expect you'll be using RAID-5 for writing only. Greg -- See complete headers for address and phone numbers. --uQ3BaAlxDi9XKvis Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.0 (FreeBSD) iD8DBQFAGa2PIubykFB6QiMRAl1KAJwJMXXd8QXu2wCoLkaSXnjhL5eJ6QCgjPWE 8TU9+mLAH6C1HKL6XxxrcbA= =voST -----END PGP SIGNATURE----- --uQ3BaAlxDi9XKvis-- From owner-freebsd-fs@FreeBSD.ORG Sat Jan 31 05:30:37 2004 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9C82916A4CE; Sat, 31 Jan 2004 05:30:37 -0800 (PST) Received: from milla.ask33.net (milla.ask33.net [217.197.166.60]) by mx1.FreeBSD.org (Postfix) with ESMTP id 52F8543D3F; Sat, 31 Jan 2004 05:30:35 -0800 (PST) (envelope-from nick@milla.ask33.net) Received: by milla.ask33.net (Postfix, from userid 1001) id 827483ABB53; Sat, 31 Jan 2004 14:31:59 +0100 (CET) Date: Sat, 31 Jan 2004 14:31:59 +0100 From: Pawel Jakub Dawidek To: freebsd-fs@freebsd.org Message-ID: <20040131133158.GE72053@garage.freebsd.pl> References: <20040126230034.GK565@garage.freebsd.pl> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-md5; protocol="application/pgp-signature"; boundary="5CUMAwwhRxlRszMD" Content-Disposition: inline In-Reply-To: <20040126230034.GK565@garage.freebsd.pl> X-PGP-Key-URL: http://garage.freebsd.pl/jules.asc X-OS: FreeBSD 4.8-RELEASE-p13 i386 X-URL: http://garage.freebsd.pl User-Agent: Mutt/1.5.1i cc: rwatson@freebsd.org Subject: Re: Analysis of mounts/unmounts issues. X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 31 Jan 2004 13:30:37 -0000 --5CUMAwwhRxlRszMD Content-Type: text/plain; charset=iso-8859-2 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Jan 27, 2004 at 12:00:34AM +0100, Pawel Jakub Dawidek wrote: +> This is a short analysis of mount(2)/unmount(2) problems related to +> usermounts, unprivileged root and jails. +>=20 +> I've found many issues related to this topic, here is a list of those is= sues: +>=20 +> 1. Root from inside of jail is able to unmount _any_ file system +> (except /) from even outside of jail. +> 2. Even if security.bsd.suser is set to 0, root is able to unmount +> file systems mounted by provileged root (except /). +> 3. If usermount is set to 1, user from inside of jail is able to +> mount file system (if support for required file system is +> compiled in kernel of loaded as a kld module), but with +> MNT_NOSUID and MNT_NODEV flags set. +> Insufficient check is in two place: for normal mounts and +> for mounts with MNT_UPDATE flag set. +> 4. Let's assume that usermount is set to 1 and user mounts file system, +> now we're setting usermount to 0 and user is still able to +> unmount file system mounted by him previously. +>=20 +> My fix deny any mounts/unmounts inside of jail and deny mounts/unmounts +> for unprivileged root, because there is no chance to check if +> security.bsd.suser was 0 or 1 while file system was mounted. +> Patch is here: +>=20 +> http://garage.freebsd.pl/patches/vfs_mount.c.2.patch +>=20 +> Things to discuss. +>=20 +> Should we permit mounts/unmounts inside of jail if usermount is set to 1? +> Maybe there should be 'jailmount' variable to control this? +>=20 +> Should we store in mount structure value of security.bsd.suser while +> file system is mounted to permit unmount and mount with MNT_UPDATE flag = set +> operations for unprivileged root? This will give as a complete solution. Ok, I got complete solution. While I was looking on mksnap_ffs issue, I've found that we've MNT_USER flag to mark file systems mounted by unprivileged users. This flag is not used currently. Patch is here: http://garage.freebsd.pl/patches/mount.patch Patch made use of MNT_USER flag, so if file system is mounted by unprivileg= ed root, it can be unmounted by him as well. Mount(8) has been modified to print 'mounted by ' for unprivileged root also. --=20 Pawel Jakub Dawidek pawel@dawidek.net UNIX Systems Programmer/Administrator http://garage.freebsd.pl Am I Evil? Yes, I Am! http://cerber.sourceforge.net --5CUMAwwhRxlRszMD Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.7 (FreeBSD) iQCVAwUBQBuuTj/PhmMH/Mf1AQEskgP5AfWJbUeLRZWRhcAas/ifhTCUq0QuDOm7 q9xrCzcwlkgbagLTHasd/Csrnzy07XQYkq/vWFRPwfri0dZ55lTRv/4jHMUF3u0x n1yQOqr0oSwYldLJLtCF3GSajxsjphvnBwl10C3rZdBqPnyn2cGOuaQUFYnKNPck KVernakb5w0= =vulA -----END PGP SIGNATURE----- --5CUMAwwhRxlRszMD-- From owner-freebsd-fs@FreeBSD.ORG Sat Jan 31 18:59:47 2004 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2A94A16A4CE for ; Sat, 31 Jan 2004 18:59:47 -0800 (PST) Received: from fledge.watson.org (fledge.watson.org [204.156.12.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id E24B043D1D for ; Sat, 31 Jan 2004 18:59:45 -0800 (PST) (envelope-from robert@fledge.watson.org) Received: from fledge.watson.org (localhost [127.0.0.1]) by fledge.watson.org (8.12.10/8.12.10) with ESMTP id i112vHUd017911; Sat, 31 Jan 2004 21:57:17 -0500 (EST) (envelope-from robert@fledge.watson.org) Received: from localhost (robert@localhost)i112vH20017908; Sat, 31 Jan 2004 21:57:17 -0500 (EST) (envelope-from robert@fledge.watson.org) Date: Sat, 31 Jan 2004 21:57:17 -0500 (EST) From: Robert Watson X-Sender: robert@fledge.watson.org To: Pawel Jakub Dawidek In-Reply-To: <20040131133158.GE72053@garage.freebsd.pl> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: freebsd-fs@freebsd.org Subject: Re: Analysis of mounts/unmounts issues. X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 01 Feb 2004 02:59:47 -0000 On Sat, 31 Jan 2004, Pawel Jakub Dawidek wrote: > Ok, I got complete solution. > > While I was looking on mksnap_ffs issue, I've found that we've MNT_USER > flag to mark file systems mounted by unprivileged users. This flag is > not used currently. > > Patch is here: > > http://garage.freebsd.pl/patches/mount.patch > > Patch made use of MNT_USER flag, so if file system is mounted by > unprivileged root, it can be unmounted by him as well. Mount(8) has > been modified to print 'mounted by ' for unprivileged root also. I like this much better, and think the fix looks generally good. I think leaving mount/umount disabled in jail for now, regardless of the MNT_USER fix, is a good idea to be on the conservative side, but it might well be worth continuing to explore usermount in jail in the future. The risk, as already observed, is that jail's protections rely in large part on very careful management of the file system namespace, and mount/umount on that namespace implies a lot of risk. Robert N M Watson FreeBSD Core Team, TrustedBSD Projects robert@fledge.watson.org Senior Research Scientist, McAfee Research From owner-freebsd-fs@FreeBSD.ORG Sun Feb 1 17:33:34 2004 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7BD3416A4CE for ; Sun, 1 Feb 2004 17:33:34 -0800 (PST) Received: from smtp2.mts.net (smtp2.mts.net [205.200.16.113]) by mx1.FreeBSD.org (Postfix) with ESMTP id 653A943D1D for ; Sun, 1 Feb 2004 17:33:33 -0800 (PST) (envelope-from gval@mts.net) Received: from [192.168.0.5] (wnpgmb01dc6-40-11.dynamic.mts.net [142.161.40.11])i121XWSV015547 for ; Sun, 1 Feb 2004 19:33:32 -0600 (CST) From: greg To: freebsd-fs@freebsd.org Content-Type: text/plain Message-Id: <1075685603.914.6.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.5 Date: Sun, 01 Feb 2004 19:33:23 -0600 Content-Transfer-Encoding: 7bit Subject: Structure of UFS2 filesystem X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Feb 2004 01:33:34 -0000 I am looking for resources that describe the UFS2 filesystem structure. I want to write some code that will pull a UFS2 filesystem back from the dead. It has a bad Super Block, and no good Super Blocks can be found. However, I sifted through the raw data on the disk, and my data is still there. Could somebody point me to documentation on this subject. I have tried googling through the BSD filter. I received no useful results. I looked at the source code for ffs, but it is a bit hard to read without a basic understand of how the filesystem is structured. If the tools I write are any good, I will make the source code available under a BSD style licence. Thank You, -- greg From owner-freebsd-fs@FreeBSD.ORG Mon Feb 2 10:16:31 2004 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0C91D16A4CE; Mon, 2 Feb 2004 10:16:31 -0800 (PST) Received: from fons-adae.s.notwork.org (fons-adae.s.notwork.org [218.224.220.115]) by mx1.FreeBSD.org (Postfix) with ESMTP id ED36243D31; Mon, 2 Feb 2004 10:16:26 -0800 (PST) (envelope-from mrt@notwork.org) Received: from fons-adae.s.notwork.org (fons-adae.s.notwork.org [IPv6:2001:218:420::3]) by fons-adae.s.notwork.org (Postfix) with ESMTP id DBBA43485; Tue, 3 Feb 2004 03:16:23 +0900 (JST) To: Zack Hobson X-cite: xcite 1.49 From: Murata Shuuichirou In-Reply-To: <1074080151.733.51.camel@cyclops.thehouse> (Zack Hobson's message of "Wed, 14 Jan 2004 03:35:51 -0800") References: <1074080151.733.51.camel@cyclops.thehouse> Date: Tue, 03 Feb 2004 03:16:21 +0900 Message-ID: <87ad41z6ru.fsf@fons-adae.s.notwork.org> User-Agent: Gnus/5.110002 (No Gnus v0.2) Emacs/22.0.0 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii cc: yar@freebsd.org cc: fs@freebsd.org Subject: Re: updating HFS for 5.2R [patch] X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Feb 2004 18:16:31 -0000 In message <1074080151.733.51.camel@cyclops.thehouse>, `zgh@malfunktion.net' wrote: > With these changes, the code compiles. I can install and load the > resulting kernel module, and I can sucessfully use newfs_hfs and > fsck_hfs, but mount_hfs on the same volume always fails with an > "Input/output error". If you have not gotten good results yet, try attached patch. Of course, your patch is also needed. With this patch, I can mount hfs successfully. Creating and removing files on the filesystem are also succeeded. But, I have not tested this fully and found some problems such as: 1. Sometime, hfs partitions become unmountable by FreeBSD (mount_hfs returns "Invalid argument"), although the partition can still be mounted by MacOSX. 2. After editing files on hfs filesystem with vi(1), umounting the filesystem causes these errors: Feb 2 21:13:11 roma kernel: hfs_fsync: dirty: 0xc2d74000: tag hfs, type VREG, usecount 2, writecount 0, refcount 2, flags (VV_SYSTEM), lock type cnode: EXCL (count 1) by thread 0xc2b42a80 (pid 1068) Feb 2 21:13:11 roma kernel: tag VT_HFS, cnid 4, on dev 4, 24 lock type cnode: EXCL (count 1) by thread 0xc2b42a80 (pid 1068) (lots of same errors continue) Then system crashed. These problems seem to occur on FreeBSD-5.1-RELEASE with original hfs-freebsd-03.tar.gz, too. So please use it with care. -- MURATA Shuuichirou --- darwin/xnu/bsd/hfs/hfs_readwrite.c 2004/01/29 13:55:22 1.1 +++ darwin/xnu/bsd/hfs/hfs_readwrite.c 2004/02/02 05:34:47 @@ -1452,6 +1452,9 @@ #ifdef DARWIN return VOCALL (vp->v_op, VOFFSET(vop_strategy), ap); #else +#if __FreeBSD_version >= 501112 /* XXX */ + bp->b_iooffset = dbtob(bp->b_blkno); +#endif #if __FreeBSD_version >= 500100 /* YYY the change has had no version bump */ VOP_SPECSTRATEGY(vp, bp); #else From owner-freebsd-fs@FreeBSD.ORG Tue Feb 3 06:13:27 2004 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 83A0116A4CE for ; Tue, 3 Feb 2004 06:13:27 -0800 (PST) Received: from smtp004.mail.ukl.yahoo.com (smtp004.mail.ukl.yahoo.com [217.12.11.35]) by mx1.FreeBSD.org (Postfix) with SMTP id B8B8D43D41 for ; Tue, 3 Feb 2004 06:13:08 -0800 (PST) (envelope-from niels_ole@salscheider-online.de) Received: from unknown (HELO ole) (niels?ole?salscheider@80.132.230.84 with login) by smtp004.mail.ukl.yahoo.com with SMTP; 3 Feb 2004 14:13:07 -0000 From: "Niels Ole Salscheider" To: Date: Tue, 3 Feb 2004 15:13:06 +0100 X-Mailer: Microsoft Office Outlook, Build 11.0.5510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Thread-Index: AcPqX9fpP8Ccmf5OTx2xUoH7DYDsSw== Message-Id: <20040203141308.B8B8D43D41@mx1.FreeBSD.org> Subject: X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Feb 2004 14:13:27 -0000 Hello, I've just installed FreeBSD and configured some servers. But then I recognized that my /-partition is too small. Is there any way to change the size of pratitions without loosing data (to make my /usr-partition smaller and my /-partition bigger)? Thank you Niels Ole Salscheider begin 666 Niels Ole Salscheider (niels_ole@salscheider-online.de).vcf M0D5'24XZ5D-!4D0-"E9%4E-)3TXZ,BXQ#0I..E-A;'-C:&5I9&5R.TYI96QS M.T]L90T*1DXZ3FEE;',@3VQE(%-A;'-C:&5I9&5R("AN:65L Delivered-To: freebsd-fs@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0276C16A4CE; Tue, 3 Feb 2004 20:00:27 -0800 (PST) Received: from mta7.pltn13.pbi.net (mta7.pltn13.pbi.net [64.164.98.8]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7836843FEB; Tue, 3 Feb 2004 20:00:17 -0800 (PST) (envelope-from zgh@malfunktion.net) Received: from balrog.thehouse (adsl-68-122-117-229.dsl.pltn13.pacbell.net [68.122.117.229])id i144013P008135; Tue, 3 Feb 2004 20:00:16 -0800 (PST) Received: from [10.0.0.6] (cyclops.thehouse [10.0.0.6]) by balrog.thehouse (Postfix) with ESMTP id 8E5313308; Tue, 3 Feb 2004 19:59:44 -0800 (PST) From: Zack Hobson To: Murata Shuuichirou In-Reply-To: <87ad41z6ru.fsf@fons-adae.s.notwork.org> References: <1074080151.733.51.camel@cyclops.thehouse> <87ad41z6ru.fsf@fons-adae.s.notwork.org> Content-Type: text/plain Message-Id: <1075867224.675.7.camel@cyclops.thehouse> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.5 Date: Tue, 03 Feb 2004 20:00:24 -0800 Content-Transfer-Encoding: 7bit cc: yar@freebsd.org cc: fs@freebsd.org Subject: Re: updating HFS for 5.2R [patch] X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Feb 2004 04:00:27 -0000 On Mon, 2004-02-02 at 10:16, Murata Shuuichirou wrote: > In message <1074080151.733.51.camel@cyclops.thehouse>, > `zgh@malfunktion.net' wrote: > > With these changes, the code compiles. I can install and load the > > resulting kernel module, and I can sucessfully use newfs_hfs and > > fsck_hfs, but mount_hfs on the same volume always fails with an > > "Input/output error". > > If you have not gotten good results yet, try attached patch. Of > course, your patch is also needed. This is great news, thanks. There is no way I would have figured that out myself. Can you give me any insight into why the changes you made were needed? Anyway, the problems that you're encountering now probably have to do with the fact that I did not properly update some of the locking code in my patch, I simply worked around it to get it to compile. The B_LOCKED (AFAIR) flag disappeared and I worked around the problem by simply defining it in my own code. I think your changes exposed this ugly hack of mine, but this is great news! Now all I need to do (hopefully) is figure out what to use instead of the now-obsolete B_LOCKED flag. Anyone have any ideas? Thanks and regards, -zack From owner-freebsd-fs@FreeBSD.ORG Fri Feb 6 11:33:20 2004 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id BBE2F16A4D3 for ; Fri, 6 Feb 2004 11:33:20 -0800 (PST) Received: from mail.lucidix.com (65-42-56-8.ded.ameritech.net [65.42.56.8]) by mx1.FreeBSD.org (Postfix) with SMTP id DA11443D4C for ; Fri, 6 Feb 2004 11:33:18 -0800 (PST) (envelope-from phil@skyscrapes.com) Received: (qmail 17911 invoked from network); 6 Feb 2004 19:33:17 -0000 Received: from unknown (HELO Su37) (phil@skyscrapes.com@132.156.63.39) by 65-42-56-11.ded.ameritech.net with SMTP; 6 Feb 2004 19:33:17 -0000 From: "Philippe Dorman" To: Date: Fri, 6 Feb 2004 14:32:34 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook, Build 11.0.5510 Thread-Index: AcPs5/g/sQHPDOMIQyO/5l2ljfPS4w== X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Message-Id: <20040206193318.DA11443D4C@mx1.FreeBSD.org> Subject: WD160 + Drive geometry problem X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Feb 2004 19:33:20 -0000 Hiya, I recently got a 160 gig hard drive, it seems to be mounted properly, partitions and slices "seem" fine, yet I cant write more than = 2k to the disk, it's just as if there wasn't any free space left. I'm using = a Promise Ultra ATA/133 controller, which does support drives greater than = 137 gigs so that shouldn't be the problem. I'm running 5.1-Current. Here's = the output to a couple commands=20 First from dmesg ad4: 19546MB [39714/16/63] at ata2-master UDMA100 ad5: 76319MB [155061/16/63] at ata2-slave UDMA100 ad6: 39205MB [79656/16/63] at ata3-master UDMA133 ad7: 152627MB [310101/16/63] at ata3-slave UDMA100 df Filesystem =A01K-blocks =A0 =A0 Used =A0 =A0 Avail Capacity =A0Mounted = on /dev/ad4s1a =A0 =A0253678 =A0 251702 =A0 =A0-18318 =A0 108% =A0 =A0/ devfs =A0 =A0 =A0 =A0 =A0 =A0 =A0 1 =A0 =A0 =A0 =A01 =A0 =A0 =A0 =A0 0 = =A0 100% =A0 =A0/dev /dev/ad4s1e =A0 =A0253678 =A0 =A0 =A0 =A02 =A0 =A0233382 =A0 =A0 0% =A0 = =A0/tmp /dev/ad4s1f =A018121388 =A02997228 =A013674450 =A0 =A018% =A0 =A0/usr /dev/ad4s1d =A0 =A0253678 =A0 =A033436 =A0 =A0199948 =A0 =A014% =A0 = =A0/var /dev/ad7s1 =A0151368706 =A0 =A0 =A0 =A02 139259208 =A0 =A0 0% =A0 = =A0/hd1 /dev/ad6s1 =A0 38879438 32184422 =A0 3584662 =A0 =A090% =A0 =A0/hd2 /dev/ad5s1 =A0 75685352 69630522 =A0 =A0 =A0 =A0 2 =A0 100% =A0 =A0/hd3 Then disklabel ad7s1 (starts to get interesting here - 8 partitions?) # /dev/ad7s1: 8 partitions: # =A0 =A0 =A0 =A0size =A0 offset =A0 =A0fstype =A0 [fsize bsize bps/cpg] =A0c: 312576642 =A0 =A0 =A0 63 =A0 =A0unused =A0 =A0 =A0 =A00 =A0 =A0 0 = =A0 =A0 =A0 =A0 # "raw" part, don't edit =A0d: 312576642 =A0 =A0 =A0 63 =A0 =A04.2BSD =A0 =A0 2048 16384 28552 partition c: partition extends past end of unit disklabel: partition c doesn't start at 0! disklabel: An incorrect partition c may cause problems for standard = system utilities partition d: partition extends past end of unit I'm not sure if it has to do with the drive geometry, I stuck the drive = in my windows box and got the following geometry, 16709/255/63 (however it wasn't recognizing more than 137gig). When I use the fdisk utility it = tells me that the geometry of 310101/16/63 (which is what you can find on the western digital website in the drive specs) is incorrect, and that it is using a more likely geometry. I try to set it back to the default, but = the changes don't seem to "stick", or change the fact that I can't use the = hard disk. Any help is appreciated! -Phil From owner-freebsd-fs@FreeBSD.ORG Fri Feb 6 23:13:22 2004 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4FEBB16A4CF for ; Fri, 6 Feb 2004 23:13:22 -0800 (PST) Received: from carver.gumbysoft.com (carver.gumbysoft.com [66.220.23.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5475243D54 for ; Fri, 6 Feb 2004 23:13:21 -0800 (PST) (envelope-from dwhite@gumbysoft.com) Received: by carver.gumbysoft.com (Postfix, from userid 1000) id 4524572DBF; Fri, 6 Feb 2004 23:13:21 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by carver.gumbysoft.com (Postfix) with ESMTP id 4023A72DB5; Fri, 6 Feb 2004 23:13:21 -0800 (PST) Date: Fri, 6 Feb 2004 23:13:21 -0800 (PST) From: Doug White To: Philippe Dorman In-Reply-To: <20040206193318.DA11443D4C@mx1.FreeBSD.org> Message-ID: <20040206231226.D20729@carver.gumbysoft.com> References: <20040206193318.DA11443D4C@mx1.FreeBSD.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=iso-8859-1 Content-Transfer-Encoding: QUOTED-PRINTABLE cc: freebsd-fs@freebsd.org Subject: Re: WD160 + Drive geometry problem X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Feb 2004 07:13:22 -0000 On Fri, 6 Feb 2004, Philippe Dorman wrote: > I recently got a 160 gig hard drive, it seems to be mounted > properly, partitions and slices "seem" fine, yet I cant write more than 2= k > to the disk, it's just as if there wasn't any free space left. I'm using = a > Promise Ultra ATA/133 controller, which does support drives greater than = 137 > gigs so that shouldn't be the problem. I'm running 5.1-Current. Here's th= e > output to a couple commands Well, there isn't since you're using the auto partition defaults and filling up /. > /dev/ad4s1a =A0 =A0253678 =A0 251702 =A0 =A0-18318 =A0 108% =A0 =A0/ oops. > /dev/ad5s1 =A0 75685352 69630522 =A0 =A0 =A0 =A0 2 =A0 100% =A0 =A0/hd3 Oops again. Try deleting some files. --=20 Doug White | FreeBSD: The Power to Serve dwhite@gumbysoft.com | www.FreeBSD.org From owner-freebsd-fs@FreeBSD.ORG Sat Feb 7 04:09:32 2004 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E69E116A4CE for ; Sat, 7 Feb 2004 04:09:32 -0800 (PST) Received: from lxmail.xebeo.com (gwnj8.utstar.com [65.200.123.8]) by mx1.FreeBSD.org (Postfix) with SMTP id 7EB7E43D1D for ; Sat, 7 Feb 2004 04:09:32 -0800 (PST) (envelope-from amit.khivesara@utstar.com) Received: (qmail 10182 invoked by uid 404); 4 Feb 2004 20:09:30 -0000 Received: from amit.khivesara@utstar.com by lxmail by uid 401 with qmail-scanner-1.20rc1 (clamscan: 0.60. spamassassin: 2.55. Clear:RC:1:. Processed in 0.023876 secs); 04 Feb 2004 20:09:30 -0000 Received: from mojo.nj.us.utstar.com (HELO utstar.com) (172.16.36.18) by lxmail.nj.us.utstar.com with SMTP; 4 Feb 2004 20:09:30 -0000 Message-ID: <40215112.2030701@utstar.com> Date: Wed, 04 Feb 2004 15:07:46 -0500 From: Amit Khivesara User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.5) Gecko/20031007 X-Accept-Language: en-us, en MIME-Version: 1.0 To: freebsd-fs@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Msdos fsync X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Feb 2004 12:09:33 -0000 Hi, The fsync for msdos does not seem to sync the FAT entries. Hence the file can be corrupted if the syncer has not come in and synced the entries. If anyone is interested I have added a function fat_sync to do this. This will allow the msdos fsync really "sync" the file. The diffs are given below for kernel 4.1.1. I am new to this mailing list. If this is a unappropriate post, then let me know. khivi diff msdosfs/fat.h msdosfs.new/fat.h 106a107 >> void fat_sync __P((struct vnode * , struct denode *dep)); diff msdosfs/msdosfs_fat.c msdosfs.new/msdosfs_fat.c 325a326,398 >> * Sync the fat cache in denode dep of all entries relating to file >> */ >> void >> fat_sync(vnode,dep) >> struct vnode *vnode; >> struct denode *dep; >> { >> u_long cn; >> u_long prevcn; >> >> u_long byteoffset; >> u_long bsize; >> u_long bo; >> u_long bn; >> u_long bp_bn = -1; >> int error; >> struct buf *bp = NULL; >> struct msdosfsmount *pmp = dep->de_pmp; >> >> u_int pm_flags=pmp->pm_flags; >> pmp->pm_flags |= MSDOSFSMNT_WAITONFAT; >> >> cn=dep->de_StartCluster; >> while (1){ >> /* >> * Stop with all reserved clusters, not just with EOF. >> */ >> if ((cn | ~pmp->pm_fatmask) >= CLUST_RSRVD) >> goto hiteof; >> byteoffset = FATOFS(pmp, cn); >> fatblock(pmp, byteoffset, &bn, &bsize, &bo); >> if (bn != bp_bn) { >> if (bp) { >> updatefats(pmp, bp, bp_bn); >> } >> error = bread(pmp->pm_devvp, bn, bsize, NOCRED, &bp); >> if (error) { >> brelse(bp); >> goto func_ret; >> } >> bp_bn = bn; >> } >> >> prevcn = cn; >> if (FAT32(pmp)) >> cn = getulong(&bp->b_data[bo]); >> else >> cn = getushort(&bp->b_data[bo]); >> if (FAT12(pmp) && (prevcn & 1)) >> cn >>= 4; >> cn &= pmp->pm_fatmask; >> >> /* >> * Force the special cluster numbers >> * to be the same for all cluster sizes >> * to let the rest of msdosfs handle >> * all cases the same. >> */ >> if ((cn | ~pmp->pm_fatmask) >= CLUST_RSRVD) >> cn |= ~pmp->pm_fatmask; >> } >> >> >> hiteof: >> if (bp) { >> updatefats(pmp, bp, bp_bn); >> } >> func_ret: >> pmp->pm_flags=pm_flags; >> return; >> } >> >> /* diff msdosfs/msdosfs_vnops.c msdosfs.new/msdosfs_vnops.c 869a870,872 >> fat_sync(vp,VTODE(vp)); From owner-freebsd-fs@FreeBSD.ORG Sat Feb 7 05:56:31 2004 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 43D1A16A4CE for ; Sat, 7 Feb 2004 05:56:31 -0800 (PST) Received: from rdsnet.ro (smtp.rdsnet.ro [62.231.74.130]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6519143D1F for ; Sat, 7 Feb 2004 05:56:30 -0800 (PST) (envelope-from itetcu@apropo.ro) Received: (qmail 14676 invoked from network); 7 Feb 2004 13:56:28 -0000 Received: from unknown (HELO it.buh.cameradicommercio.ro) (81.196.25.19) by mail.rdsnet.ro with SMTP; 7 Feb 2004 13:56:28 -0000 Date: Sat, 7 Feb 2004 15:58:19 +0200 From: Ion-Mihai Tetcu To: freebsd-fs@freebsd.org Message-Id: <20040207155819.186335d4@it.buh.cameradicommercio.ro> X-Mailer: Sylpheed version 0.9.8claws (GTK+ 1.2.10; i386-portbld-freebsd5.2) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Subject: Painful speed for copying to fat32 partitions with small cluster size. X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Feb 2004 13:56:31 -0000 Hi, Does anyone know why this happens or what to do ? Setup: UDMA133 primary master, UFS2; UDMA100 secondary master, FAT32. Copying to FAT32 partitions is very slow with small cluster sizes (I was copying some 300 - 700MB files): FAT32 clustersize=4K 500KB/s FAT32 clustersize=32K 3.5MB/s FAT32 clustersize=64K 6.2MB/s FAT32 clustersize=128K 6.4MB/s FAT16 6.5MB/s Reading speed is the same. Same experience for newfs_msdos: on a 10G partition: itetcu@it> /home/itetcu [16:23:40] 0 # newfs_msdos -F32 -b32768 /dev/ad2s2 /dev/ad2s2: 20959616 sectors in 327494 FAT32 clusters (32768 bytes/cluster) bps=512 spc=64 res=32 nft=2 mid=0xf0 spt=63 hds=16 hid=0 bsec=20964825 bspf=2559 rdcl=2 infs=1 bkbs=2 itetcu@it> /home/itetcu [16:24:51] 0 # itetcu@it> /home/itetcu [16:28:56] 1 # newfs_msdos -F32 -b65536 /dev/ad2s2 /dev/ad2s2: 20962176 sectors in 163767 FAT32 clusters (65536 bytes/cluster) bps=512 spc=128 res=32 nft=2 mid=0xf0 spt=63 hds=16 hid=0 bsec=20964825 bspf=1280 rdcl=2 infs=1 bkbs=2 itetcu@it> /home/itetcu [16:29:23] 0 # Newfs_msdos on a 30G partition: itetcu@it> /home/itetcu [16:31:40] 1 # newfs_msdos -F32 -b65536 /dev/ad2s1 /dev/ad2s1: 167746176 sectors in 1310517 FAT32 clusters (65536 bytes/cluster) bps=512 spc=128 res=32 nft=2 mid=0xf0 spt=63 hds=16 hid=0 bsec=167766732 bspf=10239 rdcl=2 infs=1 bkbs=2 itetcu@it> /home/itetcu [16:34:48] 0 # The same with 4K clusters takes about 50 minutes ! -- IOnut Unregistered ;) FreeBSD user From owner-freebsd-fs@FreeBSD.ORG Sat Feb 7 14:37:56 2004 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E583916A54D for ; Sat, 7 Feb 2004 14:37:51 -0800 (PST) Received: from mailout2.pacific.net.au (mailout2.pacific.net.au [61.8.0.85]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3627643E82 for ; Sat, 7 Feb 2004 14:19:15 -0800 (PST) (envelope-from bde@zeta.org.au) Received: from mailproxy1.pacific.net.au (mailproxy1.pacific.net.au [61.8.0.86])i17MJ85O013839; Sun, 8 Feb 2004 09:19:08 +1100 Received: from gamplex.bde.org (katana.zip.com.au [61.8.7.246]) i17MJ5t4016116; Sun, 8 Feb 2004 09:19:06 +1100 Date: Sun, 8 Feb 2004 09:19:04 +1100 (EST) From: Bruce Evans X-X-Sender: bde@gamplex.bde.org To: Ion-Mihai Tetcu In-Reply-To: <20040207155819.186335d4@it.buh.cameradicommercio.ro> Message-ID: <20040208084754.O725@gamplex.bde.org> References: <20040207155819.186335d4@it.buh.cameradicommercio.ro> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: freebsd-fs@freebsd.org Subject: Re: Painful speed for copying to fat32 partitions with small cluster size. X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Feb 2004 22:37:56 -0000 On Sat, 7 Feb 2004, Ion-Mihai Tetcu wrote: > Does anyone know why this happens or what to do ? > > Setup: UDMA133 primary master, UFS2; UDMA100 secondary master, FAT32. > > Copying to FAT32 partitions is very slow with small cluster sizes (I was > copying some 300 - 700MB files): > > FAT32 clustersize=4K 500KB/s > FAT32 clustersize=32K 3.5MB/s > FAT32 clustersize=64K 6.2MB/s > FAT32 clustersize=128K 6.4MB/s > FAT16 6.5MB/s > > Reading speed is the same. Lots of things are suboptimal, including your disk apparently not liking small writes (or reads?). Try this patch: %%% Index: msdosfs_vnops.c =================================================================== RCS file: /home/ncvs/src/sys/fs/msdosfs/msdosfs_vnops.c,v retrieving revision 1.147 diff -u -2 -r1.147 msdosfs_vnops.c --- msdosfs_vnops.c 4 Feb 2004 21:52:53 -0000 1.147 +++ msdosfs_vnops.c 5 Feb 2004 08:11:38 -0000 @@ -771,5 +791,9 @@ (void) bwrite(bp); else if (n + croffset == pmp->pm_bpcluster) +#if 0 bawrite(bp); +#else + bdwrite(bp); +#endif else bdwrite(bp); %%% With it, I get 3+ MB/sec from iozone with a write size of 4K to a file system with a cluster size of 4K on an old 6.3GB drive with 9MB/sec max transfer speed, and writing 512-blocks is not much slower. Without it, writing 4K blocks goes fast enough but writing 2K blocks is 10 times slower. It won't help reads. See ffs_write() for a more complete version of this. ffs_write() normally uses cluster_write() for the full-block case where the original version of the above uses foot-shooting; both ffs_write() and msdosfs_write() use bdwrite() for partial blocks and ffs_write() also sets B_CLUSTEROK for this and most other cases. As fair as I understand, bdwrite() with B_CLUSTEROK is just as good as, if not better than cluster_write() (the former gives a delayed clustered write and the latter gives an immediate clustered write if the cluster is full and is no different otherwise; the advantage of cluster_write() is that it gives a better hint to vfs_bio that the write should be done soon). > Newfs_msdos on a 30G partition: > > itetcu@it> /home/itetcu [16:31:40] 1 > # newfs_msdos -F32 -b65536 /dev/ad2s1 > /dev/ad2s1: 167746176 sectors in 1310517 FAT32 clusters (65536 bytes/cluster) > bps=512 spc=128 res=32 nft=2 mid=0xf0 spt=63 hds=16 hid=0 bsec=167766732 bspf=10239 rdcl=2 infs=1 bkbs=2 > itetcu@it> /home/itetcu [16:34:48] 0 > # > > The same with 4K clusters takes about 50 minutes ! Your disk apparently doesn't like writing 4K-blocks and mine apparently doesn't like writing 2K-blocks. Write caching probably helps a lot here. My old drive doesn't have it. Read ahead on the disk certainly helps for reads with too-small block sizes. Bruce From owner-freebsd-fs@FreeBSD.ORG Sat Feb 7 15:10:25 2004 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6992516A4CF for ; Sat, 7 Feb 2004 15:10:25 -0800 (PST) Received: from rdsnet.ro (smtp.rdsnet.ro [62.231.74.130]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9D4E443D1F for ; Sat, 7 Feb 2004 15:10:24 -0800 (PST) (envelope-from itetcu@apropo.ro) Received: (qmail 28062 invoked from network); 7 Feb 2004 23:10:23 -0000 Received: from unknown (HELO it.buh.cameradicommercio.ro) (81.196.25.19) by mail.rdsnet.ro with SMTP; 7 Feb 2004 23:10:23 -0000 Date: Sun, 8 Feb 2004 01:12:16 +0200 From: Ion-Mihai Tetcu To: Bruce Evans Message-Id: <20040208011216.4c062e97@it.buh.cameradicommercio.ro> In-Reply-To: <20040208084754.O725@gamplex.bde.org> References: <20040207155819.186335d4@it.buh.cameradicommercio.ro> <20040208084754.O725@gamplex.bde.org> X-Mailer: Sylpheed version 0.9.8claws (GTK+ 1.2.10; i386-portbld-freebsd5.2) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit cc: freebsd-fs@freebsd.org Subject: Re: Painful speed for copying to fat32 partitions with small cluster size. X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Feb 2004 23:10:25 -0000 On Sun, 8 Feb 2004 09:19:04 +1100 (EST) Bruce Evans wrote: > On Sat, 7 Feb 2004, Ion-Mihai Tetcu wrote: > > > Does anyone know why this happens or what to do ? > > > > Setup: UDMA133 primary master, UFS2; UDMA100 secondary master, FAT32. > > > > Copying to FAT32 partitions is very slow with small cluster sizes (I was > > copying some 300 - 700MB files): > > > > FAT32 clustersize=4K 500KB/s > > FAT32 clustersize=32K 3.5MB/s > > FAT32 clustersize=64K 6.2MB/s > > FAT32 clustersize=128K 6.4MB/s > > FAT16 6.5MB/s > > > > Reading speed is the same. > > Lots of things are suboptimal, including your disk apparently not liking > small writes (or reads?). I don't think reads are the problem; I cannot say for sure, since I haven't done real testing, but I'll try. When I've said 'Reading speed is the same.' I meant that I get the same reading speed no mater the cluster size. For reference: Primary master (copying from) is: ATA-7 disk at ata0-master 117246MB (240121728 sectors), 238216 C, 16 H, 63 S, 512 B 16 secs/int, 1 depth queue, UDMA133 and secondary slave (copying to) is: ATA-6 disk at ata1-master 152626MB (312579695 sectors), 310098 C, 16 H, 63 S, 512 B 16 secs/int, 1 depth queue, UDMA100 the controller is: VIA 8237 chip > Try this patch: Thank you, I'll try it in about a week or so, since I don't have the disk in anymore. > %%% > Index: msdosfs_vnops.c > =================================================================== > RCS file: /home/ncvs/src/sys/fs/msdosfs/msdosfs_vnops.c,v > retrieving revision 1.147 > diff -u -2 -r1.147 msdosfs_vnops.c > --- msdosfs_vnops.c 4 Feb 2004 21:52:53 -0000 1.147 > +++ msdosfs_vnops.c 5 Feb 2004 08:11:38 -0000 > @@ -771,5 +791,9 @@ > (void) bwrite(bp); > else if (n + croffset == pmp->pm_bpcluster) > +#if 0 > bawrite(bp); > +#else > + bdwrite(bp); > +#endif > else > bdwrite(bp); > %%% > > With it, I get 3+ MB/sec from iozone with a write size of 4K to a file > system with a cluster size of 4K on an old 6.3GB drive with 9MB/sec max > transfer speed, and writing 512-blocks is not much slower. Without it, > writing 4K blocks goes fast enough but writing 2K blocks is 10 times > slower. > > It won't help reads. Reading seems ok, from both disks. > See ffs_write() for a more complete version of this. ffs_write() > normally uses cluster_write() for the full-block case where the original > version of the above uses foot-shooting; both ffs_write() and > msdosfs_write() use bdwrite() for partial blocks and ffs_write() also > sets B_CLUSTEROK for this and most other cases. As fair as I understand, > bdwrite() with B_CLUSTEROK is just as good as, if not better than > cluster_write() (the former gives a delayed clustered write and the > latter gives an immediate clustered write if the cluster is full and > is no different otherwise; the advantage of cluster_write() is that it > gives a better hint to vfs_bio that the write should be done soon). > > > Newfs_msdos on a 30G partition: > > > > itetcu@it> /home/itetcu [16:31:40] 1 > > # newfs_msdos -F32 -b65536 /dev/ad2s1 > > /dev/ad2s1: 167746176 sectors in 1310517 FAT32 clusters (65536 bytes/cluster) > > bps=512 spc=128 res=32 nft=2 mid=0xf0 spt=63 hds=16 hid=0 bsec=167766732 bspf=10239 rdcl=2 infs=1 bkbs=2 > > itetcu@it> /home/itetcu [16:34:48] 0 > > # > > > > The same with 4K clusters takes about 50 minutes ! > > Your disk apparently doesn't like writing 4K-blocks and mine apparently > doesn't like writing 2K-blocks. Write caching probably helps a lot here. True, hw.ata.wc=0. BTW, with this setting atacotrol says: Feature Support Enable Value Vendor write cache yes yes read ahead yes yes which confuses me. -- IOnut Unregistered ;) FreeBSD user