From owner-freebsd-fs Mon Aug 19 10:59:36 2002 Delivered-To: freebsd-fs@hub.freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id CD7C137B400; Mon, 19 Aug 2002 10:59:33 -0700 (PDT) Received: from freefall.freebsd.org (freefall.FreeBSD.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7EF3B43E4A; Mon, 19 Aug 2002 10:59:33 -0700 (PDT) (envelope-from johan@FreeBSD.org) Received: from freefall.freebsd.org (johan@localhost [127.0.0.1]) by freefall.freebsd.org (8.12.4/8.12.4) with ESMTP id g7JHxXJU007775; Mon, 19 Aug 2002 10:59:33 -0700 (PDT) (envelope-from johan@freefall.freebsd.org) Received: (from johan@localhost) by freefall.freebsd.org (8.12.4/8.12.4/Submit) id g7JHxXce007771; Mon, 19 Aug 2002 10:59:33 -0700 (PDT) Date: Mon, 19 Aug 2002 10:59:33 -0700 (PDT) From: Johan Karlsson Message-Id: <200208191759.g7JHxXce007771@freefall.freebsd.org> To: johan@FreeBSD.org, freebsd-bugs@FreeBSD.org, freebsd-fs@FreeBSD.org Subject: Re: kern/21807: [patches] Make System attribute correspond to SF_IMMUTABLE Sender: owner-freebsd-fs@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Synopsis: [patches] Make System attribute correspond to SF_IMMUTABLE Responsible-Changed-From-To: freebsd-bugs->freebsd-fs Responsible-Changed-By: johan Responsible-Changed-When: Mon Aug 19 10:55:04 PDT 2002 Responsible-Changed-Why: Lets see what -fs think about this proposal. http://www.freebsd.org/cgi/query-pr.cgi?pr=21807 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-fs" in the body of the message From owner-freebsd-fs Tue Aug 20 22: 2:50 2002 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 0151837B400 for ; Tue, 20 Aug 2002 22:02:43 -0700 (PDT) Received: from ns.gechosting.com (ns.gechosting.com [203.155.241.29]) by mx1.FreeBSD.org (Postfix) with SMTP id 4834343E6E for ; Tue, 20 Aug 2002 22:02:41 -0700 (PDT) (envelope-from tas@thdiy.com) Received: (qmail 28396 invoked from network); 21 Aug 2002 05:02:33 -0000 Received: from 202.59.255.60.idn.co.th (HELO hydra.home.thdiy.com) (202.59.255.60) by ns.gechosting.com with SMTP; 21 Aug 2002 05:02:33 -0000 From: Tasanakorn Phaipool To: ache@freebsd.org Subject: Thai convertion table for /sbin/mount_msdos(fs) Date: Wed, 21 Aug 2002 12:02:32 +0700 X-Mailer: KMail [version 1.4] Cc: freebsd-i18n@freebsd.org, freebsd-fs@freebsd.org MIME-Version: 1.0 Content-Type: Multipart/Mixed; boundary="------------Boundary-00=_8OG6N4I40I1VTG43QFK6" Message-Id: <200208211202.32685.tas@thdiy.com> Sender: owner-freebsd-fs@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org --------------Boundary-00=_8OG6N4I40I1VTG43QFK6 Content-Type: text/plain; charset="tis-620" Content-Transfer-Encoding: quoted-printable Please review. TIS-620 : Thai Industial Standard. MS874/CP874 : Microsoft/IBM. For more information Thai Support in GNU/Linux http://linux.thai.net/thep/ Basic Concept of Thai Language http://www.fedu.uec.ac.jp/ZzzThai/thailang/ Thai Unicode http://www.unicode.org/charts/PDF/U0E00.pdf If you want more information please let me know.=20 --------------Boundary-00=_8OG6N4I40I1VTG43QFK6 Content-Type: text/plain; charset="tis-620"; name="tis2dos" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="tis2dos" # # # u2w: 16 rows of TIS620 -> Unicode conversion table (upper half) # 0x003f 0x003f 0x003f 0x003f 0x003f 0x003f 0x003f 0x003f 0x003f 0x003f 0x003f 0x003f 0x003f 0x003f 0x003f 0x003f 0x003f 0x003f 0x003f 0x003f 0x003f 0x003f 0x003f 0x003f 0x003f 0x003f 0x003f 0x003f 0x003f 0x003f 0x003f 0x003f 0x003f 0x0e01 0x0e02 0x0e03 0x0e04 0x0e05 0x0e06 0x0e07 0x0e08 0x0e09 0x0e0A 0x0e0b 0x0e0c 0x0e0d 0x0e0e 0x0e0f 0x0e10 0x0e11 0x0e12 0x0e13 0x0e14 0x0e15 0x0e16 0x0e17 0x0e18 0x0e19 0x0e1A 0x0e1b 0x0e1c 0x0e1d 0x0e1e 0x0e1f 0x0e20 0x0e21 0x0e22 0x0e23 0x0e24 0x0e25 0x0e26 0x0e27 0x0e28 0x0e29 0x0e2A 0x0e2b 0x0e2c 0x0e2d 0x0e2e 0x0e2f 0x0e30 0x0e31 0x0e32 0x0e33 0x0e34 0x0e35 0x0e36 0x0e37 0x0e38 0x0e39 0x0e3A 0x003f 0x003f 0x003f 0x003f 0x0e3f 0x0e40 0x0e41 0x0e42 0x0e43 0x0e44 0x0e45 0x0e46 0x0e47 0x0e48 0x0e49 0x0e4A 0x0e4b 0x0e4c 0x0e4d 0x0e4e 0x0e4f 0x0e50 0x0e51 0x0e52 0x0e53 0x0e54 0x0e55 0x0e56 0x0ee7 0x0e58 0x0e59 0x0e5A 0x0e5b 0x003f 0x003f 0x003f 0x003f # # d2u: 16 rows of CP874 -> TIS620 conversion table (upper half) # 0x3f 0x3f 0x3f 0x3f 0x3f 0x3f 0x3f 0x3f 0x3f 0x3f 0x3f 0x3f 0x3f 0x3f 0x3f 0x3f 0x3f 0x3f 0x3f 0x3f 0x3f 0x3f 0x3f 0x3f 0x3f 0x3f 0x3f 0x3f 0x3f 0x3f 0x3f 0x3f 0x3f 0xa1 0xa2 0xa3 0xa4 0xa5 0xa6 0xa7 0xa8 0xa9 0xaa 0xab 0xac 0xad 0xae 0xaf 0xb0 0xb1 0xb2 0xb3 0xb4 0xb5 0xb6 0xb7 0xb8 0xb9 0xba 0xbb 0xbc 0xbd 0xbe 0xbf 0xc0 0xc1 0xc2 0xc3 0xc4 0xc5 0xc6 0xc7 0xc8 0xc9 0xca 0xcb 0xcc 0xcd 0xce 0xcf 0xd0 0xd1 0xd2 0xd3 0xd4 0xd5 0xd6 0xd7 0xd8 0xd9 0xda 0x3f 0x3f 0x3f 0x3f 0xdf 0xe0 0xe1 0xe2 0xe3 0xe4 0xe5 0xe6 0xe7 0xe8 0xe9 0xea 0xeb 0xec 0xed 0xee 0xef 0xf0 0xf1 0xf2 0xf3 0xf4 0xf5 0xf6 0xf7 0xf8 0xf9 0xfa 0xfb 0x3f 0x3f 0x3f 0x3f # # u2d: 16 rows of TIS620 -> CP874 conversion table (upper half) # 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0xa1 0xa2 0xa3 0xa4 0xa5 0xa6 0xa7 0xa8 0xa9 0xaa 0xab 0xac 0xad 0xae 0xaf 0xb0 0xb1 0xb2 0xb3 0xb4 0xb5 0xb6 0xb7 0xb8 0xb9 0xba 0xbb 0xbc 0xbd 0xbe 0xbf 0xc0 0xc1 0xc2 0xc3 0xc4 0xc5 0xc6 0xc7 0xc8 0xc9 0xca 0xcb 0xcc 0xcd 0xce 0xcf 0xd0 0xd1 0xd2 0xd3 0xd4 0xd5 0xd6 0xd7 0xd8 0xd9 0xda 0x00 0x00 0x00 0x00 0xdf 0xe0 0xe1 0xe2 0xe3 0xe4 0xe5 0xe6 0xe7 0xe8 0xe9 0xea 0xeb 0xec 0xed 0xee 0xef 0xf0 0xf1 0xf2 0xf3 0xf4 0xf5 0xf6 0xf7 0xf8 0xf9 0xfa 0xfb 0x00 0x00 0x00 0x00 --------------Boundary-00=_8OG6N4I40I1VTG43QFK6-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-fs" in the body of the message From owner-freebsd-fs Thu Aug 22 16:14:36 2002 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 649BF37B401 for ; Thu, 22 Aug 2002 16:14:34 -0700 (PDT) Received: from mail.allcaps.org (h-66-166-142-198.SNDACAGL.covad.net [66.166.142.198]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1285E43E4A for ; Thu, 22 Aug 2002 16:14:34 -0700 (PDT) (envelope-from bsder@mail.allcaps.org) Received: by mail.allcaps.org (Postfix, from userid 501) id C30A4153C6; Thu, 22 Aug 2002 16:14:32 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.allcaps.org (Postfix) with ESMTP id B7400153C2 for ; Thu, 22 Aug 2002 16:14:32 -0700 (PDT) Date: Thu, 22 Aug 2002 16:14:32 -0700 (PDT) From: "Andrew P. Lentvorski" To: freebsd-fs@freebsd.org Subject: Status of RAIDFrame for FreeBSD? Message-ID: <20020822161233.P36851-100000@mail.allcaps.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-fs@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org What is the status of RAIDFrame for FreeBSD? The latest patch is dated almost a year old. Thanks, -a To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-fs" in the body of the message From owner-freebsd-fs Thu Aug 22 17:19:46 2002 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 A086937B400 for ; Thu, 22 Aug 2002 17:19:44 -0700 (PDT) Received: from magic.adaptec.com (magic.adaptec.com [208.236.45.80]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1D95743E97 for ; Thu, 22 Aug 2002 17:19:44 -0700 (PDT) (envelope-from Scott_Long@adaptec.com) Received: from redfish.adaptec.com (redfish.adaptec.com [162.62.50.11]) by magic.adaptec.com (8.10.2+Sun/8.10.2) with ESMTP id g7MNnFG04824; Thu, 22 Aug 2002 16:49:15 -0700 (PDT) Received: from btc.btc.adaptec.com (btc.btc.adaptec.com [10.100.0.52]) by redfish.adaptec.com (8.8.8+Sun/8.8.8) with ESMTP id QAA00654; Thu, 22 Aug 2002 16:49:15 -0700 (PDT) Received: from btcexc01.btc.adaptec.com (btcexc01 [10.100.0.23]) by btc.btc.adaptec.com (8.8.8+Sun/8.8.8) with ESMTP id RAA26711; Thu, 22 Aug 2002 17:49:12 -0600 (MDT) Received: by btcexc01.btc.adaptec.com with Internet Mail Service (5.5.2653.19) id ; Thu, 22 Aug 2002 17:49:13 -0600 Message-ID: <2C7CBDC6EA58D6119E4A00065B3A24CB0464C3@btcexc01.btc.adaptec.com> From: "Long, Scott" To: "'Andrew P. Lentvorski'" , freebsd-fs@freebsd.org Subject: RE: Status of RAIDFrame for FreeBSD? Date: Thu, 22 Aug 2002 17:49:13 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Sender: owner-freebsd-fs@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Those patches will work with 4.6.x. I've been struggling over the past year to make it work in 5-current. RAIDframe was not built with SMPng in mind, and as such it does evil things like hold locks for too long and abuse the kernel stack. I'm slowly working my way through it, but occasionally real life intrudes. Email me privately if you are interested in helping. Scott > -----Original Message----- > From: Andrew P. Lentvorski [mailto:bsder@mail.allcaps.org] > Sent: Thursday, August 22, 2002 5:15 PM > To: freebsd-fs@freebsd.org > Subject: Status of RAIDFrame for FreeBSD? > > > What is the status of RAIDFrame for FreeBSD? The latest > patch is dated > almost a year old. > > Thanks, > -a > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-fs" in the body of the message > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-fs" in the body of the message From owner-freebsd-fs Thu Aug 22 17:20:52 2002 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 3507837B400 for ; Thu, 22 Aug 2002 17:20:49 -0700 (PDT) Received: from magic.adaptec.com (magic.adaptec.com [208.236.45.80]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9A40743E84 for ; Thu, 22 Aug 2002 17:20:48 -0700 (PDT) (envelope-from scottl@btc.adaptec.com) Received: from redfish.adaptec.com (redfish.adaptec.com [162.62.50.11]) by magic.adaptec.com (8.10.2+Sun/8.10.2) with ESMTP id g7N0KkG09074; Thu, 22 Aug 2002 17:20:46 -0700 (PDT) Received: from btc.btc.adaptec.com (btc.btc.adaptec.com [10.100.0.52]) by redfish.adaptec.com (8.8.8+Sun/8.8.8) with ESMTP id RAA05104; Thu, 22 Aug 2002 17:20:46 -0700 (PDT) Received: from hollin.btc.adaptec.com (hollin [10.100.253.56]) by btc.btc.adaptec.com (8.8.8+Sun/8.8.8) with ESMTP id SAA26859; Thu, 22 Aug 2002 18:20:43 -0600 (MDT) Received: from hollin.btc.adaptec.com (localhost [127.0.0.1]) by hollin.btc.adaptec.com (8.12.5/8.12.5) with ESMTP id g7N0GhjF026122; Thu, 22 Aug 2002 18:16:43 -0600 (MDT) (envelope-from scottl@hollin.btc.adaptec.com) Received: (from scottl@localhost) by hollin.btc.adaptec.com (8.12.5/8.12.5/Submit) id g7N0Ggg8026121; Thu, 22 Aug 2002 18:16:42 -0600 (MDT) Received: by btcexc01.btc.adaptec.com id <01C24A36.8487FFF0@btcexc01.btc.adaptec.com>; Thu, 22 Aug 2002 17:49:13 -0600 Message-ID: <2C7CBDC6EA58D6119E4A00065B3A24CB0464C3@btcexc01.btc.adaptec.com> From: "Long, Scott" To: "'Andrew P. Lentvorski'" , freebsd-fs@freebsd.org Subject: RE: Status of RAIDFrame for FreeBSD? Date: Thu, 22 Aug 2002 17:49:13 -0600 MIME-Version: 1.0 Content-Type: text/plain Sender: owner-freebsd-fs@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Those patches will work with 4.6.x. I've been struggling over the past year to make it work in 5-current. RAIDframe was not built with SMPng in mind, and as such it does evil things like hold locks for too long and abuse the kernel stack. I'm slowly working my way through it, but occasionally real life intrudes. Email me privately if you are interested in helping. Scott > -----Original Message----- > From: Andrew P. Lentvorski [mailto:bsder@mail.allcaps.org] > Sent: Thursday, August 22, 2002 5:15 PM > To: freebsd-fs@freebsd.org > Subject: Status of RAIDFrame for FreeBSD? > > > What is the status of RAIDFrame for FreeBSD? The latest > patch is dated > almost a year old. > > Thanks, > -a > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-fs" in the body of the message > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-fs" in the body of the message From owner-freebsd-fs Thu Aug 22 20:28:41 2002 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 4C3A337B400 for ; Thu, 22 Aug 2002 20:28:40 -0700 (PDT) Received: from cs.rpi.edu (mumble.cs.rpi.edu [128.213.8.16]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9101943E4A for ; Thu, 22 Aug 2002 20:28:39 -0700 (PDT) (envelope-from guptar@cs.rpi.edu) Received: from jenolen.cs.rpi.edu (jenolen.cs.rpi.edu [128.213.12.42]) by cs.rpi.edu (8.9.3/8.9.3) with ESMTP id XAA22501; Thu, 22 Aug 2002 23:28:37 -0400 (EDT) Received: from localhost (guptar@localhost) by jenolen.cs.rpi.edu (8.11.6+Sun/8.9.3) with ESMTP id g7N3SbN09085; Thu, 22 Aug 2002 23:28:37 -0400 (EDT) X-Authentication-Warning: jenolen.cs.rpi.edu: guptar owned process doing -bs Date: Thu, 22 Aug 2002 23:28:37 -0400 (EDT) From: Rashim Gupta To: Cc: "David E. Cross" Subject: Block free question Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-fs@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Hi As you all know we are working on logging the FS metadata. We are stuck while we are trying to free a block . When we free a block, we need to write this block number into the log file. We are storing the handle to the journal file in the ufsmount structure, how do we get access to that in ffs_blkfree? We have available to us "struct fs *fs", but there doesn't seem to be a way to get back to the ufsmount from there. We also have struct vnode *devvp, but that points to the /dev/foo entry (devfs), so its not usefull. The last bits of information we have are the block-number and inode-number, which I don't see an easy O(reasonable) way to extract the ufsmount information. As a status update we have the following metadata operations mostly done: inodealloc, link, unlink, blockalloc. Rashim Gupta To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-fs" in the body of the message From owner-freebsd-fs Thu Aug 22 20:36: 1 2002 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 1D49637B400 for ; Thu, 22 Aug 2002 20:35:59 -0700 (PDT) Received: from elvis.mu.org (elvis.mu.org [192.203.228.196]) by mx1.FreeBSD.org (Postfix) with ESMTP id D771C43E6A for ; Thu, 22 Aug 2002 20:35:58 -0700 (PDT) (envelope-from bright@elvis.mu.org) Received: by elvis.mu.org (Postfix, from userid 1192) id B1809AE22C; Thu, 22 Aug 2002 20:35:58 -0700 (PDT) Date: Thu, 22 Aug 2002 20:35:58 -0700 From: Alfred Perlstein To: Rashim Gupta Cc: fs@freebsd.org, "David E. Cross" Subject: Re: Block free question Message-ID: <20020823033558.GY75574@elvis.mu.org> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.3.27i Sender: owner-freebsd-fs@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org * Rashim Gupta [020822 20:28] wrote: > > Hi > As you all know we are working on logging the FS metadata. We are stuck > while we are trying to free a block . When we free a block, we need to > write this block number into the log file. We are storing the handle to > the journal file in the ufsmount structure, how do we get access to that > in ffs_blkfree? We have available to us "struct fs *fs", but there > doesn't seem to be a way to get back to the ufsmount from there. We also > have struct vnode *devvp, but that points to the /dev/foo entry (devfs), > so its not usefull. The last bits of information we have are the > block-number and inode-number, which I don't see an easy O(reasonable) way > to extract the ufsmount information. > > As a status update we have the following metadata operations mostly done: > inodealloc, link, unlink, blockalloc. here's one way: you can look at devvp->v_rdev->si_mountpoint for 'struct mount', you can use VFS_VGET on the mount along with the inode number to get the vnode, the vnode can also give you the info you require. -- -Alfred Perlstein [alfred@freebsd.org] [#bsdcode/efnet/irc.prison.net] 'Instead of asking why a piece of software is using "1970s technology," start asking why software is ignoring 30 years of accumulated wisdom.' To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-fs" in the body of the message From owner-freebsd-fs Thu Aug 22 21:20:39 2002 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 A458A37B400 for ; Thu, 22 Aug 2002 21:20:35 -0700 (PDT) Received: from cs.rpi.edu (mumble.cs.rpi.edu [128.213.8.16]) by mx1.FreeBSD.org (Postfix) with ESMTP id C8FD043E65 for ; Thu, 22 Aug 2002 21:20:34 -0700 (PDT) (envelope-from guptar@cs.rpi.edu) Received: from jenolen.cs.rpi.edu (jenolen.cs.rpi.edu [128.213.12.42]) by cs.rpi.edu (8.9.3/8.9.3) with ESMTP id AAA23778; Fri, 23 Aug 2002 00:20:32 -0400 (EDT) Received: from localhost (guptar@localhost) by jenolen.cs.rpi.edu (8.11.6+Sun/8.9.3) with ESMTP id g7N4KV309118; Fri, 23 Aug 2002 00:20:31 -0400 (EDT) X-Authentication-Warning: jenolen.cs.rpi.edu: guptar owned process doing -bs Date: Fri, 23 Aug 2002 00:20:31 -0400 (EDT) From: Rashim Gupta To: Alfred Perlstein Cc: , "David E. Cross" Subject: Re: Block free question In-Reply-To: <20020823033558.GY75574@elvis.mu.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-fs@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Hi Alfred Thanks for the response. I tried the following piece of code based on your suggestions: VFS_VGET(ba->devvp->v_rdev->si_mountpoint, ba->inum, 0, &myvnode); Here, ba is a structure which contains the inode number, the devvp pointer, and the block number. But on compiling this, I get the follwoing error: "dereferencing pointer to incomplete type". Any suggestions how I proceed from here. Thanks in advance Rashim On Thu, 22 Aug 2002, Alfred Perlstein wrote: > * Rashim Gupta [020822 20:28] wrote: > > > > Hi > > As you all know we are working on logging the FS metadata. We are stuck > > while we are trying to free a block . When we free a block, we need to > > write this block number into the log file. We are storing the handle to > > the journal file in the ufsmount structure, how do we get access to that > > in ffs_blkfree? We have available to us "struct fs *fs", but there > > doesn't seem to be a way to get back to the ufsmount from there. We also > > have struct vnode *devvp, but that points to the /dev/foo entry (devfs), > > so its not usefull. The last bits of information we have are the > > block-number and inode-number, which I don't see an easy O(reasonable) way > > to extract the ufsmount information. > > > > As a status update we have the following metadata operations mostly done: > > inodealloc, link, unlink, blockalloc. > > here's one way: > > you can look at devvp->v_rdev->si_mountpoint for 'struct mount', > you can use VFS_VGET on the mount along with the inode number to > get the vnode, the vnode can also give you the info you require. > > -- > -Alfred Perlstein [alfred@freebsd.org] [#bsdcode/efnet/irc.prison.net] > 'Instead of asking why a piece of software is using "1970s technology," > start asking why software is ignoring 30 years of accumulated wisdom.' To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-fs" in the body of the message From owner-freebsd-fs Fri Aug 23 14:26:51 2002 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 DB8E837B400; Fri, 23 Aug 2002 14:26:42 -0700 (PDT) Received: from mailsrv.otenet.gr (mailsrv.otenet.gr [195.170.0.5]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0C0FD43E7B; Fri, 23 Aug 2002 14:26:42 -0700 (PDT) (envelope-from keramida@FreeBSD.org) Received: from hades.hell.gr (patr530-a021.otenet.gr [212.205.215.21]) by mailsrv.otenet.gr (8.12.4/8.12.4) with ESMTP id g7NLQbpD025428; Sat, 24 Aug 2002 00:26:38 +0300 (EEST) Received: from hades.hell.gr (hades [127.0.0.1]) by hades.hell.gr (8.12.5/8.12.5) with ESMTP id g7NLQZDq066141; Sat, 24 Aug 2002 00:26:35 +0300 (EEST) (envelope-from keramida@FreeBSD.org) Received: (from charon@localhost) by hades.hell.gr (8.12.5/8.12.5/Submit) id g7NLQXDX066140; Sat, 24 Aug 2002 00:26:33 +0300 (EEST) (envelope-from keramida@FreeBSD.org) Date: Sat, 24 Aug 2002 00:26:32 +0300 From: Giorgos Keramidas To: Chris Ptacek Cc: Carlos Carnero , freebsd-questions@FreeBSD.org, freebsd-fs@FreeBSD.org Subject: Re: optimization changed from TIME to SPACE ?! Message-ID: <20020823212631.GA64644@hades.hell.gr> References: <31269226357BD211979E00A0C9866DAB02BB9988@rios.sitaranetworks.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <31269226357BD211979E00A0C9866DAB02BB9988@rios.sitaranetworks.com> X-PGP-Fingerprint: C1EB 0653 DB8B A557 3829 00F9 D60F 941A 3186 03B6 X-Phone: +30-944-116520 Sender: owner-freebsd-fs@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org The following postings describe the problems Carlos Carnero is having with Squid causing space optimizations to be always turned on, without his /var filesystem being too full. Those of you who are confident about your ffs/ufs understanding correct me if I'm wrong in my comments below, but I think I've found why this happens. Any suggestions to avoid excessive fragmentation and avoid triggering this? After reading what happens, I'd be indebted if you helped a bit :) - Giorgos On 2002-08-23 09:48 +0000, Carlos Carnero wrote: > > Your /var filesystem is almost 100% full. > > I thought so the moment I saw the message, but for > several months now I monitor that box using SNMP and > that partition is *always* kept very loose space-wise. On 2002-08-23 13:43 +0000, Chris Ptacek wrote: > Actually I have been trying to figure out this myself for a while. > I am having the same issues (squid cache), TIME to SPACE changes > with the partition at 50-70% used. I think I've found it :))) [[ A little kernel background. ]] That's an interesting observation. You are indeed correct. The code of /usr/src/sys/ufs/ffs/ffs_alloc.c is the one that controls when SPACE or TIME optimization kicks in. The default optimization is TIME to make operations as fast as possible, with the added disadvantage that some times blocks or fragments will be allocated in positions that are in "good" positions, thus wasting space. The following parts of the ffs_alloc.c source show this: 287 if (fs->fs_minfree <= 5 || 288 fs->fs_cstotal.cs_nffree > 289 (off_t)fs->fs_dsize * fs->fs_minfree / (2 * 100)) 290 break; 291 log(LOG_NOTICE, "%s: optimization changed from SPACE to TIME\n", 292 fs->fs_fsmnt); 293 fs->fs_optim = FS_OPTTIME; 294 break; If the fs_minfree percentage of minimum free blocks is less than 5% then the optimization is NEVER set to FS_OPTTIME to enable fast operation. Running a filesystem with less than 5% of free space will keep everything a bit slower. The next part checks to ensure that the total number of fragments in all cylinder groups doesn't exceed in size 50% of the free reserve. THIS is where the problems you're seeing lies. In a relatively empty disk with a free reserve of 5%, with many thousands small files (typical of Squid caches), it's easy to have many thousands of small fragments. In that case, when the total disk space allocated to fragments exceeds 50% of the 5% (which is a relatively small amount of space, regardless of the total disk size), SPACE optimization won't be turned off. Similar things can be seen where TIME optimization is set to SPACE, further down in ffs_alloc.c. Only in this case, SPACE optimization kicks in faster than before. When the space occupied by fragments grows reaches 80% of the space allocated to the free reserve it is considered excess fragmentation and SPACE optimizations kick in. 307 if (fs->fs_cstotal.cs_nffree < 308 (off_t)fs->fs_dsize * (fs->fs_minfree - 2) / 100) 309 break; 310 log(LOG_NOTICE, "%s: optimization changed from TIME to SPACE\n", 311 fs->fs_fsmnt); 312 fs->fs_optim = FS_OPTSPACE; 313 break; In the code above, fs_cstotal.cs_nffree is the number of free fragments available in all cylinder groups of the filesystem. fs_minfree is the percentage of free space reserved by tunefs(8). (fs_minfree - 2) is the percentage that fragments are allowed to take. If more disk space than that is dedicated to fragments, then the check fails and SPACE optimizations are turned on. > From what I have been able to find this has to do with fragmentation in the > partition and not the disk actually being full. That was a VERY useful hint in finding out why this happens. Now that I have understood that this is an interesting interaction between the free space reserved aside from the total disk space and fragmentation, perhaps we can find some way to solve the problems SPACE optimizations might cause. What techniques would you use to reduce fragmentation? Changes in block/fragment ratio? Changes to the default fragment or block size? Ideas anyone? -- FreeBSD: The Power to Serve <> http://www.FreeBSD.org FreeBSD 5.0-CURRENT #0: Wed Aug 21 22:08:19 EEST 2002 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-fs" in the body of the message From owner-freebsd-fs Fri Aug 23 23: 6: 1 2002 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 66AC737B400; Fri, 23 Aug 2002 23:05:56 -0700 (PDT) Received: from gw.catspoiler.org (217-ip-163.nccn.net [209.79.217.163]) by mx1.FreeBSD.org (Postfix) with ESMTP id D547143E88; Fri, 23 Aug 2002 23:05:52 -0700 (PDT) (envelope-from dl-freebsd@catspoiler.org) Received: from mousie.catspoiler.org (mousie.catspoiler.org [192.168.101.2]) by gw.catspoiler.org (8.12.5/8.12.5) with ESMTP id g7O65awr041961; Fri, 23 Aug 2002 23:05:40 -0700 (PDT) (envelope-from dl-freebsd@catspoiler.org) Message-Id: <200208240605.g7O65awr041961@gw.catspoiler.org> Date: Fri, 23 Aug 2002 23:05:36 -0700 (PDT) From: Don Lewis Subject: Re: optimization changed from TIME to SPACE ?! To: keramida@FreeBSD.ORG Cc: cptacek@sitaranetworks.com, zopewiz@yahoo.com, freebsd-questions@FreeBSD.ORG, freebsd-fs@FreeBSD.ORG In-Reply-To: <20020823212631.GA64644@hades.hell.gr> MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Sender: owner-freebsd-fs@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On 24 Aug, Giorgos Keramidas wrote: > The following postings describe the problems Carlos Carnero is having > with Squid causing space optimizations to be always turned on, without > his /var filesystem being too full. Those of you who are confident > about your ffs/ufs understanding correct me if I'm wrong in my > comments below, but I think I've found why this happens. Any > suggestions to avoid excessive fragmentation and avoid triggering > this? After reading what happens, I'd be indebted if you helped a bit :) I ran into similar problems in the past when I ran a Usenet server. Space optimization is most painful when a file slowly grows over time because the fragments have to be relocated every time they outgrow the available space at their current location. Because Usenet news articles are written in one shot and don't grow, space optimization doesn't cost all that much performance, so I just used tunefs to force the filesystem to always run in space optimization mode. The potential extra seek for the fragments isn't likely to matter much because even the full blocks are unlikely to all be stored sequentially in a well used Usenet spool filesystem that is run anywhere near full. Squid should show similar behaviour, so you might try the same workaround. On the other hand, if you are willing to throw some disk space at the problem to avoid any performance penalty, you could create the filesystem with the fragment size set the same as the block size. I suspect that setting the block and fragment sizes closer together than the default 8:1 ratio would help with the problem without as much cost in terms of wasted space as compared to setting them to the same size. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-fs" in the body of the message From owner-freebsd-fs Sat Aug 24 5: 1:29 2002 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 8252237B405; Sat, 24 Aug 2002 05:01:24 -0700 (PDT) Received: from HAL9000.homeunix.com (12-232-220-15.client.attbi.com [12.232.220.15]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0E5A743E6E; Sat, 24 Aug 2002 05:00:23 -0700 (PDT) (envelope-from dschultz@uclink.Berkeley.EDU) Received: from HAL9000.homeunix.com (localhost [127.0.0.1]) by HAL9000.homeunix.com (8.12.5/8.12.5) with ESMTP id g7OC0hJ7007486; Sat, 24 Aug 2002 05:00:43 -0700 (PDT) (envelope-from dschultz@uclink.Berkeley.EDU) Received: (from das@localhost) by HAL9000.homeunix.com (8.12.5/8.12.5/Submit) id g7OC0cva007485; Sat, 24 Aug 2002 05:00:38 -0700 (PDT) (envelope-from dschultz@uclink.Berkeley.EDU) Date: Sat, 24 Aug 2002 05:00:38 -0700 From: David Schultz To: Giorgos Keramidas Cc: Chris Ptacek , Carlos Carnero , freebsd-questions@FreeBSD.ORG, freebsd-fs@FreeBSD.ORG Subject: Re: optimization changed from TIME to SPACE ?! Message-ID: <20020824120038.GA4994@HAL9000.homeunix.com> Mail-Followup-To: Giorgos Keramidas , Chris Ptacek , Carlos Carnero , freebsd-questions@FreeBSD.ORG, freebsd-fs@FreeBSD.ORG References: <31269226357BD211979E00A0C9866DAB02BB9988@rios.sitaranetworks.com> <20020823212631.GA64644@hades.hell.gr> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20020823212631.GA64644@hades.hell.gr> Sender: owner-freebsd-fs@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Thus spake Giorgos Keramidas : > Now that I have understood that this is an interesting interaction > between the free space reserved aside from the total disk space and > fragmentation, perhaps we can find some way to solve the problems > SPACE optimizations might cause. > > What techniques would you use to reduce fragmentation? Changes in > block/fragment ratio? Changes to the default fragment or block size? > > Ideas anyone? If the filesystem contains many small files, e.g. a squid cache, a smaller block size is probably appropriate. This should reduce the number of fragments necessary without changing the block size / fragment size ratio. With larger blocks, time optimization will waste lots of space if you have lots of small files. In some cases, a smaller block size might be a bad idea even with a small average file size. For example, if two-thirds of the files in the filesystem suddenly required indirect blocks as a result of lowering the block size, you would be shooting yourself in the foot. I believe Softupdates mitigates some of the performance loss associated with fragment copying because fragments can be reallocated to full blocks if necessary before they are ever written to disk. However, someone else should confirm this, since I'm not sure about this point. By the way, you typically don't want to set the free space reserve as low as 5%. It is not merely an administrative limit. When a filesystem is low on space, it is impossible to allocate new data in reasonably good positions on the disk; the limit prevents this situation from occurring. (I believe we discussed this in another thread a few months back.) If you set the reserve below 5%, FFS assumes that you expect disk space to be very tight, so it optimizes for space. As you pointed out, it also does this if space *is* tight, i.e. the disk is within 2% of being full after subtracting off the reserve. I suppose it's debatable whether these policy decisions should be overridable, but most people just give the filesystem enough room to breathe. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-fs" in the body of the message From owner-freebsd-fs Sat Aug 24 19: 4:39 2002 Delivered-To: freebsd-fs@hub.freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id F3DC037B400; Sat, 24 Aug 2002 19:04:37 -0700 (PDT) Received: from freefall.freebsd.org (freefall.FreeBSD.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id A54BD43E4A; Sat, 24 Aug 2002 19:04:37 -0700 (PDT) (envelope-from johan@FreeBSD.org) Received: from freefall.freebsd.org (johan@localhost [127.0.0.1]) by freefall.freebsd.org (8.12.4/8.12.4) with ESMTP id g7P24bJU050396; Sat, 24 Aug 2002 19:04:37 -0700 (PDT) (envelope-from johan@freefall.freebsd.org) Received: (from johan@localhost) by freefall.freebsd.org (8.12.4/8.12.4/Submit) id g7P24bZe050392; Sat, 24 Aug 2002 19:04:37 -0700 (PDT) Date: Sat, 24 Aug 2002 19:04:37 -0700 (PDT) From: Johan Karlsson Message-Id: <200208250204.g7P24bZe050392@freefall.freebsd.org> To: johan@FreeBSD.org, freebsd-fs@FreeBSD.org, fs@FreeBSD.org Subject: Re: kern/21807: [patches] Make System attribute correspond to SF_IMMUTABLE Sender: owner-freebsd-fs@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Synopsis: [patches] Make System attribute correspond to SF_IMMUTABLE Responsible-Changed-From-To: freebsd-fs->fs Responsible-Changed-By: johan Responsible-Changed-When: Sat Aug 24 19:04:07 PDT 2002 Responsible-Changed-Why: Use short names for mailing list to make searches using the web query form work with the shown responsible. This also makes open PR show up in the summery mail. http://www.freebsd.org/cgi/query-pr.cgi?pr=21807 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-fs" in the body of the message From owner-freebsd-fs Sat Aug 24 19: 4:48 2002 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 F3DC037B400; Sat, 24 Aug 2002 19:04:37 -0700 (PDT) Received: from freefall.freebsd.org (freefall.FreeBSD.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id A54BD43E4A; Sat, 24 Aug 2002 19:04:37 -0700 (PDT) (envelope-from johan@FreeBSD.org) Received: from freefall.freebsd.org (johan@localhost [127.0.0.1]) by freefall.freebsd.org (8.12.4/8.12.4) with ESMTP id g7P24bJU050396; Sat, 24 Aug 2002 19:04:37 -0700 (PDT) (envelope-from johan@freefall.freebsd.org) Received: (from johan@localhost) by freefall.freebsd.org (8.12.4/8.12.4/Submit) id g7P24bZe050392; Sat, 24 Aug 2002 19:04:37 -0700 (PDT) Date: Sat, 24 Aug 2002 19:04:37 -0700 (PDT) From: Johan Karlsson Message-Id: <200208250204.g7P24bZe050392@freefall.freebsd.org> To: johan@FreeBSD.org, freebsd-fs@FreeBSD.org, fs@FreeBSD.org Subject: Re: kern/21807: [patches] Make System attribute correspond to SF_IMMUTABLE Sender: owner-freebsd-fs@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Synopsis: [patches] Make System attribute correspond to SF_IMMUTABLE Responsible-Changed-From-To: freebsd-fs->fs Responsible-Changed-By: johan Responsible-Changed-When: Sat Aug 24 19:04:07 PDT 2002 Responsible-Changed-Why: Use short names for mailing list to make searches using the web query form work with the shown responsible. This also makes open PR show up in the summery mail. http://www.freebsd.org/cgi/query-pr.cgi?pr=21807 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-fs" in the body of the message