From owner-freebsd-fs Sun Aug 25 23:15:34 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 72B8637B400 for ; Sun, 25 Aug 2002 23:15:31 -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 0C9B043E42 for ; Sun, 25 Aug 2002 23:15:30 -0700 (PDT) (envelope-from bsder@mail.allcaps.org) Received: by mail.allcaps.org (Postfix, from userid 501) id 071F9153C6; Sun, 25 Aug 2002 23:15:20 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.allcaps.org (Postfix) with ESMTP id EDA1D153C2 for ; Sun, 25 Aug 2002 23:15:20 -0700 (PDT) Date: Sun, 25 Aug 2002 23:15:20 -0700 (PDT) From: "Andrew P. Lentvorski" To: freebsd-fs@freebsd.org Subject: atacontrol metadata storage Message-ID: <20020825231202.L44977-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 How and where is atacontrol storing its metadata for the RAID configurations? Atacontrol RAID configuration data seems to persist even across reboots and even seems to allow RAID-based root partitions. This also has the unfortunate effect of scrambling your disk drive if the RAID configration fails, but that's a different problem. -a To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-fs" in the body of the message From owner-freebsd-fs Mon Aug 26 11: 1:12 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 C8AB637B406 for ; Mon, 26 Aug 2002 11:01:07 -0700 (PDT) Received: from freefall.freebsd.org (freefall.FreeBSD.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6371543E4A for ; Mon, 26 Aug 2002 11:01:07 -0700 (PDT) (envelope-from owner-bugmaster@freebsd.org) Received: from freefall.freebsd.org (peter@localhost [127.0.0.1]) by freefall.freebsd.org (8.12.4/8.12.4) with ESMTP id g7QI17JU085173 for ; Mon, 26 Aug 2002 11:01:07 -0700 (PDT) (envelope-from owner-bugmaster@freebsd.org) Received: (from peter@localhost) by freefall.freebsd.org (8.12.4/8.12.4/Submit) id g7QI16YJ085169 for fs@freebsd.org; Mon, 26 Aug 2002 11:01:06 -0700 (PDT) Date: Mon, 26 Aug 2002 11:01:06 -0700 (PDT) Message-Id: <200208261801.g7QI16YJ085169@freefall.freebsd.org> X-Authentication-Warning: freefall.freebsd.org: peter set sender to owner-bugmaster@freebsd.org using -f From: FreeBSD bugmaster To: fs@FreeBSD.org Subject: Current problem reports assigned to you 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 Current FreeBSD problem reports Critical problems Serious problems Non-critical problems S Submitted Tracker Resp. Description ------------------------------------------------------------------------------- a [2000/10/06] kern/21807 fs [patches] Make System attribute correspon 1 problem total. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-fs" in the body of the message From owner-freebsd-fs Mon Aug 26 11:52:45 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 72EC537B400 for ; Mon, 26 Aug 2002 11:52:42 -0700 (PDT) Received: from carver.gumbysoft.com (carver.gumbysoft.com [66.220.23.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3647643E6A for ; Mon, 26 Aug 2002 11:52:42 -0700 (PDT) (envelope-from dwhite@gumbysoft.com) Received: by carver.gumbysoft.com (Postfix, from userid 1000) id 97D8B72FC5; Mon, 26 Aug 2002 11:50:59 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by carver.gumbysoft.com (Postfix) with ESMTP id 9352172D9E; Mon, 26 Aug 2002 11:50:59 -0700 (PDT) Date: Mon, 26 Aug 2002 11:50:59 -0700 (PDT) From: Doug White To: "Andrew P. Lentvorski" Cc: freebsd-fs@freebsd.org Subject: Re: atacontrol metadata storage In-Reply-To: <20020825231202.L44977-100000@mail.allcaps.org> Message-ID: <20020826115002.P60837-100000@carver.gumbysoft.com> 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 Sun, 25 Aug 2002, Andrew P. Lentvorski wrote: > How and where is atacontrol storing its metadata for the RAID > configurations? Its a format internal to the Promise ATA RAID controllers. I believe they place it in the protected area of the disk reserved for such things. > Atacontrol RAID configuration data seems to persist even across reboots > and even seems to allow RAID-based root partitions. This also has the > unfortunate effect of scrambling your disk drive if the RAID configration > fails, but that's a different problem. well it would sort of suck if it got lost on reboots :) Root RAID works since the RAIDing is done in hardware. -- Doug White | FreeBSD: The Power to Serve dwhite@gumbysoft.com | www.FreeBSD.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-fs" in the body of the message From owner-freebsd-fs Mon Aug 26 12: 1:49 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 52C3B37B400; Mon, 26 Aug 2002 12:01:41 -0700 (PDT) Received: from apollo.sitaranetworks.com (apollo.sitaranetworks.com [199.103.141.105]) by mx1.FreeBSD.org (Postfix) with ESMTP id 542CE43E6A; Mon, 26 Aug 2002 12:01:40 -0700 (PDT) (envelope-from cptacek@sitaranetworks.com) Received: from rios.sitaranetworks.com (rios.sitaranetworks.com [199.103.141.78]) by apollo.sitaranetworks.com (8.10.2+Sun/8.9.3) with ESMTP id g7QJ1W629027; Mon, 26 Aug 2002 15:01:32 -0400 (EDT) Received: by rios.sitaranetworks.com with Internet Mail Service (5.5.2653.19) id ; Mon, 26 Aug 2002 15:02:19 -0400 Message-ID: <31269226357BD211979E00A0C9866DAB02BB998B@rios.sitaranetworks.com> From: Chris Ptacek To: "'David Schultz'" , Giorgos Keramidas Cc: Chris Ptacek , Carlos Carnero , freebsd-questions@FreeBSD.ORG, freebsd-fs@FreeBSD.ORG Subject: RE: optimization changed from TIME to SPACE ?! Date: Mon, 26 Aug 2002 15:02:18 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" 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 I had a few questions... What actually causes the fragmentation to occur? I have tried just copying a small file over and over and this results in no fragmentation. This leads me to believe that the fragmentation is a result of simultainious open files or at least different file sizes. Also it seems that when we switch to SPACE optimizaiton is based on the % fragmentation based on the minfree setting. Can I change the minfree for the filesystem (I have a dedicated cache partition) to like 27% (8 is default) so that I am much less likely to hit the SPACE case? My question is other than reserving 27% of my disk space, will this cause any other problems or performance decreases? - Chris > -----Original Message----- > From: David Schultz [mailto:dschultz@uclink.Berkeley.EDU] > Sent: Saturday, August 24, 2002 5:01 AM > To: Giorgos Keramidas > Cc: Chris Ptacek; Carlos Carnero; freebsd-questions@FreeBSD.ORG; > freebsd-fs@FreeBSD.ORG > Subject: Re: optimization changed from TIME to SPACE ?! > > > 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-questions" 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 Mon Aug 26 13:13:30 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 9277437B400 for ; Mon, 26 Aug 2002 13:13:27 -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 1AA4543E77 for ; Mon, 26 Aug 2002 13:13:27 -0700 (PDT) (envelope-from bsder@mail.allcaps.org) Received: by mail.allcaps.org (Postfix, from userid 501) id E38B2153C6; Mon, 26 Aug 2002 13:13:20 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.allcaps.org (Postfix) with ESMTP id D7704153C2; Mon, 26 Aug 2002 13:13:20 -0700 (PDT) Date: Mon, 26 Aug 2002 13:13:20 -0700 (PDT) From: "Andrew P. Lentvorski" To: Doug White Cc: freebsd-fs@freebsd.org Subject: Re: atacontrol metadata storage In-Reply-To: <20020826115002.P60837-100000@carver.gumbysoft.com> Message-ID: <20020826130855.S46242-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 On Mon, 26 Aug 2002, Doug White wrote: > On Sun, 25 Aug 2002, Andrew P. Lentvorski wrote: > > > How and where is atacontrol storing its metadata for the RAID > > configurations? > > Its a format internal to the Promise ATA RAID controllers. I believe they > place it in the protected area of the disk reserved for such things. Ummm, really? That's interesting since I don't actually *have* a Promise ATA RAID controller in the box I'm doing these experiments on. > well it would sort of suck if it got lost on reboots :) Root RAID works > since the RAIDing is done in hardware. Root RAIDing worked just fine without any hardware RAID support at all. RAID rebuilding, on the other hand ... -a To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-fs" in the body of the message From owner-freebsd-fs Mon Aug 26 13:47: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 2F2CC37B400; Mon, 26 Aug 2002 13:47:44 -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 5C2DA43E7B; Mon, 26 Aug 2002 13:47:43 -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 g7QKmR1v000392; Mon, 26 Aug 2002 13:48:27 -0700 (PDT) (envelope-from dschultz@uclink.Berkeley.EDU) Received: (from das@localhost) by HAL9000.homeunix.com (8.12.5/8.12.5/Submit) id g7QKmCLZ000391; Mon, 26 Aug 2002 13:48:12 -0700 (PDT) (envelope-from dschultz@uclink.Berkeley.EDU) Date: Mon, 26 Aug 2002 13:48:11 -0700 From: David Schultz To: Chris Ptacek Cc: Giorgos Keramidas , Carlos Carnero , freebsd-questions@FreeBSD.ORG, freebsd-fs@FreeBSD.ORG Subject: Re: optimization changed from TIME to SPACE ?! Message-ID: <20020826204811.GA337@HAL9000.homeunix.com> Mail-Followup-To: Chris Ptacek , Giorgos Keramidas , Carlos Carnero , freebsd-questions@FreeBSD.ORG, freebsd-fs@FreeBSD.ORG References: <31269226357BD211979E00A0C9866DAB02BB998B@rios.sitaranetworks.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <31269226357BD211979E00A0C9866DAB02BB998B@rios.sitaranetworks.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 Thus spake Chris Ptacek : > I had a few questions... > What actually causes the fragmentation to occur? > I have tried just copying a small file over and > over and this results in no fragmentation. This > leads me to believe that the fragmentation is a > result of simultainious open files or at least > different file sizes. > > Also it seems that when we switch to SPACE > optimizaiton is based on the % fragmentation based > on the minfree setting. Can I change the minfree > for the filesystem (I have a dedicated cache > partition) to like 27% (8 is default) so that I > am much less likely to hit the SPACE case? My > question is other than reserving 27% of my disk > space, will this cause any other problems or > performance decreases? I'm not an expert on FFS, but hopefully someone will correct me if I have missed something. First of all, there are several kinds of fragmentation. One kind is where the blocks of a file are externally fragmented and scattered all over the disk, reducing performance. Some filesystems, such as FAT, make no effort to avoid this kind of fragmentation, which is why you need to run defrag every few weeks on them. UFS is good at avoiding this sort of fragmentation; unless the filesystem gets nearly full, it is usually able to place blocks for a given file close together. Internal fragmentation, on the other hand, occurs when a file doesn't take up all of the space in a block and the remaining space is wasted. For example, on a filesystem with an 8K block size, a 9K file requires two blocks. To mitigate this problem, FFS allows blocks to be split into up to 8 fragments. The fragments are used to store the tails of files that do not require full blocks, thus saving space. One problem with fragments is that dealing with them can be inefficient. If your 9K file grows to a 12K file, then to a 14K file, then to a 16K file, the filesystem may have to copy fragments around in order to fit all of the fragments for the end of the file into a single block. This is the kind of fragmentation fsck is telling you about. If you have FFS optimize for space, it will happily manage all of these fragments for you. If you tell it to optimize for time, FFS will still use fragments, but it won't bother to keep reallocating them when a file grows; instead, it will upgrade the file to a full block. The latter method is more efficient, but you lose a bit more space due to internal fragmentation. Thus, if FFS expects to run out of space, or if there are too many free fragments lying around, it will revert to space optimization until the situation improves. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-fs" in the body of the message From owner-freebsd-fs Mon Aug 26 15: 0: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 5A82637B400 for ; Mon, 26 Aug 2002 15:00:48 -0700 (PDT) Received: from bilver.wjv.com (user38.net339.fl.sprint-hsd.net [65.40.24.38]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8B27143E4A for ; Mon, 26 Aug 2002 15:00:47 -0700 (PDT) (envelope-from bv@bilver.wjv.com) Received: from bilver.wjv.com (localhost [127.0.0.1]) by bilver.wjv.com (8.12.5/8.12.5) with ESMTP id g7QM0kkv027649 for ; Mon, 26 Aug 2002 18:00:46 -0400 (EDT) (envelope-from bv@bilver.wjv.com) Received: (from bv@localhost) by bilver.wjv.com (8.12.5/8.12.5/Submit) id g7QM0k51027648 for freebsd-fs@freebsd.org; Mon, 26 Aug 2002 18:00:46 -0400 (EDT) Date: Mon, 26 Aug 2002 18:00:45 -0400 From: Bill Vermillion To: freebsd-fs@freebsd.org Subject: Re: optimization changed from TIME to SPACE ?! Message-ID: <20020826220045.GB27088@wjv.com> Reply-To: bv@wjv.com References: <31269226357BD211979E00A0C9866DAB02BB998B@rios.sitaranetworks.com> <20020826204811.GA337@HAL9000.homeunix.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20020826204811.GA337@HAL9000.homeunix.com> User-Agent: Mutt/1.3.25i Organization: W.J.Vermillion / Orlando - Winter Park 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 -segmentation fault- press any key to reboot Damn damn damn David Schultz said, after restarting his PC and mailer on Mon, Aug 26, 2002 at 13:48 . > Thus spake Chris Ptacek : > > What actually causes the fragmentation to occur? Read the docs or take a look at one of the books on the BSD file system to explain it fully. > I'm not an expert on FFS, but hopefully someone will correct me if > I have missed something. .... > One problem with fragments is that dealing with them can be > inefficient. If your 9K file grows to a 12K file, then to a 14K > file, then to a 16K file, the filesystem may have to copy > fragments around in order to fit all of the fragments for the end > of the file into a single block. But at the point the files goes to 16K it has no fragmentation at all and there is a good chance those two 8K allocation units will be contiguous. The FFS systme is good at this. > This is the kind of > fragmentation fsck is telling you about. If you have FFS optimize > for space, it will happily manage all of these fragments for you. > If you tell it to optimize for time, FFS will still use fragments, > but it won't bother to keep reallocating them when a file grows; > instead, it will upgrade the file to a full block. The latter > method is more efficient, but you lose a bit more space due to > internal fragmentation. Thus, if FFS expects to run out of space, > or if there are too many free fragments lying around, it will > revert to space optimization until the situation improves. I've been using FFS style systems since about 1993 - and I really like them. If you do get to the poinn where you see optimization changed from time to space - then it's time to get a bigger drive or get rid of some of the cruft. Bill -- Bill Vermillion - bv @ wjv . com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-fs" in the body of the message From owner-freebsd-fs Mon Aug 26 16:33:59 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 D0D5E37B400; Mon, 26 Aug 2002 16:33:47 -0700 (PDT) Received: from harrier.mail.pas.earthlink.net (harrier.mail.pas.earthlink.net [207.217.120.12]) by mx1.FreeBSD.org (Postfix) with ESMTP id 61CFE43E3B; Mon, 26 Aug 2002 16:33:47 -0700 (PDT) (envelope-from tlambert2@mindspring.com) Received: from pool0294.cvx21-bradley.dialup.earthlink.net ([209.179.193.39] helo=mindspring.com) by harrier.mail.pas.earthlink.net with esmtp (Exim 3.33 #1) id 17jTMT-00012C-00; Mon, 26 Aug 2002 16:33:34 -0700 Message-ID: <3D6ABA93.704F54A0@mindspring.com> Date: Mon, 26 Aug 2002 16:32:35 -0700 From: Terry Lambert X-Mailer: Mozilla 4.79 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Chris Ptacek Cc: 'David Schultz' , Giorgos Keramidas , Carlos Carnero , freebsd-questions@FreeBSD.ORG, freebsd-fs@FreeBSD.ORG Subject: Re: optimization changed from TIME to SPACE ?! References: <31269226357BD211979E00A0C9866DAB02BB998B@rios.sitaranetworks.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit 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 Chris Ptacek wrote: > I had a few questions... You would do well to read the FFS design paper. It is available at: http://citeseer.nj.nec.com/mckusick84fast.html in any format you could probably want (PDF, etc.). > What actually causes the fragmentation to occur? There are two types of fragmentation: external fragmentation, which can be a performance issue, and internal fragmentation, which is based on the smalles permissible allocation using in the filesystem. In FFS, there are only two causes of external fragmentation: 1) Putting more data on a disk than the free reserve would permit (can only be done by root, and you will see it complain and state "changed optimization from time to space"). 2) Filling up a disk, and then using "growfs", without also doing a backup/restore to spread the pre-existing data out over the whole space, instead of just the front of the disk. Internal fragmentation occurs based on the "frag size"; this is normally 1/8 of the file system block size. The current defaults for block size and frag size, respectively, are 16K and 2K. This means that the smallest amount of space you can allocate is 2K, and that any file on average, will allocate 2K/2 (or 1K) of space that is not usable for other files. All filesystems have internal fragmentation; historically, FFS used a 4K/512b sizing, rather than a 16K/2K sizing. Since a physical block 512b, and that is the smallest addressable unit on a disk device, that is as optimum as it is possible to get on internal fragmentation. At this "frag size", the average "wasted space" per file is 256b. For large FSs, and for modern data cache sizes -- on disks, controllers, and in system memory itself -- the larger size is generally more efficient. Also, it is necessary for incredibly large disks to use a larger filesystem block size in order to be able to span all that space. You can select the filesystem block size/frag size ratio to be 1:1, 1:2, 1:4, or 1:8 at the time you newfs the disk. These are the only permissable values, and 1:8 is almost always the correct one. > I have tried just copying a small file over and > over and this results in no fragmentation. This > leads me to believe that the fragmentation is a > result of simultainious open files or at least > different file sizes. No. It is a result of discontiguous small free areas; a small file being copied would almost never demonstrate any external fragmentation. The best possible demonstration is a bunch of allocations of the same two sizes, large and small, spanning 2/3 + 1 of a cluster of 9 disk blocks, and deleting the small ones and repeating the process with only large ones, as root, until the disk is physically full. > Also it seems that when we switch to SPACE > optimizaiton is based on the % fragmentation based > on the minfree setting. Can I change the minfree > for the filesystem (I have a dedicated cache > partition) to like 27% (8 is default) so that I > am much less likely to hit the SPACE case? My > question is other than reserving 27% of my disk > space, will this cause any other problems or > performance decreases? 15% is the best number. A Perfect Hash does not suffer any collisions until an 85% fill has been achieved. Anything more than 15% is a waste; anything less will exponentially degrade performance. The current default value of 8% is a compromise (it used to be 10% by default) for people who believe that the reserved space is "wasted" because they do not understand statistics or hashing. It was picked because it's the largest number that "seems to be a small percentage". The switch to space optimization occurs at 5%. If you are getting to the point that space optimization is occurring, it means you are using 3% of your free reserve. Since only root can use the free reserve ("for emergencies"), that means that whatever you are doing, you are doing as root. Thus the easiest way to avoid switching to space optimization is to not run your programs as root. For programs which *must* run as root (not even logging "must" run as root, once the reserved port has been obtained), don't share the FS between the root program and user programs. -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-fs" in the body of the message From owner-freebsd-fs Tue Aug 27 15:28:14 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 668CA37B400 for ; Tue, 27 Aug 2002 15:28:12 -0700 (PDT) Received: from carver.gumbysoft.com (carver.gumbysoft.com [66.220.23.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2DA7643E3B for ; Tue, 27 Aug 2002 15:28:12 -0700 (PDT) (envelope-from dwhite@gumbysoft.com) Received: by carver.gumbysoft.com (Postfix, from userid 1000) id D288872FC5; Tue, 27 Aug 2002 15:26:16 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by carver.gumbysoft.com (Postfix) with ESMTP id CE7A072D9E; Tue, 27 Aug 2002 15:26:16 -0700 (PDT) Date: Tue, 27 Aug 2002 15:26:16 -0700 (PDT) From: Doug White To: "Andrew P. Lentvorski" Cc: freebsd-fs@freebsd.org Subject: Re: atacontrol metadata storage In-Reply-To: <20020826130855.S46242-100000@mail.allcaps.org> Message-ID: <20020827152601.G68343-100000@carver.gumbysoft.com> 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 Mon, 26 Aug 2002, Andrew P. Lentvorski wrote: > On Mon, 26 Aug 2002, Doug White wrote: > > > On Sun, 25 Aug 2002, Andrew P. Lentvorski wrote: > > > > > How and where is atacontrol storing its metadata for the RAID > > > configurations? > > > > Its a format internal to the Promise ATA RAID controllers. I believe they > > place it in the protected area of the disk reserved for such things. > > Ummm, really? That's interesting since I don't actually *have* a Promise > ATA RAID controller in the box I'm doing these experiments on. Are you using vinum? -- Doug White | FreeBSD: The Power to Serve dwhite@gumbysoft.com | www.FreeBSD.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-fs" in the body of the message From owner-freebsd-fs Tue Aug 27 16: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 187FA37B400 for ; Tue, 27 Aug 2002 16:19:45 -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 B12CA43E4A for ; Tue, 27 Aug 2002 16:19:44 -0700 (PDT) (envelope-from bsder@mail.allcaps.org) Received: by mail.allcaps.org (Postfix, from userid 501) id C480D154AA; Tue, 27 Aug 2002 16:19:43 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.allcaps.org (Postfix) with ESMTP id B8BB1154A9; Tue, 27 Aug 2002 16:19:43 -0700 (PDT) Date: Tue, 27 Aug 2002 16:19:43 -0700 (PDT) From: "Andrew P. Lentvorski" To: Doug White Cc: freebsd-fs@freebsd.org Subject: Re: atacontrol metadata storage In-Reply-To: <20020827152601.G68343-100000@carver.gumbysoft.com> Message-ID: <20020827161723.C48439-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 No, I'm not using vinum. I'm using atacontrol. If you want a full explanation of my attempts to use atacontrol for RAID, please see my post on -STABLE: http://docs.freebsd.org/cgi/getmsg.cgi?fetch=698625+0+archive/2002/freebsd-stable/20020825.freebsd-stable -a To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-fs" in the body of the message From owner-freebsd-fs Tue Aug 27 18:47:32 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 A236337B400 for ; Tue, 27 Aug 2002 18:47:24 -0700 (PDT) Received: from rshb.com.ru (rshb.com.ru [195.162.58.1]) by mx1.FreeBSD.org (Postfix) with ESMTP id A51A243E4A for ; Tue, 27 Aug 2002 18:47:23 -0700 (PDT) (envelope-from admin@rshb.com.ru) Received: by rshb.com.ru (Sendmail for UK-NC RT11-SJ, from userid 426) id AB685580E; Wed, 28 Aug 2002 08:47:22 +0700 (OMSST) Received: from rshb.com.ru (vampiro.rsb.local [192.168.1.111]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (Client CN "Evgueni V. Gavrilov", Issuer "RSHB Omsk branch CA" (verified OK)) by rshb.com.ru (Sendmail for UK-NC RT11-SJ) with ESMTP id 745365809 for ; Wed, 28 Aug 2002 08:47:22 +0700 (OMSST) Message-ID: <3D6C2BAA.50009@rshb.com.ru> Date: Wed, 28 Aug 2002 08:47:22 +0700 From: "Evgueni V. Gavrilov" User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.0.0) Gecko/20020813 X-Accept-Language: ru, en MIME-Version: 1.0 To: freebsd-fs@freebsd.org Subject: [Fwd: Further investigation with panic: softdep_lock: locking against myself] Content-Type: text/plain; charset=KOI8-R; format=flowed Content-Transfer-Encoding: 7bit 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 guys I forgot to put fs maillist to cc. Sorry. I sent PR also (http://www.freebsd.org/cgi/query-pr.cgi?pr=42064). -------- Original Message -------- Date: Tue, 27 Aug 2002 20:41:15 +0700 From: "Evgueni V. Gavrilov" To: freebsd-stable@freebsd.org hi As I wrote before - several kernel panics per day achieved with softupdates code. I totally replaced hardware on that box but troubles remain. Any suggestions ? $ gdb -k kernel.debug vmcore.2 GNU gdb 4.18 (FreeBSD) Copyright 1998 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "i386-unknown-freebsd"... IdlePTD at phsyical address 0x00335000 initial pcb at physical address 0x002a8420 panicstr: softdep_lock: locking against myself panic messages: --- Fatal trap 12: page fault while in kernel mode fault virtual address = 0xffff000a fault code = supervisor read, page not present instruction pointer = 0x8:0xc01f9b5c stack pointer = 0x10:0xcd10cd10 frame pointer = 0x10:0xcd10cd10 code segment = base 0x0, limit 0xfffff, type 0x1b = DPL 0, pres 1, def32 1, gran 1 processor eflags = interrupt enabled, resume, IOPL = 0 current process = 5 (syncer) interrupt mask = bio trap number = 12 panic: page fault syncing disks... panic: softdep_lock: locking against myself Uptime: 36m49s dumping to dev #ad/0x20001, offset 128 dump ata0: resetting devices .. done 255 254 253 252 251 250 249 248 247 246 245 244 243 242 241 240 239 238 237 236 235 234 233 232 231 230 229 228 227 226 225 224 223 222 221 220 219 218 217 216 215 214 213 212 211 210 209 208 207 206 205 204 203 202 201 200 199 198 197 196 195 194 193 192 191 190 189 188 187 186 185 184 183 182 181 180 179 178 177 176 175 174 173 172 171 170 169 168 167 166 165 164 163 162 161 160 159 158 157 156 155 154 153 152 151 150 149 148 147 146 145 144 143 142 141 140 139 138 137 136 135 134 133 132 131 130 129 128 127 126 125 124 123 122 121 120 119 118 117 116 115 114 113 112 111 110 109 108 107 106 105 104 103 102 101 100 99 98 97 96 95 9 4 93 92 91 90 89 88 87 86 85 84 83 82 81 80 79 78 77 76 75 74 73 72 71 70 69 68 67 66 65 64 63 62 61 60 59 58 57 56 55 54 53 52 51 50 49 48 47 46 45 44 43 42 41 40 39 38 37 36 35 34 33 32 31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 1 4 13 12 11 10 9 8 7 6 5 4 3 2 1 0 --- #0 dumpsys () at /usr/src/sys/kern/kern_shutdown.c:487 487 if (dumping++) { (kgdb) where #0 dumpsys () at /usr/src/sys/kern/kern_shutdown.c:487 #1 0xc0158ba3 in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:316 #2 0xc0158fc8 in poweroff_wait (junk=0xc02711c0, howto=0) at /usr/src/sys/kern/kern_shutdown.c:595 #3 0xc01f988e in acquire_lock (lk=0xc0296c1c) at /usr/src/sys/ufs/ffs/ffs_softdep.c:261 #4 0xc01fdeca in softdep_fsync_mountdev (vp=0xcd0ff900) at /usr/src/sys/ufs/ffs/ffs_softdep.c:4024 #5 0xc02020fa in ffs_fsync (ap=0xcd10cbb0) at /usr/src/sys/ufs/ffs/ffs_vnops.c:134 #6 0xc0200d8b in ffs_sync (mp=0xc1278600, waitfor=2, cred=0xc0a3c600, p=0xc02bcee0) at vnode_if.h:558 #7 0xc0189267 in sync (p=0xc02bcee0, uap=0x0) at /usr/src/sys/kern/vfs_syscalls.c:576 #8 0xc0158916 in boot (howto=256) at /usr/src/sys/kern/kern_shutdown.c:235 #9 0xc0158fc8 in poweroff_wait (junk=0xc027b2cc, howto=-1071141393) at /usr/src/sys/kern/kern_shutdown.c:595 #10 0xc0243112 in trap_fatal (frame=0xcd10ccd0, eva=4294901770) at /usr/src/sys/i386/i386/trap.c:974 #11 0xc0242de5 in trap_pfault (frame=0xcd10ccd0, usermode=0, eva=4294901770) at /usr/src/sys/i386/i386/trap.c:867 #12 0xc02429a3 in trap (frame={tf_fs = 16, tf_es = 16, tf_ds = 16, tf_edi = 0, tf_esi = -1052660736, tf_ebp = -854536944, tf_isp = -854536964, tf_ebx = -65536, tf_edx = -1052064512, tf_ecx = -65536, tf_eax = -1052064512, tf_trapno = 12, tf_err = 0, tf_eip = -1071670436, tf_cs = 8, tf_eflags = 66071, tf_esp = -854536912, tf_ss = -1071654306}) at /usr/src/sys/i386/i386/trap.c:466 #13 0xc01f9b5c in worklist_remove (item=0xffff0000) at /usr/src/sys/ufs/ffs/ffs_softdep.c:467 #14 0xc01fda5e in softdep_update_inodeblock (ip=0xc141ac00, bp=0xc65340b0, waitfor=0) at /usr/src/sys/ufs/ffs/ffs_softdep.c:3847 #15 0xc01f89dd in ffs_update (vp=0xcdb05840, waitfor=0) at /usr/src/sys/ufs/ffs/ffs_inode.c:106 #16 0xc01f8cc1 in ffs_truncate (vp=0xcdb05840, length=0, flags=0, cred=0x0, p=0xcc02b780) at /usr/src/sys/ufs/ffs/ffs_inode.c:201 #17 0xc02030d8 in ufs_inactive (ap=0xcd10ced8) at /usr/src/sys/ufs/ufs/ufs_inode.c:89 #18 0xc02085d1 in ufs_vnoperate (ap=0xcd10ced8) at /usr/src/sys/ufs/ufs/ufs_vnops.c:2422 #19 0xc01873b8 in vput (vp=0xcdb05840) at vnode_if.h:815 #20 0xc01fc864 in handle_workitem_remove (dirrem=0xc0a351c0) at /usr/src/sys/ufs/ffs/ffs_softdep.c:2852 #21 0xc01f9edd in process_worklist_item (matchmnt=0x0, flags=0) at /usr/src/sys/ufs/ffs/ffs_softdep.c:716 #22 0xc01f9d82 in softdep_process_worklist (matchmnt=0x0) at /usr/src/sys/ufs/ffs/ffs_softdep.c:622 #23 0xc0186cdf in sched_sync () at /usr/src/sys/kern/vfs_subr.c:1177 (kgdb) up 13 #13 0xc01f9b5c in worklist_remove (item=0xffff0000) at /usr/src/sys/ufs/ffs/ffs_softdep.c:467 467 panic("worklist_remove: lock not held"); (kgdb) l 462 worklist_remove(item) 463 struct worklist *item; 464 { 465 466 if (lk.lkt_held == -1) 467 panic("worklist_remove: lock not held"); 468 if ((item->wk_state & ONWORKLIST) == 0) { 469 FREE_LOCK(&lk); 470 panic("worklist_remove: not on list"); 471 } (kgdb) p item $1 = (struct worklist *) 0x0 (kgdb) p lk.lkt_held $2 = -1 (kgdb) up #14 0xc01fda5e in softdep_update_inodeblock (ip=0xc141ac00, bp=0xc65340b0, waitfor=0) at /usr/src/sys/ufs/ffs/ffs_softdep.c:3847 3847 WORKLIST_REMOVE(wk); (kgdb) list 3842 * operations dependent on the inode being written to disk 3843 * can be moved to the id_bufwait so that they will be 3844 * processed when the buffer I/O completes. 3845 */ 3846 while ((wk = LIST_FIRST(&inodedep->id_inowait)) != NULL) { 3847 WORKLIST_REMOVE(wk); 3848 WORKLIST_INSERT(&inodedep->id_bufwait, wk); 3849 } 3850 /* 3851 * Newly allocated inodes cannot be written until the bitmap (kgdb) p wk $3 = (struct worklist *) 0x68c040 (kgdb) p wk->wk_list Cannot access memory at address 0x68c040. (kgdb) p wk->wk_state Cannot access memory at address 0x68c04a. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-stable" 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 29 7:36:15 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 4B0B137B400 for ; Thu, 29 Aug 2002 07:36:12 -0700 (PDT) Received: from scrooge.etek.chalmers.se (scrooge.etek.chalmers.se [129.16.32.112]) by mx1.FreeBSD.org (Postfix) with ESMTP id 367E343E42 for ; Thu, 29 Aug 2002 07:36:11 -0700 (PDT) (envelope-from b@etek.chalmers.se) Received: from scrooge.etek.chalmers.se (b@localhost [127.0.0.1]) by scrooge.etek.chalmers.se (8.12.3/8.12.3) with ESMTP id g7TEaA9E012136 for ; Thu, 29 Aug 2002 16:36:10 +0200 (CEST) (envelope-from b@etek.chalmers.se) Received: from localhost (b@localhost) by scrooge.etek.chalmers.se (8.12.3/8.12.3/Submit) with ESMTP id g7TEa9UL012133 for ; Thu, 29 Aug 2002 16:36:10 +0200 (CEST) X-Authentication-Warning: scrooge.etek.chalmers.se: b owned process doing -bs Date: Thu, 29 Aug 2002 16:36:09 +0200 (CEST) From: Magnus B{ckstr|m To: freebsd-fs@freebsd.org Subject: smbfs password capitalization 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 smbfs(4) capitalizes the password before attempting to authenticate to an SMB server. This ceased being a good idea once even m$ admitted the benefits of mixed-case passwords; can/should we change it? I propose the below patch. Magnus diff -u src/sys/netsmb.ORIG/smb_conn.c src/sys/netsmb/smb_conn.c --- src/sys/netsmb.ORIG/smb_conn.c Wed Aug 7 12:53:52 2002 +++ src/sys/netsmb/smb_conn.c Thu Aug 29 17:29:43 2002 @@ -429,7 +429,6 @@ ierror((vcp->vc_username = smb_strdup(vcspec->username)) == NULL, ENOMEM); ithrow(iconv_open("tolower", vcspec->localcs, &vcp->vc_tolower)); - ithrow(iconv_open("toupper", vcspec->localcs, &vcp->vc_toupper)); if (vcspec->servercs[0]) { ithrow(iconv_open(vcspec->servercs, vcspec->localcs, &vcp->vc_toserver)); @@ -464,8 +463,6 @@ free(vcp->vc_laddr, M_SONAME); if (vcp->vc_tolower) iconv_close(vcp->vc_tolower); - if (vcp->vc_toupper) - iconv_close(vcp->vc_toupper); if (vcp->vc_tolocal) iconv_close(vcp->vc_tolocal); if (vcp->vc_toserver) diff -u src/sys/netsmb.ORIG/smb_conn.h src/sys/netsmb/smb_conn.h --- src/sys/netsmb.ORIG/smb_conn.h Thu Feb 21 17:13:19 2002 +++ src/sys/netsmb/smb_conn.h Thu Aug 29 17:29:14 2002 @@ -244,7 +244,6 @@ int vc_maxvcs; /* maximum number of VC per connection */ void * vc_tolower; /* local charset */ - void * vc_toupper; /* local charset */ void * vc_toserver; /* local charset to server one */ void * vc_tolocal; /* server charset to local one */ int vc_number; /* number of this VC from the client side */ diff -u src/sys/netsmb.ORIG/smb_smb.c src/sys/netsmb/smb_smb.c --- src/sys/netsmb.ORIG/smb_smb.c Thu Feb 21 17:18:39 2002 +++ src/sys/netsmb/smb_smb.c Thu Aug 29 17:06:04 2002 @@ -247,7 +247,7 @@ pbuf = malloc(SMB_MAXPASSWORDLEN + 1, M_SMBTEMP, M_WAITOK); encpass = malloc(24, M_SMBTEMP, M_WAITOK); if (vcp->vc_sopt.sv_sm & SMB_SM_USER) { - iconv_convstr(vcp->vc_toupper, pbuf, smb_vc_getpass(vcp)); + strncpy(pbuf, smb_vc_getpass(vcp), SMB_MAXPASSWORDLEN); iconv_convstr(vcp->vc_toserver, pbuf, pbuf); if (vcp->vc_sopt.sv_sm & SMB_SM_ENCRYPT) { uniplen = plen = 24; @@ -415,7 +415,7 @@ } else { pbuf = malloc(SMB_MAXPASSWORDLEN + 1, M_SMBTEMP, M_WAITOK); encpass = malloc(24, M_SMBTEMP, M_WAITOK); - iconv_convstr(vcp->vc_toupper, pbuf, smb_share_getpass(ssp)); + strncpy(pbuf, smb_share_getpass(ssp), SMB_MAXPASSWORDLEN); iconv_convstr(vcp->vc_toserver, pbuf, pbuf); if (vcp->vc_sopt.sv_sm & SMB_SM_ENCRYPT) { plen = 24; To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-fs" in the body of the message From owner-freebsd-fs Thu Aug 29 12:16:26 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 C51FA37B400 for ; Thu, 29 Aug 2002 12:16:23 -0700 (PDT) Received: from snipe.mail.pas.earthlink.net (snipe.mail.pas.earthlink.net [207.217.120.62]) by mx1.FreeBSD.org (Postfix) with ESMTP id 716F243E42 for ; Thu, 29 Aug 2002 12:16:23 -0700 (PDT) (envelope-from tlambert2@mindspring.com) Received: from pool0180.cvx40-bradley.dialup.earthlink.net ([216.244.42.180] helo=mindspring.com) by snipe.mail.pas.earthlink.net with esmtp (Exim 4.10) id 17kUly-00062n-00; Thu, 29 Aug 2002 12:16:06 -0700 Message-ID: <3D6E72BC.6BB5B9F5@mindspring.com> Date: Thu, 29 Aug 2002 12:15:08 -0700 From: Terry Lambert X-Mailer: Mozilla 4.79 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Magnus B{ckstr|m Cc: freebsd-fs@freebsd.org Subject: Re: smbfs password capitalization References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit 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 Magnus B{ckstr|m wrote: > smbfs(4) capitalizes the password before attempting to authenticate to > an SMB server. This ceased being a good idea once even m$ admitted the > benefits of mixed-case passwords; can/should we change it? > I propose the below patch. According to Jeremy Allison, it should try the password as it was supplied by the user, and, if that fails, try the case-folded password instead. Otherewise, you do not have compatability with old servers that expect the case folding behaviour. -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-fs" in the body of the message From owner-freebsd-fs Sat Aug 31 12: 0:53 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 6323237B400 for ; Sat, 31 Aug 2002 12:00:34 -0700 (PDT) Received: from relay2.kornet.net (relay2.kornet.net [211.48.62.162]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2D1B543E77 for ; Sat, 31 Aug 2002 11:59:41 -0700 (PDT) (envelope-from ggaggung13@kornet.net) Received: from you10-l4kjkpuq6 (61.73.136.251) by relay2.kornet.net; 1 Sep 2002 03:58:49 +0900 Message-ID: <3d7111ee3d9aee79@relay2.kornet.net> (added by relay2.kornet.net) From: =?ks_c_5601-1987?B?x/a06yDEq7XlILCzwM4gvLOw6Lvn?= To: freebsd-fs@FreeBSD.ORG Subject: =?ks_c_5601-1987?B?W7GksO1dIGZyZWVic2QtZnO01CDA57nMwNa0wiC758C6x7DAuyC15biztM+02S4=?= Date: Sun, 01 Sep 2002 03:07:14 +0900 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0037_01C0F07A.93A14C00" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 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 This is a multi-part message in MIME format. ------=_NextPart_000_0037_01C0F07A.93A14C00 Content-Type: text/plain; charset="ks_c_5601-1987" Content-Transfer-Encoding: base64 vcXDu7ytuN7Az8b7IGE6bGlua3sgdGV4dC1kZWNvcmF0aW9uOm5vbmU7IGNvbG9yOmZmZmZm Zjtmb250LXNpemU6OXB0O31hOnZpc2l0ZWQgeyB0ZXh0LWRlY29yYXRpb246bm9uZTsgY29s b3I6ZmZmZmZmO2ZvbnQtc2l6ZTo5cHQ7fWE6aG92ZXIgeyB0ZXh0LWRlY29yYXRpb246dW5k ZXJsaW5lOyBDb2xvcjojRkFCODU2O2ZvbnQtc2l6ZTo5cHQ7fWE6YWN0aXZlIHsgdGV4dC1k ZWNvcmF0aW9uOm5vbmU7Y29sb3I6I0ZBQjg1Njtmb250LXNpemU6OXB0O30tLT4geXl5ICkg fHwgKHlfY2hrID09IHl5eSAmJiBtX2NoayA+IG1tKSB8fCAoeV9jaGsgPT0geXl5ICYmIG1f Y2hrID09IG1tICYmIGRfY2hrID4gZGQpKSB7IGFsZXJ0KCIyMLy8ILnMuLjAuiC9xcO7wMwg utKwobTJx9W0z7TZLiIpOyByZXR1cm4gZmFsc2U7ICB9cmV0dXJuIHRydWU7fS8vwda5zrXu t88gw7zFqWZ1bmN0aW9uIGp1bWluY2hrKGFkdWx0KXsJanVtaW50b3QgPSAwOwlqdW1pbmFk ZCA9ICcyMzQ1Njc4OTIzNDUnOwlmb3IoaT0wO2kNCiANCiAgIA0KICAgICAgDQogDQogICAg IAkJCQkJICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICC8urjtICAJCSAgICAgwda5 zrXut88gufjIoyAoIi0iwNS3wikgDQogICAgICAgICAgICAgICAgICAgICAgICAgwffA5SDA /MitICAgICAgyN6068b5ICANCiAgICAgICAgIA0KvcWx1CDIuL/4IL+syLi68SAguOnBpg0K IMf2tOsgwNq1v8L3ILG4wNS9wyDG98DOxq4gx9LAziANCrG5s7vD1sPKIMHWwK8gurjH6Lmr t+EgsKHA1A0KIMGkuvEgwNq1v8L3IL/rx7Agx9LAzg0KICAgICAgDQogIMf2tOsgIE0gxKu1 5Q0KICAgDQoNCiAgDQq9xbHUIMi4v/ggv6zIuLrxICC46cGmDQogseK+xiDA2rW/wvcgsbjA 1L3DIMb3wM7GriDH0sDOIA0Ksbmzu8PWw8ogwdbAryC6uMfouau34SCwocDUDQogwaS68SDA 2rW/wvcgv+vHsCDH0sDODQogICAgICAgseK+xiAgs+u67be5vboNCiAgIA0KDQogICANCsby u/0gv6zIuLrxILjpwaYNCiDG98DOxq6zs7rOLLD4sPqx3SDEq7XlsOHBpiC8rbrxvbogDQog x/a068GkwK8gp6QgtOcgNDC/+CANCr+1yK0gv7m4xSDA5bTnIDIsMDAwv/ggx9LAziANCiAg ICAgIA0KICBLVCAguvTHw7bzwNoNCiAgIA0KDQogIA0Ku+e/68fRIDAuNSW4piAgutK/7MDM v/S1vbHiDQogxvK7/SC/rMi4uvEguOnBpiANCrHdwLa8rbrxvboNCiA1vu8guau34SC6uMfo IA0KDQoNCg0KICAgICAgILvntvvAxyAgvNWw4cbsseINCiAgIA0KDQogICAgILHNx8/AxyAg uN7Az8HWvNK0wiDApbytx87AuyDF68fYILz2wf3H0SCwzcDMuOcsILHXv9y/oSC+7rawx9Eg waS6uLW1ILCusO0gIMDWwfYgvsrAvcC7ILngyPy0z7TZLg0KICDAzCBFLW1haWzAuiC5373F wPy/68DMuOcsIL/4xKEgvsrAuL3HICCw5r/sIL7Gt6Egw6K/oSC43sDPwda80rimIMDUt8LH z7+pIMHWvcO46SC1ziC5+CC02b3DILjewM/AzCAgsKHB9iAgvsq1tbfPIMfPsNq9wLTPtNku DQogICANCiAgICAgICAgICAgICAgICAgICC6uyC43sDPwLogwaS6uMXrvcW6ziCxx7DtILvn x9e/oSDAx7DFIMGmuPG/oSBbsaSw7V2287DtIMelvcO1yCCxpLDtILjewM/A1LTPtNkuDQog ICAgICAgICAgICAgICAgICAgICAgILn2xrDAuyDFrLivx8+9w7jpILz2vcWwxbrOw7O4rrCh IMDMt+e+7iDB/bTPtNkuIA0KICAgICAgICAgIElmIHlvdSB3b24ndCByZWNlaXZlIGFueSBt b3JlIG1haWwgYWJvdXQgdGhpcyBzaXRlLCANCiAgcHJlc3MgYnV0dG9uIGFuZCBmaWxsIHlv dXIgZS1tYWlsIGFkZHJlc3MuIEFuZCB0aGVuIHdlIHdpbGwgbm90IHNlbmQgYW55IG1haWwg dG8geW91DQogICAgICAgICAgDQoNCiAgIA0KICAgICAgDQogICAgIA0KICAgICAgICAgICAg ZW5leHRvcEBseWNvcy5jby5rcg0KICAgICANCiAgICAgICAgIA0KICAgICAgIA0KIA0K ------=_NextPart_000_0037_01C0F07A.93A14C00 Content-Type: text/html; charset="ks_c_5601-1987" Content-Transfer-Encoding: base64 PGh0bWw+DQoNCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVpdj0iY29udGVudC10eXBlIiBjb250 ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9ZXVjLWtyIj4NCjx0aXRsZT69xcO7vK243sDPxvsg PC90aXRsZT4NCjxTQ1JJUFQgbGFuZ3VhZ2U9amF2YXNjcmlwdD4NCjwhLS0NCmZ1bmN0aW9u IGNsaWNrTW91c2UoKQ0KCXsNCgkgIA0KCQlpZiAoKGV2ZW50LmJ1dHRvbj09MikgfHwgKGV2 ZW50LmJ1dHRvbj09Mykpew0KCQkJcmV0dXJuIChmYWxzZSk7DQoJCX0JDQoJfQ0KCQ0KCWZ1 bmN0aW9uIGNsaWNrS2V5KCkNCgl7DQoJCWlmKChldmVudC5zaGlmdEtleSkgJiYgKGV2ZW50 LmtleUNvZGUgPT0gMTIxKSkNCgkJewkJDQoJCQlyZXR1cm4gZmFsc2U7DQoJCX0JDQoJfQ0K CQ0KCWZ1bmN0aW9uIG5vQWN0aW9uKCl7DQoJCXJldHVybiBmYWxzZTsNCgl9DQoNCmRvY3Vt ZW50Lm9ubW91c2Vkb3duPWNsaWNrTW91c2UNCmRvY3VtZW50Lm9ua2V5ZG93bj1jbGlja0tl eQ0KZG9jdW1lbnQub25jb250ZXh0bWVudT1ub0FjdGlvbg0KZG9jdW1lbnQub25kcmFnc3Rh cnQ9bm9BY3Rpb24NCmRvY3VtZW50Lm9uc2VsZWN0c3RhcnQ9bm9BY3Rpb24NCi8vLS0+DQo8 L3NjcmlwdD4NCjxzdHlsZSB0eXBlPSJ0ZXh0L2NzcyI+DQo8IS0tDQouZm9udCB7ICBmb250 LXNpemU6IDlwdH0NCi0tPg0KYTpsaW5rew0KICAgIHRleHQtZGVjb3JhdGlvbjpub25lOyBj b2xvcjpmZmZmZmY7Zm9udC1zaXplOjlwdDt9DQphOnZpc2l0ZWQgew0KICAgIHRleHQtZGVj b3JhdGlvbjpub25lOyBjb2xvcjpmZmZmZmY7Zm9udC1zaXplOjlwdDt9DQphOmhvdmVyIHsN CiAgICB0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lOyBDb2xvcjojRkFCODU2O2ZvbnQtc2l6 ZTo5cHQ7fQ0KYTphY3RpdmUgew0KICAgIHRleHQtZGVjb3JhdGlvbjpub25lO2NvbG9yOiNG QUI4NTY7Zm9udC1zaXplOjlwdDt9DQotLT4NCjwvc3R5bGU+DQo8c2NyaXB0IGxhbmd1YWdl PSJKYXZhU2NyaXB0Ij4NCjwhLS0NCg0KZnVuY3Rpb24gc2VuZGl0KCl7DQoNCiAgICBpZiAo bWFpbGZybTEubmFtZS52YWx1ZSA9PSAiIil7DQogICAgICAgIGFsZXJ0KCK8urjtwLsgwNS3 wsfPvcq9w7/ALiIpOw0KICAgICAgICBtYWlsZnJtMS5uYW1lLmZvY3VzKCk7DQoNCiAgICAg ICAgcmV0dXJuIGZhbHNlOw0KICAgIH0NCglpZiAobWFpbGZybTEuaGFuZG51bS52YWx1ZT09 IiIpew0KCQlhbGVydCgiwPu+7rW1IMfPs6rAxyDA/MitufjIo7imIMDUt8LH2MHWvLy/5C5c blxutdG02SDA1LfCx8+9w7jpILr8uKW9xcO7wMwgsKG0ycfVtM+02S4iKTsNCgkJbWFpbGZy bTEuaGFuZG51bS5mb2N1cygpOw0KDQoJCXJldHVybiBmYWxzZTsNCgl9DQogICAgdmFyIGp1 bWluID0gbWFpbGZybTEuanVtaW4udmFsdWU7DQoNCglpZiAoanVtaW5jaGsoanVtaW4pKXsN CgkJYWxlcnQoIsHWuc617rfPufjIo7ChIL/Dudm4o8H2IL7KvcC0z7TZLiIpOw0KCQltYWls ZnJtMS5qdW1pbi5zZWxlY3QoKTsNCgkJcmV0dXJuIGZhbHNlOw0KCX0NCg0KICAgIHRvZGF5 ID0gbmV3IERhdGUoKTsNCiAgICB5eSA9IHRvZGF5LmdldFllYXIoKTsNCiAgICBtbSA9IHRv ZGF5LmdldE1vbnRoKCkrMTsNCiAgICBkZCA9IHRvZGF5LmdldERhdGUoKTsNCiAgICB5eXkg PSBldmFsKHl5KSAtIGV2YWwoMTkpDQogICAgDQogICAgeV9jaGsgPSBldmFsKCIxOSIranVt aW4uc3Vic3RyaW5nKDAsMikpDQogICAgbV9jaGsgPSBldmFsKGp1bWluLnN1YnN0cmluZygy LDQpKQ0KICAgIGRfY2hrID0gZXZhbChqdW1pbi5zdWJzdHJpbmcoNCw2KSkNCg0KICAgIGlm ICgoeV9jaGsgPiB5eXkgKSB8fCAoeV9jaGsgPT0geXl5ICYmIG1fY2hrID4gbW0pIHx8ICh5 X2NoayA9PSB5eXkgJiYgbV9jaGsgPT0gbW0gJiYgZF9jaGsgPiBkZCkpIHsNCg0KICAgICAg ICBhbGVydCgiMjC8vCC5zLi4wLogvcXDu8DMILrSsKG0ycfVtM+02S4iKTsNCiAgICAgICAg cmV0dXJuIGZhbHNlOw0KICAgICAgICANCiAgICB9DQpyZXR1cm4gdHJ1ZTsNCn0NCg0KLy/B 1rnOte63zyDDvMWpDQpmdW5jdGlvbiBqdW1pbmNoayhhZHVsdCl7DQoJanVtaW50b3QgPSAw Ow0KCWp1bWluYWRkID0gJzIzNDU2Nzg5MjM0NSc7DQoNCglmb3IoaT0wO2k8MTI7aSsrKXsN Cg0KCQlqdW1pbnRvdCA9IGp1bWludG90ICsgcGFyc2VJbnQoYWR1bHQuc3Vic3RyaW5nKGks aSsxKSkgKiBwYXJzZUludChqdW1pbmFkZC5zdWJzdHJpbmcoaSxpKzEpKTsNCgl9DQoNCglq dW1pbnRvdCA9IDExLShqdW1pbnRvdCUxMSk7DQoNCglpZiAoanVtaW50b3QgPT0gMTApew0K CQlqdW1pbnRvdD0wOw0KCX0NCgllbHNlIGlmIChqdW1pbnRvdCA9PSAxMSl7DQoJCWp1bWlu dG90ID0gMTsNCgl9DQoNCglpZiAocGFyc2VJbnQoYWR1bHQuc3Vic3RyaW5nKDEyLDEzKSkg IT0ganVtaW50b3QpDQoJcmV0dXJuIHRydWUNCn0NCg0KLy8tLT4NCjwvc2NyaXB0Pg0KDQo8 L2hlYWQ+DQo8Ym9keSBiZ2NvbG9yPSJ3aGl0ZSIgdGV4dD0iYmxhY2siIGxpbms9ImJsdWUi IHZsaW5rPSJwdXJwbGUiIGFsaW5rPSJyZWQiIG9ubG9hZD0ibWFpbGZybTEubmFtZS5mb2N1 cygpOyI+DQo8cD4mbmJzcDs8L3A+DQo8dGFibGUgYWxpZ249ImNlbnRlciIgYm9yZGVyPSIx IiBjZWxsc3BhY2luZz0iMCIgd2lkdGg9IjYzMiIgYm9yZGVyY29sb3JkYXJrPSJ3aGl0ZSIg Ym9yZGVyY29sb3JsaWdodD0iYmxhY2siIGJnY29sb3I9IndoaXRlIj4NCiAgICA8dHI+DQog ICAgICAgIDx0ZCB3aWR0aD0iOTc0Ij4NCiAgICAgICAgICAgIDxwIGFsaWduPSJjZW50ZXIi PjxpbWcgc3JjPSJodHRwOi8vaXllc2NhcmQuY29tL2ltZy83LmdpZiIgd2lkdGg9IjYzMiIg aGVpZ2h0PSIxNzQiIGJvcmRlcj0iMCI+PC9wPg0KICAgICAgICA8L3RkPg0KICAgIDwvdHI+ DQogICAgPHRyPg0KICAgICAgICA8dGQgd2lkdGg9Ijk3NCI+DQogICAgICAgICAgICANCiAg ICAgICAgICAgICAgICA8cD4mbmJzcDs8aW1nIHNyYz0iaHR0cDovL2l5ZXNjYXJkLmNvbS9p bWcvYm90dG9tNi5naWYiIHdpZHRoPSI2MjMiIGhlaWdodD0iMjExIiBib3JkZXI9IjAiPjwv cD4NCiAgICAgICAgICAgIDwvZm9ybT4NCiAgICAgICAgPC90ZD4NCiAgICA8L3RyPg0KICAg IDx0cj4NCiAgICAgICAgPHRkIHdpZHRoPSI5NzQiPg0KCQkNCgkJCTxmb3JtIG5hbWU9Im1h aWxmcm0xIiBhY3Rpb249Imh0dHA6Ly93d3cuaXllc2NhcmQuY29tL21haWwvaW5zZXJ0MS5h c3AiIG1ldGhvZD0icG9zdCIgb25zdWJtaXQ9InJldHVybiBzZW5kaXQoKTsiPg0KICAgICAg ICAgICAgJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7PGZvbnQgc2l6ZT0iMiIgY29sb3I9IiM2 NjY2NjYiPry6uO08L2ZvbnQ+PEZPTlQgc2l6ZT0yPiAgDQogICAgICAgICAgPC9GT05UPjxp bnB1dCB0eXBlPSJ0ZXh0IiBuYW1lPSJuYW1lIiBzaXplPSI2Ij4NCgkJICAmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDs8Zm9udCBzaXplPSIyIiBjb2xvcj0iIzY2NjY2NiI+wda5zrXut88g ufjIoyA8L2ZvbnQ+PGlucHV0IHR5cGU9InRleHQiIG5hbWU9Imp1bWluIiBzaXplPSIxNCIg bWF4bGVuZ3RoPSIxNCI+PGZvbnQgc2l6ZT0iMiIgZmFjZT0isby4siIgY29sb3I9IiM2NjY2 NjYiPigmcXVvdDstJnF1b3Q7wNS3wik8L2ZvbnQ+PGZvbnQgY29sb3I9IiM5OTk5OTkiPg0K ICAgICAgICAgIDwvZm9udD48YnI+ICZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOzxmb250IHNpemU9IjIiIGNvbG9yPSIjNjY2NjY2Ij7B98DlIMD8yK0gIA0K ICAgICAgICAgIDwvZm9udD48aW5wdXQgdHlwZT0idGV4dCIgbmFtZT0idGVsbnVtIiBzaXpl PSIxMyI+DQogICAgICAgICAgJm5ic3A7Jm5ic3A7Jm5ic3A7PGZvbnQgc2l6ZT0iMiIgY29s b3I9IiM2NjY2NjYiPsjetOvG+SA8L2ZvbnQ+PEZPTlQgc2l6ZT0yPjxpbnB1dCB0eXBlPSJ0 ZXh0IiBuYW1lPSJoYW5kbnVtIiBzaXplPSIxNSI+DQogICAgICAgICAgPC9GT05UPjxpbnB1 dCB0eXBlPSJzdWJtaXQiIG5hbWU9IlN1Ym1pdDIiIHZhbHVlPSK9xcO7Ij48L3A+DQogICAg ICAgICAgICAgICAgICAgICAgICA8L2Zvcm0+DQogICAgICAgIDwvdGQ+DQogICAgPC90cj4N CiAgICA8dHI+DQogICAgICAgIDx0ZCB3aWR0aD0iOTc0Ij48VEFCTEUgYm9yZGVyQ29sb3I9 d2hpdGUgY2VsbFNwYWNpbmc9MCANCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg Ym9yZGVyQ29sb3JEYXJrPXdoaXRlIGNlbGxQYWRkaW5nPTAgd2lkdGg9IjYyMSIgDQogICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgIGFsaWduPWNlbnRlciBib3JkZXJDb2xvckxp Z2h0PSMwMDY2OTkgYm9yZGVyPTE+DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg IDxUQk9EWT4NCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgPFRSPg0KICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICA8VEQgd2lkdGg9IjMyNCI+DQogICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgIDxQIGFsaWduPWxlZnQ+PEJSPjxJTUcgaGVpZ2h0PSI2 NiIgDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHNyYz0iaHR0cDovL2l5ZXNj YXJkLmNvbS9pbWcvY2FyZF9pbWdfMjAuZ2lmIiB3aWR0aD0iMTA1IiANCiAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgYWxpZ249bGVmdCBib3JkZXI9MD48SU1HIGhlaWdodD03 IA0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBzcmM9Imh0dHA6Ly9peWVzY2Fy ZC5jb20vaW1nL2J1XzAxLmdpZiIgd2lkdGg9NCANCiAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgYm9yZGVyPTA+IDxTUEFOIHN0eWxlPSJGT05ULVNJWkU6IDlwdCI+vcWx1CDI uL/4IL+syLi68SANCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAguOnBpjxCUj48 SU1HIGhlaWdodD03IA0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBzcmM9Imh0 dHA6Ly9peWVzY2FyZC5jb20vaW1nL2J1XzAxLmdpZiIgd2lkdGg9NCANCiAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgYm9yZGVyPTA+IMf2tOsgwNq1v8L3ILG4wNS9wyDG98DO xq4gx9LAziA8QlI+PElNRyBoZWlnaHQ9NyANCiAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgc3JjPSJodHRwOi8vaXllc2NhcmQuY29tL2ltZy9idV8wMS5naWYiIHdpZHRoPTQg DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIGJvcmRlcj0wPiCxubO7w9bDyiDB 1sCvILq4x+i5q7fhILChwNQ8QlI+PElNRyBoZWlnaHQ9NyANCiAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgc3JjPSJodHRwOi8vaXllc2NhcmQuY29tL2ltZy9idV8wMS5naWYi IHdpZHRoPTQgDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIGJvcmRlcj0wPiDB pLrxIMDatb/C9yC/68ewIMfSwM48L1NQQU4+PC9QPg0KICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICA8RElWIGFsaWduPWxlZnQ+DQogICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgIDxUQUJMRSBjZWxsU3BhY2luZz0wIGNlbGxQYWRkaW5nPTAgYm9yZGVyPTA+DQog ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIDxUQk9EWT4NCiAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgPFRSPg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICA8VEQgd2lkdGg9MTUyPg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICA8UD4m bmJzcDsmbmJzcDs8U1BBTiANCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgc3R5 bGU9IkZPTlQtU0laRTogOXB0Ij48Rk9OVCBjb2xvcj0jY2Q0NDMzPjxCPsf2tOsgDQogICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgIE0gxKu15TwvQj48L0ZPTlQ+PC9TUEFOPjwv UD48L1REPg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICA8VEQgd2lkdGg9MTUy Pg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICA8UCBhbGlnbj1sZWZ0PiAmbmJz cDs8L1A+PC9URD48L1RSPjwvVEJPRFk+PC9UQUJMRT48L0RJVj48L1REPg0KICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICA8VEQgd2lkdGg9IjI5MSI+DQogICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgIDxQIGFsaWduPWxlZnQ+PEJSPjxJTUcgaGVpZ2h0PSI2MyIg DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHNyYz0iaHR0cDovL2l5ZXNjYXJk LmNvbS9pbWcvY2FyZF9pbWdfMjEuZ2lmIiB3aWR0aD0iOTkiIA0KICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICBhbGlnbj1sZWZ0IGJvcmRlcj0wPjxJTUcgaGVpZ2h0PTcgDQog ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHNyYz0iaHR0cDovL2l5ZXNjYXJkLmNv bS9pbWcvYnVfMDEuZ2lmIiB3aWR0aD00IA0KICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICBib3JkZXI9MD4gPFNQQU4gc3R5bGU9IkZPTlQtU0laRTogOXB0Ij69xbHUIMi4v/gg v6zIuLrxIA0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICC46cGmPEJSPjxJTUcg aGVpZ2h0PTcgDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHNyYz0iaHR0cDov L2l5ZXNjYXJkLmNvbS9pbWcvYnVfMDEuZ2lmIiB3aWR0aD00IA0KICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICBib3JkZXI9MD4gseK+xiZuYnNwO8Datb/C9yCxuMDUvcMgxvfA zsauIMfSwM4gPEJSPjxJTUcgDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIGhl aWdodD03IHNyYz0iaHR0cDovL2l5ZXNjYXJkLmNvbS9pbWcvYnVfMDEuZ2lmIiB3aWR0aD00 IA0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBib3JkZXI9MD4gsbmzu8PWw8og wdbAryC6uMfouau34SCwocDUPEJSPjxJTUcgaGVpZ2h0PTcgDQogICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgIHNyYz0iaHR0cDovL2l5ZXNjYXJkLmNvbS9pbWcvYnVfMDEuZ2lm IiB3aWR0aD00IA0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBib3JkZXI9MD4g waS68SDA2rW/wvcgv+vHsCDH0sDOPC9TUEFOPjwvUD4NCiAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgPERJViBhbGlnbj1sZWZ0Pg0KICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICA8VEFCTEUgY2VsbFNwYWNpbmc9MCBjZWxsUGFkZGluZz0wIGJvcmRlcj0wPg0K ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICA8VEJPRFk+DQogICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgIDxUUj4NCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgPFREIHdpZHRoPTE0MT4NCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgPFAg YWxpZ249bGVmdD48U1BBTiANCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgc3R5 bGU9IkZPTlQtU0laRTogOXB0Ij48Rk9OVCBjb2xvcj0jY2Q0NDMzPjxCPiZuYnNwO7HivsYg DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgILPruu23ub26PC9CPjwvRk9OVD48 L1NQQU4+PC9QPjwvVEQ+DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIDxURCB3 aWR0aD0xNDE+DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIDxQIGFsaWduPWxl ZnQ+ICZuYnNwOzwvUD48L1REPjwvVFI+PC9UQk9EWT48L1RBQkxFPjwvRElWPjwvVEQ+PC9U Uj4NCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgPFRSPg0KICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICA8VEQgd2lkdGg9IjMyNCI+DQogICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgIDxQIGFsaWduPWxlZnQ+PEJSPjxJTUcgaGVpZ2h0PSI3MiIgDQog ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHNyYz0iaHR0cDovL2l5ZXNjYXJkLmNv bS9pbWcvcGFydG5lcjE1X2NhcmRfaW1nLmpwZyIgDQogICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgIHdpZHRoPSIxMTMiIGFsaWduPWxlZnQgYm9yZGVyPTA+PElNRyBoZWlnaHQ9 NyANCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgc3JjPSJodHRwOi8vaXllc2Nh cmQuY29tL2ltZy9idV8wMS5naWYiIHdpZHRoPTQgDQogICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgIGJvcmRlcj0wPiA8U1BBTiBzdHlsZT0iRk9OVC1TSVpFOiA5cHQiPsbyu/0m bmJzcDu/rMi4uvEguOnBpjxCUj48SU1HIA0KICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICBoZWlnaHQ9NyBzcmM9Imh0dHA6Ly9peWVzY2FyZC5jb20vaW1nL2J1XzAxLmdpZiIg d2lkdGg9NCANCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgYm9yZGVyPTA+IMb3 wM7GrrOzus4ssPiw+rHdIMSrteWw4cGmILytuvG9uiZuYnNwOzxCUj48SU1HIA0KICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICBoZWlnaHQ9NyBzcmM9Imh0dHA6Ly9peWVzY2Fy ZC5jb20vaW1nL2J1XzAxLmdpZiIgd2lkdGg9NCANCiAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgYm9yZGVyPTA+IMf2tOvBpMCvIKekILTnIDQwv/ggPEJSPjxJTUcgaGVpZ2h0 PTcgDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHNyYz0iaHR0cDovL2l5ZXNj YXJkLmNvbS9pbWcvYnVfMDEuZ2lmIiB3aWR0aD00IA0KICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICBib3JkZXI9MD4gv7XIrSC/ubjFIMDltOcgMiwwMDC/+CDH0sDOIDwvU1BB Tj48L1A+DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIDxESVYgYWxpZ249bGVm dD4NCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgPFRBQkxFIGNlbGxTcGFjaW5n PTAgY2VsbFBhZGRpbmc9MCBib3JkZXI9MD4NCiAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgPFRCT0RZPg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICA8VFI+DQog ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIDxURCB3aWR0aD0xNTIgaGVpZ2h0PTE3 Pg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICA8UD4mbmJzcDsmbmJzcDs8U1BB TiANCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgc3R5bGU9IkZPTlQtU0laRTog OXB0Ij48Rk9OVCBjb2xvcj0jY2Q0NDMzPjxCPktUIA0KICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICC69MfDtvPA2jwvQj48L0ZPTlQ+PC9TUEFOPjwvUD48L1REPg0KICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICA8VEQgd2lkdGg9MTUyIGhlaWdodD0xNz4NCiAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgPFAgYWxpZ249bGVmdD4gJm5ic3A7PC9Q PjwvVEQ+PC9UUj48L1RCT0RZPjwvVEFCTEU+PC9ESVY+PC9URD4NCiAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgPFREIHdpZHRoPSIyOTEiPg0KICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICA8UCBhbGlnbj1sZWZ0Pjxicj48SU1HIGhlaWdodD0iNjgiIA0KICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICBzcmM9Imh0dHA6Ly9peWVzY2FyZC5jb20v aW1nL2NhcmRfaW1nXzExLmdpZiIgd2lkdGg9IjEwNiIgDQogICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgIGFsaWduPWxlZnQgYm9yZGVyPTA+PElNRyBoZWlnaHQ9NyANCiAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgc3JjPSJodHRwOi8vaXllc2NhcmQuY29tL2lt Zy9idV8wMS5naWYiIHdpZHRoPTQgDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg IGJvcmRlcj0wPiA8U1BBTiBzdHlsZT0iRk9OVC1TSVpFOiA5cHQiPrvnv+vH0SAwLjUluKYg DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgILrSv+zAzL/0tb2x4jxCUj48SU1H IGhlaWdodD03IA0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBzcmM9Imh0dHA6 Ly9peWVzY2FyZC5jb20vaW1nL2J1XzAxLmdpZiIgd2lkdGg9NCANCiAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgYm9yZGVyPTA+IMbyu/0mbmJzcDu/rMi4uvEguOnBpiA8QlI+ PElNRyBoZWlnaHQ9NyANCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgc3JjPSJo dHRwOi8vaXllc2NhcmQuY29tL2ltZy9idV8wMS5naWYiIHdpZHRoPTQgDQogICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgIGJvcmRlcj0wPiCx3cC2vK268b26PEJSPjxJTUcgaGVp Z2h0PTcgDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHNyYz0iaHR0cDovL2l5 ZXNjYXJkLmNvbS9pbWcvYnVfMDEuZ2lmIiB3aWR0aD00IA0KICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICBib3JkZXI9MD4gNb7vILmrt+EgurjH6CA8YnI+PGJyPjxicj48L1NQ QU4+PC9QPg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICA8RElWIGFsaWduPWxl ZnQ+DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIDxUQUJMRSBjZWxsU3BhY2lu Zz0wIGNlbGxQYWRkaW5nPTAgYm9yZGVyPTA+DQogICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgIDxUQk9EWT4NCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgPFRSPg0K ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICA8VEQgd2lkdGg9MTQzPg0KICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICA8UCBhbGlnbj1sZWZ0PjxTUEFOIA0KICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICBzdHlsZT0iRk9OVC1TSVpFOiA5cHQiPjxGT05U IGNvbG9yPSNjZDQ0MzM+PEI+Jm5ic3A7u+e2+8DHIA0KICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICC81bDhxuyx4jwvQj48L0ZPTlQ+PC9TUEFOPjwvUD48L1REPg0KICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICA8VEQgd2lkdGg9MTQzPg0KICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICA8UCBhbGlnbj1sZWZ0PiAmbmJzcDs8L1A+PC9URD48L1RS PjwvVEJPRFk+PC9UQUJMRT48L0RJVj48L1REPjwvVFI+PC9UQk9EWT48L1RBQkxFPiAgICAg ICAgPC90ZD4NCiAgICA8L3RyPg0KICAgIDx0cj4NCiAgICAgICAgPHRkIHdpZHRoPSI5NzQi PjxwIGFsaWduPSJsZWZ0Ij48Zm9udCBzaXplPSIyIiBmYWNlPSKxvLiyIiBjb2xvcj0iIzY2 NjY2NiI+Jm5ic3A7sc3Hz8DHIA0KICAgICAgICAgICAguN7Az8HWvNK0wiDApbytx87AuyDF 68fYILz2wf3H0SCwzcDMuOcsILHXv9y/oSC+7rawx9EgwaS6uLW1ILCusO0gDQogICAgICAg ICAgICDA1sH2IL7KwL3AuyC54Mj8tM+02S48YnI+ICZuYnNwO8DMIEUtbWFpbMC6ILnfvcXA /L/rwMy45ywgv/jEoSC+ysC4vccgDQogICAgICAgICAgICCw5r/sIL7Gt6Egw6K/oSC43sDP wda80rimIMDUt8LHz7+pIMHWvcO46SC1ziC5+CC02b3DILjewM/AzCANCiAgICAgICAgICAg ILChwfYgJm5ic3A7vsq1tbfPIMfPsNq9wLTPtNkuPGJyPiAmbmJzcDsmbmJzcDs8YnI+ICZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOzwv Zm9udD48Rk9OVCBmYWNlPSKxvLiyIiBjb2xvcj0iIzY2NjY2NiIgc2l6ZT0yPrq7ILjewM/A uiDBpLq4xeu9xbrOILHHsO0gu+fH17+hIMDHsMUgwaa48b+hIA0KPC9GT05UPjxGT05UIGZh Y2U9IrG8uLIiIGNvbG9yPSJyZWQiIHNpemU9IjIiPluxpLDtXTwvRk9OVD48Rk9OVCBmYWNl PSKxvLiyIiBjb2xvcj0iIzY2NjY2NiIgc2l6ZT0yPrbzsO0gx6W9w7XIILGksO0guN7Az8DU tM+02S48L0ZPTlQ+PGZvbnQgY29sb3I9IiM2NjY2NjYiPjxCUj4gJm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7PC9m b250PjxhIGhyZWY9Imh0dHA6Ly9peWVzY2FyZC5jb20vcmVzZnVsLmh0bWwiPjxmb250IGNv bG9yPSIjNjY2NjY2Ij48aW1nIHNyYz0iaHR0cDovL2l5ZXNjYXJkLmNvbS9pbWcvYnV0dG9u XzMuZ2lmIiB3aWR0aD0iNzEiIGhlaWdodD0iMjUiIGJvcmRlcj0iMCI+PC9mb250PjwvYT48 Zm9udCBjb2xvcj0iIzY2NjY2NiI+IA0KICAgICAgICAgICAgPC9mb250PjxGT05UIGNvbG9y PSIjNjY2NjY2IiANCnNpemU9Mj659sawwLsgxay4r8fPvcO46SC89r3FsMW6zsOzuK6woSDA zLfnvu4gwf20z7TZLjwvRk9OVD48Zm9udCBjb2xvcj0iIzY2NjY2NiI+IDwvZm9udD48L3A+ DQogICAgICAgIDwvdGQ+DQogICAgPC90cj4NCiAgICA8dHI+DQogICAgICAgIDx0ZCB3aWR0 aD0iOTc0Ij4NCiAgICAgICAgICAgIDxwIGFsaWduPSJjZW50ZXIiPjxmb250IGNvbG9yPSIj NjY2NjY2Ij4mbmJzcDs8L2ZvbnQ+PEZPTlQgZmFjZT0isby4siIgY29sb3I9IiM2NjY2NjYi IHNpemU9Mj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDtJZiB5b3Ugd29uJ3QgcmVjZWl2ZSBh bnkgbW9yZSBtYWlsIGFib3V0IHRoaXMgDQpzaXRlLCA8L0ZPTlQ+PGZvbnQgY29sb3I9IiM2 NjY2NjYiPjxCUj4gJm5ic3A7Jm5ic3A7PC9mb250PjxhIGhyZWY9Imh0dHA6Ly9peWVzY2Fy ZC5jb20vcmVzZnVsLmh0bWwiPjxmb250IGNvbG9yPSIjNjY2NjY2Ij48aW1nIHNyYz0iaHR0 cDovL2l5ZXNjYXJkLmNvbS9pbWcvYnV0dG9uXzQuZ2lmIiB3aWR0aD0iNzEiIGhlaWdodD0i MjUiIGJvcmRlcj0iMCI+PC9mb250PjwvYT48Rk9OVCBjb2xvcj0iIzY2NjY2NiIgDQpzaXpl PTI+cHJlc3MgYnV0dG9uIGFuZCBmaWxsIHlvdXIgZS1tYWlsIGFkZHJlc3MuIEFuZCB0aGVu IHdlIHdpbGwgbm90IHNlbmQgYW55IA0KbWFpbCB0byB5b3U8L0ZPTlQ+PC9wPg0KICAgICAg ICA8L3RkPg0KICAgIDwvdHI+DQogICAgPHRyPg0KICAgICAgICA8dGQgd2lkdGg9Ijk3NCIg Ymdjb2xvcj0iIzhCQjVFMiI+DQo8dGFibGUgYWxpZ249ImNlbnRlciIgYm9yZGVyPSIxIiBj ZWxsc3BhY2luZz0iMCIgd2lkdGg9IjYzMiIgYm9yZGVyY29sb3JkYXJrPSJ3aGl0ZSIgYm9y ZGVyY29sb3JsaWdodD0iYmxhY2siIGJnY29sb3I9IndoaXRlIj4NCiAgICA8dHI+DQogICAg ICAgIDx0ZCB3aWR0aD0iNjI2IiBiZ2NvbG9yPSJ3aGl0ZSI+DQogICAgICAgICAgICA8dGFi bGUgY2VsbHBhZGRpbmc9IjAiIGNlbGxzcGFjaW5nPSIwIiB3aWR0aD0iNjMyIj4NCiAgICAg ICAgICAgICAgICA8dHI+DQogICAgICAgICAgICAgICAgICAgIDx0ZCB3aWR0aD0iMTI2IiBo ZWlnaHQ9IjUyIiByb3dzcGFuPSIzIj4NCiAgICAgICAgICAgICAgICAgICAgICAgIDxwPjxp bWcgc3JjPSJodHRwOi8vd2VtZXMuY29tL2ltYWdlL8f2tOu3zrDtLmdpZiIgd2lkdGg9IjE5 NyIgaGVpZ2h0PSI0NyIgYm9yZGVyPSIwIj48L3A+DQogICAgICAgICAgICAgICAgICAgIDwv dGQ+DQogICAgICAgICAgICAgICAgICAgIDx0ZCB3aWR0aD0iNDkwIiBoZWlnaHQ9IjEzIj4N CiAgICAgICAgICAgICAgICAgICAgICAgIDxwPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOzxpbWcgc3JjPSJodHRwOi8vd2VtZXMuY29tL2ltYWdlL21haWwxLmdpZiIg d2lkdGg9IjM0MCIgaGVpZ2h0PSIxMiIgYm9yZGVyPSIwIj48L3A+DQogICAgICAgICAgICAg ICAgICAgIDwvdGQ+DQogICAgICAgICAgICAgICAgPC90cj4NCiAgICAgICAgICAgICAgICA8 dHI+DQogICAgICAgICAgICAgICAgICAgIDx0ZCB3aWR0aD0iNDkwIiBoZWlnaHQ9IjE1Ij4N CiAgICAgICAgICAgICAgICAgICAgICAgIDxwPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOzxpbWcgc3Jj PSJodHRwOi8vd2VtZXMuY29tL2ltYWdlL7+stvTDszEuZ2lmIiB3aWR0aD0iMTMzIiBoZWln aHQ9IjEyIiBib3JkZXI9IjAiPjxhIGhyZWY9Im1haWx0bzplbmV4dG9wQGx5Y29zLmNvLmty Ij48Zm9udCBjb2xvcj0iIzg4ODY4NiIgc2l6ZT0iMiIgZmFjZT0isby4siI+ZW5leHRvcEBs eWNvcy5jby5rcjwvZm9udD48L2E+PC9wPg0KICAgICAgICAgICAgICAgICAgICA8L3RkPg0K ICAgICAgICAgICAgICAgIDwvdHI+DQogICAgICAgICAgICAgICAgPHRyPg0KICAgICAgICAg ICAgICAgICAgICA8dGQgd2lkdGg9IjQ5MCIgaGVpZ2h0PSIxNiI+DQogICAgICAgICAgICAg ICAgICAgICAgICA8cD4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDs8aW1nIHNyYz0iaHR0cDovL3dlbWVzLmNvbS9pbWFnZS9jb3B5cmln aHQuZ2lmIiB3aWR0aD0iMzQwIiBoZWlnaHQ9IjEyIiBib3JkZXI9IjAiPjwvcD4NCiAgICAg ICAgICAgICAgICAgICAgPC90ZD4NCiAgICAgICAgICAgICAgICA8L3RyPg0KICAgICAgICAg ICAgPC90YWJsZT4NCiAgICAgICAgPC90ZD4NCiAgICA8L3RyPg0KPC90YWJsZT4NCiAgICAg ICAgPC90ZD4NCiAgICA8L3RyPg0KPC90YWJsZT4NCjxwPiZuYnNwOzwvcD4NCjwvYm9keT4N Cg0KPC9odG1sPg0K ------=_NextPart_000_0037_01C0F07A.93A14C00-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-fs" in the body of the message From owner-freebsd-fs Sat Aug 31 21: 9:34 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 A57C637B400; Sat, 31 Aug 2002 21:09:22 -0700 (PDT) Received: from lycos.com (YahooBB218118160005.bbtec.net [218.118.160.5]) by mx1.FreeBSD.org (Postfix) with SMTP id BF27243E4A; Sat, 31 Aug 2002 21:09:16 -0700 (PDT) (envelope-from barry_abdul@lycos.com) Received: from unknown (199.130.169.148) by rly-xr01.mx.aol.com with asmtp; 01 Sep 2002 03:09:10 +0100 Reply-To: Message-ID: <001a84e73ebd$8224a1b0$0ec67da0@iexsfx> From: To: Cc: , , , , , Subject: why pay $35.00 when you can get better service for $14.95 MiME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 Importance: Normal Date: Sat, 31 Aug 2002 21:09:16 -0700 (PDT) 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 LATEST NEWS: The new domain names are finally available to the general public at discount prices. Now you can register one of the exciting new .BIZ or .INFO domain names, as well as the original .COM and .NET names for just $14.95. These brand new domain extensions were recently approved by ICANN and have the same rights as the original .COM and .NET domain names. The biggest benefit is of-course that the .BIZ and .INFO domain names are currently more available. i.e. it will be much easier to register an attractive and easy-to-remember domain name for the same price. Visit: http://www.affordable-domains.com today for more info. Register your domain name today for just $14.95 at: http://www.affordable-domains.com/ Registration fees include full access to an easy-to-use control panel to manage your domain name in the future. Sincerely, Domain Administrator Affordable Domains To remove your email address from further promotional mailings from this company, click here: http://www.centralremovalservice.com/cgi-bin/domain-remove.cgi (e3)2546mEwQ5-744iAuM8195fXrJ4-346bVnF0707zRjD3-856vNfA9207sKbV8-757nFzR3106jDvN7-@73 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-fs" in the body of the message