From owner-freebsd-fs Sun Apr 2 1: 1:53 2000 Delivered-To: freebsd-fs@freebsd.org Received: from mail.du.gtn.com (mail.du.gtn.com [194.77.9.57]) by hub.freebsd.org (Postfix) with ESMTP id DB9C337B51A for ; Sun, 2 Apr 2000 01:01:49 -0800 (PST) (envelope-from ticso@cicely8.cicely.de) Received: from mail.cicely.de (cicely.de [194.231.9.142]) by mail.du.gtn.com (8.9.3/8.9.3) with ESMTP id LAA27041; Sun, 2 Apr 2000 11:00:15 +0200 (MET DST) Received: from cicely8.cicely.de (cicely8.cicely.de [10.1.2.10]) by mail.cicely.de (8.9.3/8.9.0) with ESMTP id LAA29119; Sun, 2 Apr 2000 11:01:15 +0200 (CEST) Received: (from ticso@localhost) by cicely8.cicely.de (8.9.3/8.9.2) id LAA24926; Sun, 2 Apr 2000 11:02:18 +0200 (CEST) (envelope-from ticso) Date: Sun, 2 Apr 2000 11:02:17 +0200 From: Bernd Walter To: vova@express.ru Cc: Bernd Walter , freebsd-fs@FreeBSD.ORG Subject: Re: SCSI bus Message-ID: <20000402110216.A24876@cicely8.cicely.de> References: <20000331215756.A19890@cicely8.cicely.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0.1i In-Reply-To: ; from vova@express.ru on Sat, Apr 01, 2000 at 12:01:36AM +0400 Sender: owner-freebsd-fs@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Sat, Apr 01, 2000 at 12:01:36AM +0400, vova@express.ru wrote: > On Fri, 31 Mar 2000, Bernd Walter wrote: > > > > I have question about two SCSI controllers on one SCSI bus, > > > > > > I want to run following configuration: one FreeBSD with SCSI controler, > > > with mounted disks in read/write mode, and another FreeBSD with SCSI > > > controller on the same bus with mounted disks in read-only mode. > > > > > > So can two controllers correctly handle SCSI bus with FreeBSD drivers ? > > > (I mean aic78* controllers) > > > > I don't expect this to work because the readonly side can't know when the > > incore informations outdates. > > Yes, it can be a problem, but may be this may be solved by disabling any > cache on read-only side (or setting expire time in one sec) ? You can't diable readcaching completely. Say you need the inode, then you will read it and finaly use it. You don't reread it for every single byte you access which creates some kind of read cache. And there are much more complex points like this sample. -- B.Walter COSMO-Project http://www.cosmo-project.de ticso@cicely.de Usergroup info@cosmo-project.de To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-fs" in the body of the message From owner-freebsd-fs Sun Apr 2 4:43:18 2000 Delivered-To: freebsd-fs@freebsd.org Received: from lanturn.express.ru (lanturn.kmost.express.ru [212.24.37.109]) by hub.freebsd.org (Postfix) with ESMTP id C3B2D37BABF for ; Sun, 2 Apr 2000 04:43:02 -0700 (PDT) (envelope-from vova@express.ru) Received: from vova (helo=localhost) by lanturn.express.ru with local-esmtp (Exim 3.11 #1) id 12bihm-0006SB-00; Sun, 02 Apr 2000 15:38:10 +0400 Date: Sun, 2 Apr 2000 15:38:10 +0400 (MSD) From: vova@express.ru X-Sender: vova@lanturn.kmost.express.ru To: Bernd Walter Cc: freebsd-fs@FreeBSD.ORG Subject: Re: SCSI bus In-Reply-To: <20000402110216.A24876@cicely8.cicely.de> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-fs@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Sun, 2 Apr 2000, Bernd Walter wrote: > > > I don't expect this to work because the readonly side can't know when the > > > incore informations outdates. > > > > Yes, it can be a problem, but may be this may be solved by disabling any > > cache on read-only side (or setting expire time in one sec) ? > > You can't diable readcaching completely. > Say you need the inode, then you will read it and finaly use it. > You don't reread it for every single byte you access which creates some kind of > read cache. And there are much more complex points like this sample. Ok, have kernel algorithm to "expire" cached vnodes ? Or vnodes only pushed out by new pages ? In my case writes - relative rare case then reads and I can wait for some timeout while my in-kernel vnodes will dropped to see new from disk > -- > B.Walter COSMO-Project http://www.cosmo-project.de > ticso@cicely.de Usergroup info@cosmo-project.de -- TSB Russian Express, Moscow Vladimir B. Grebenschikov, vova@express.ru To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-fs" in the body of the message From owner-freebsd-fs Sun Apr 2 6:53:54 2000 Delivered-To: freebsd-fs@freebsd.org Received: from ewok.creative.net.au (ewok.creative.net.au [203.30.44.41]) by hub.freebsd.org (Postfix) with SMTP id 7832537B99A for ; Sun, 2 Apr 2000 06:53:48 -0700 (PDT) (envelope-from freebsd@ewok.creative.net.au) Received: (qmail 52804 invoked by uid 1008); 2 Apr 2000 13:53:24 -0000 Date: Sun, 2 Apr 2000 21:53:24 +0800 From: Adrian Chadd To: vova@express.ru Cc: Bernd Walter , freebsd-fs@FreeBSD.ORG Subject: Re: SCSI bus Message-ID: <20000402215318.E21291@ewok.creative.net.au> References: <20000402110216.A24876@cicely8.cicely.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95.4i In-Reply-To: ; from vova@express.ru on Sun, Apr 02, 2000 at 03:38:10PM +0400 Sender: owner-freebsd-fs@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Sun, Apr 02, 2000, vova@express.ru wrote: > On Sun, 2 Apr 2000, Bernd Walter wrote: > > > > > I don't expect this to work because the readonly side can't know when the > > > > incore informations outdates. > > > > > > Yes, it can be a problem, but may be this may be solved by disabling any > > > cache on read-only side (or setting expire time in one sec) ? > > > > You can't diable readcaching completely. > > Say you need the inode, then you will read it and finaly use it. > > You don't reread it for every single byte you access which creates some kind of > > read cache. And there are much more complex points like this sample. > > Ok, have kernel algorithm to "expire" cached vnodes ? Or vnodes only > pushed out by new pages ? > > In my case writes - relative rare case then reads and I can wait for some > timeout while my in-kernel vnodes will dropped to see new from disk Think from a metadata point of view - if you're half way through updating a directory on a write, and you try reading that directory, you are going to get very weird results. You'd need to have a filesystem that supports this kind of access at the very outside. FFS wasn't designed for this. Adrian To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-fs" in the body of the message From owner-freebsd-fs Tue Apr 4 8:15:59 2000 Delivered-To: freebsd-fs@freebsd.org Received: from smtp05.primenet.com (smtp05.primenet.com [206.165.6.135]) by hub.freebsd.org (Postfix) with ESMTP id 9F7C337B67A for ; Tue, 4 Apr 2000 08:15:50 -0700 (PDT) (envelope-from tlambert@usr06.primenet.com) Received: (from daemon@localhost) by smtp05.primenet.com (8.9.3/8.9.3) id IAA27807; Tue, 4 Apr 2000 08:15:24 -0700 (MST) Received: from usr06.primenet.com(206.165.6.206) via SMTP by smtp05.primenet.com, id smtpdAAA7HaGo2; Tue Apr 4 08:15:16 2000 Received: (from tlambert@localhost) by usr06.primenet.com (8.8.5/8.8.5) id IAA08886; Tue, 4 Apr 2000 08:15:30 -0700 (MST) From: Terry Lambert Message-Id: <200004041515.IAA08886@usr06.primenet.com> Subject: Re: SCSI bus To: vova@express.ru Date: Tue, 4 Apr 2000 15:15:29 +0000 (GMT) Cc: ticso@cicely.de (Bernd Walter), freebsd-fs@FreeBSD.ORG In-Reply-To: from "vova@express.ru" at Apr 02, 2000 03:38:10 PM X-Mailer: ELM [version 2.5 PL2] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-fs@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > > > > I don't expect this to work because the readonly side > > > > can't know when the incore informations outdates. > > > > > > Yes, it can be a problem, but may be this may be solved by > > > disabling any cache on read-only side (or setting expire > > > time in one sec) ? > > > > You can't diable readcaching completely. > > Say you need the inode, then you will read it and finaly use it. > > You don't reread it for every single byte you access which > > creates some kind of read cache. And there are much more > > complex points like this sample. > > Ok, have kernel algorithm to "expire" cached vnodes ? Or vnodes only > pushed out by new pages ? > > In my case writes - relative rare case then reads and I can wait for some > timeout while my in-kernel vnodes will dropped to see new from disk There is a general problem here. It stems from the ability to disassociate the ihash cache from the vnode cache; this is a direct result of the operating system, not the file system, owning the vnodes in question. Fixing this is complex. It requires coupling the pool retention times on all file systems, such that the OS can ask the file systems to flush cached data in low resource situations. Is this worth it? In general, "yes, a little", and in specific cases, "yes, a lot". The "yes, a little" case is the locality of reference case for freed vnodes with cached clean data, which have not been reclaimed. This is, in effect, any clean vnode from which the ihash entry has been divorced. Even though the data is available in core without going to disk, you must go to disk to reread the data, because the association between the inode and vnode can not be recovered. In effect, this is the difference between a "write through" and a "write back" cache: the "write back" cache has significantly better associativity, and therefore significantly better performance. The specific "yes, a lot" case is another associativity case, and in particular, comes into play when the machine is being used as a file server for Windows machines (SAMBA, etc.). You can get a 35% increase in speed for directory and file name manipulation operations out of SAMBA very quickly. A peculiar property of jamming the file operations into the DOS interface is that the DOS file system has historically been pased on "FAT", or "file allocation tables". This is well known, but the net opshot of this architecture is often ignored: in this architecture, the directory entry _is_ the inode. This is very un-UNIX-like. The main impact this has on file operations is that any BIOS or even protected mode directory lookup operation, including file opens, will return stat information. In UNIX, this requires that the SMB (or NCP, etc.) file server running as a hosted OS perform two operations: the requested operation, and an additional "stat" operation to get the rest of the data which, while it may not be used by the client, it might be, and there is no way to tell, so it must be returned. Throwing aside performance increases available by providing a seperate system call interface that mimics the interface that is expected to be implemented by the file system by these clients (all operations return stat information, thus saving 50% of all system calls, and globbing in the kernel, which would allow pushing back only data that was relevent to the client request across the user/kernel protection domain boundary), there is still a significant win to be had. Prefault the vnodes when iterating directory entries, opening files, or performing other operations. This technique realizes an immediate performance boost for SAMBA and other file server software that services Windows clients. There are a couple of problems with this approach. Performance on most normal UNIX applications is reduced. Without kernel globbing, you will fault a lot of vnodes that don't need faulting, because they are not relevent to the client. But the first can be addressed by making it a flag on the process; the easiest way to do this is to have the process open its own /proc entry, and set the flag on itself, and have the prefault occur in the FS when this falg is set. The second wants another API (which is just as well; if we define that a directory is not a file, then we can ignore the atime update requirements of POSIX, since they only apply to the POSIX defined getdents(2) interface -- getdirentries(2), for BSD-land). The operating system ownership of vnodes damages the utility of these techniques, but not enough to make them not useful. On the other hand, an operating system where the file system owns its vnodes, and where there are provisions for kernel globbing and call collapse (putting the stat in with the open and directory and file name manipulation code), etc., will be able to achieve much better performance than an operating system without these capabilities (such as the current FreeBSD). UnixWare has some of these capabilities built in; that's to be expected, since they were invented by myself, Ed Lane, Dan Fritch, Dan Grice, and others at Novell in the early 1990's. They are among the reasons that NetWare for UNIX, written in C and running on UnixWare, outperformed Native NetWare, written in assembly, and running on the bare silicon, when run on identical Intel hardware. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-fs" in the body of the message From owner-freebsd-fs Tue Apr 4 15: 3:15 2000 Delivered-To: freebsd-fs@freebsd.org Received: from fLuFFy.iNt.tElE.dK (fw1.inet.tele.dk [193.163.158.4]) by hub.freebsd.org (Postfix) with ESMTP id 3CBF037B961; Tue, 4 Apr 2000 15:03:06 -0700 (PDT) (envelope-from kvindeservice@netscum.dk) Received: from localhost (kvindeservice@localhost) by fLuFFy.iNt.tElE.dK (8.9.3/8.9.3) with SMTP id AAA07668; Wed, 5 Apr 2000 00:02:49 +0200 (CEST) (envelope-from kvindeservice@netscum.dk) X-Authentication-Warning: fLuFFy.iNt.tElE.dK: kvindeservice owned process doing -bs Date: Wed, 5 Apr 2000 00:02:49 +0200 (CEST) From: tele danmarQ kvindeservice X-Sender: kvindeservice@fLuFFy.iNt.tElE.dK Reply-To: freebsd-guinea-pigs@netscum.dk To: Matthew Dillon Cc: current@FreeBSD.ORG, fs@FreeBSD.ORG Subject: Re: FreeBSD random I/O performance issues In-Reply-To: Message-ID: Organization: Department of Weird so-called Music and Stuff X-Pedophile: BARRY BOUWSMA HAS A PEDO FILE MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-fs@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Thu, 23 Mar 19100 (not like I'm slow or anything), Matthew Dillon wrote: [regarding random-access database files, such as are used for the INN history files, and FreeBSD 4.0...] > For INN there are several things you can tune in 4.0. First and > foremost you can try turning off the write-behind code, > sysctl -w vfs.write_behind=0. Secondly you can mess around with > the vfs.hidirtybuffers sysctl (generally lower it) in order to > force out dirty pages earlier and thus reduce the number that > fsync has to deal with. Thanks for the tips. A few days ago, I rebuilt one of my transit peering boxen to use the 4.0-RELENG k0deZ and then proceeded to tune the above, after letting it run for a while to get a feel for how it was acting, as well as to let accumulated backlogs clear out. Now, the history file I'm dealing with contains some 14 million entries, so there's about 200 megabytes of goods to be scribbled over the disks (or at least the pages for some 12-18 entries per second over the 30- second intervals). It's just a single disk, so it takes a while to dump the data, and much more so when taking in backlogs at several dozen message IDs per second (limited mostly by the time blocked waiting for the disk writes to complete). After first firing things up, it almost seemed to be taking anywhere from 25 to 55 seconds to dump to the disks every so often, with an available cycle time of perhaps 10 to 15%. After a bit of time, as the backlogs were cleared out, things seemed to settle down to somewhere around 15 seconds blocked, plus or minus a bit, followed by around 25 seconds of activity. Toggling the sysctl knob and tweaking the limits might have trimmed a couple seconds from the unresponsive times, although it's difficult to say just what was an improvement, and what was due to natural fluctuation in the flow of incoming news. It was nothing to write home about. So, while I did tune things, the results weren't quite what I hoped for. > I believe that INN also messes around with > shared/R+W mmap()'s - it may be possible to add MAP_NOSYNC to those > maps to turn off the 30 second fsync on pages dirtied through the VM > system (for those maps), though this may increase the amount of stale > (unwritten) data after a crash. If this is the MMAP_SYNC in the (INN 1.5) config.data file, this is set to `DONT' on these boxes. I have noticed that our 2.2-RELENG box, which had the time between sync disk dumps tweaked up to an hour, always seemed to sync the disks when it would crash (except when the truck delivering a new UPS ran into the electric pole), and as long as the text file (only appended to) is in a consistent state, one can recreate the database files, so the risk of losing data hasn't concerned me too much. Now, I did notice with great joy that you committed some k0deZ a few days ago that might help this problem, and as soon as I unearth that announcement, I'll followup to that and describe the results on our history database files. thanks, barry (not a fluffy, oh no) bouwsma, teledanmorkinternet -- *** This was posted with the express permission of *** ****************************************************** ** HIS HIGHNESS KAAZMANN LORD AND MASTER OF USENET ** ****************************************************** ********* We are simple servants of his will ********* To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-fs" in the body of the message From owner-freebsd-fs Tue Apr 4 18:29: 0 2000 Delivered-To: freebsd-fs@freebsd.org Received: from fLuFFy.iNt.tElE.dK (fw1.inet.tele.dk [193.163.158.4]) by hub.freebsd.org (Postfix) with ESMTP id BE76F37B9C3; Tue, 4 Apr 2000 18:28:50 -0700 (PDT) (envelope-from freebeer@fluffy.gets.an.analprobe.dk) Received: from localhost (freebeer@localhost) by fLuFFy.iNt.tElE.dK (8.9.3/8.9.3) with SMTP id DAA07903; Wed, 5 Apr 2000 03:28:45 +0200 (CEST) (envelope-from freebeer@fluffy.gets.an.analprobe.dk) X-Authentication-Warning: fLuFFy.iNt.tElE.dK: freebeer owned process doing -bs Date: Wed, 5 Apr 2000 03:28:45 +0200 (CEST) From: Kun Limfjordsporter X-Sender: freebeer@fLuFFy.iNt.tElE.dK Reply-To: FreeBSD-guineapigs@netscum.dk To: Matthew Dillon Cc: current@FreeBSD.ORG, fs@FreeBSD.ORG Subject: Re: FreeBSD random I/O performance issues In-Reply-To: Message-ID: Organization: Freenix is STILL OVERRATED X-Pedophile: Yes MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-fs@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Sun, 2406 Sep 1993, Matthew Dillon wrote: > I've committed an 80% fix for the random seek / write > performance issue. The rest of the fix will come later > when Kirk commits his shared-lock-buffer-cache idea. > > I've committed it into -current and will MFC it into > -stable in a week if there aren't any problems. I Woo. Okay, so I took the bait and snarfed the k0deZ from midday GMT 02.April, and have built a suitable SMP kernel and world, and that's what I've been running for one news peering swerver for a spell. > This should solve most of the random-I/O latency issues > with read-after-write on buffers. Basically what > had to be done was to continue to call the clustering > code as before (so reallocblks still gets called), but > only issue write_behind I/O if the writes are > generally sequential. If the writes are random, even > big writes, we do not issue write-behind I/O. As I noted in the earlier message I just sent, disabling the write- behind via the sysctl knob didn't make an outstanding difference in performance -- innd was still unresponsive during the time that the random history database files needed updating for somewhere around 10 to 15 seconds when handling a full feed. Unfortunately, as I was hoping these latest hacks would fix the read/write locking, it looks like I'll have to wait for the remaining 20% of the fix, since I still see innd blocking during the time the light on the drive with history is lit. I did notice earlier with 4.0-STABLE that I had not enabled softupdates on the /news disk (with the history files), so I enabled it and tried looking at numbers again. There was no improvement -- if anything, it almost seemed like the time that INN was spending in history-related activity (writing or lookups) increased somewhat. I don't see any problems with the latest code changes (of 2 1/2 days ago), as the machine has been running without problems for more than a day now. I just don't see the improvement I am hoping for. This machine isn't taking a full feed, but 2/3 of one, and it spends on the order of 6 seconds blocked with disk activity every 30 secs. I'm not quite sure, but it also seems like any access to this disk (such as `ls -l /news') is blocked during the time the history files on the disk are being updated -- similarly a seek with `less' within /news/log/news.notice. `expire' also causes things to grind to a crawl -- even when `nice'd, the incoming article rate drops to about one third of normal. I won't say there's no improvement, since it's hard to tell with the variable flow of news, but so far I don't see the improvement that is needed for me to be able to keep up with a full incoming news feed, which I do see on the companion box using NetBSD and trickle sync, where the time INN spends on history file access drops to just over a second out of every 5 minutes, compared with more than 100 seconds using the current FreeBSD k0deZ. More importantly, I haven't seen any problems with it yet, and I'm eagerly looking forward to the best 20% of the fix to come... (I haven't tried tweaking any sysctl knobs to see if they make any difference, this is pretty much a standard installation with the same old INN k0deZ as on the other test machines) barry bouwsma, newsmangler & netscum -- *** This was posted with the express permission of *** ****************************************************** ** HIS HIGHNESS KAAZMANN LORD AND MASTER OF USENET ** ****************************************************** ********* We are simple servants of his will ********* To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-fs" in the body of the message From owner-freebsd-fs Tue Apr 4 19:20: 2 2000 Delivered-To: freebsd-fs@freebsd.org Received: from apollo.backplane.com (apollo.backplane.com [216.240.41.2]) by hub.freebsd.org (Postfix) with ESMTP id BB0BC37B8D1; Tue, 4 Apr 2000 19:19:56 -0700 (PDT) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.9.3/8.9.1) id TAA72439; Tue, 4 Apr 2000 19:19:00 -0700 (PDT) (envelope-from dillon) Date: Tue, 4 Apr 2000 19:19:00 -0700 (PDT) From: Matthew Dillon Message-Id: <200004050219.TAA72439@apollo.backplane.com> To: Kun Limfjordsporter Cc: current@FreeBSD.ORG, fs@FreeBSD.ORG Subject: Re: FreeBSD random I/O performance issues References: Sender: owner-freebsd-fs@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org :Woo. Okay, so I took the bait and snarfed the k0deZ from midday GMT :02.April, and have built a suitable SMP kernel and world, and that's :what I've been running for one news peering swerver for a spell. : :... : :As I noted in the earlier message I just sent, disabling the write- :behind via the sysctl knob didn't make an outstanding difference in :performance -- innd was still unresponsive during the time that the :random history database files needed updating for somewhere around :10 to 15 seconds when handling a full feed. I would have been very surprised if these changes made innd work better :-) These changes fix a case that innd does not usually generate. Even though innd's history files are hash-based, they are large enough that I would not expect one to typically hit the read-after-write case that the commit fixed. The innd problem is a different issue entirely, one related either to dirtying pages via mmap() or to excessive dirty pages in the buffer cache. You might be able to mitigate the problem somewhat by lowering the 'vfs.hidirtybuffers' sysctl, or maybe not. :I don't see any problems with the latest code changes (of 2 1/2 days :ago), as the machine has been running without problems for more than :a day now. I just don't see the improvement I am hoping for. This :machine isn't taking a full feed, but 2/3 of one, and it spends :on the order of 6 seconds blocked with disk activity every 30 secs. That's good. I didn't expect any problems with the write-behind fixes, they are fairly trivial. :I'm not quite sure, but it also seems like any access to this disk :(such as `ls -l /news') is blocked during the time the history files :on the disk are being updated -- similarly a seek with `less' within This is a different issue -- this is an issue of the disk write queues getting too long and/or the buffer cache getting starved and blocking other I/O while draining. :variable flow of news, but so far I don't see the improvement that :is needed for me to be able to keep up with a full incoming news :feed, which I do see on the companion box using NetBSD and trickle :sync, where the time INN spends on history file access drops to just :over a second out of every 5 minutes, compared with more than 100 :seconds using the current FreeBSD k0deZ. :... : :barry bouwsma, newsmangler & netscum -Matt Matthew Dillon To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-fs" in the body of the message From owner-freebsd-fs Tue Apr 4 22:24:26 2000 Delivered-To: freebsd-fs@freebsd.org Received: from fLuFFy.iNt.tElE.dK (fw1.inet.tele.dk [193.163.158.4]) by hub.freebsd.org (Postfix) with ESMTP id E955D37BD56; Tue, 4 Apr 2000 22:24:17 -0700 (PDT) (envelope-from freebeer@fluffy.gets.an.analprobe.dk) Received: from localhost (freebeer@localhost) by fLuFFy.iNt.tElE.dK (8.9.3/8.9.3) with SMTP id HAA08200; Wed, 5 Apr 2000 07:24:08 +0200 (CEST) (envelope-from freebeer@fluffy.gets.an.analprobe.dk) X-Authentication-Warning: fLuFFy.iNt.tElE.dK: freebeer owned process doing -bs Date: Wed, 5 Apr 2000 07:24:08 +0200 (CEST) From: Kun Limfjordsporter X-Sender: freebeer@fLuFFy.iNt.tElE.dK Reply-To: FreeBSD-manglers@netscum.dk To: Matthew Dillon Cc: current@FreeBSD.ORG, fs@FreeBSD.ORG Subject: Re: FreeBSD random I/O performance issues In-Reply-To: Message-ID: Organization: Department of Superfluous Headers MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-fs@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Wed, 5 Apr 19100, Matthew Dillon wrote: > :performance -- innd was still unresponsive during the time that the > :random history database files needed updating for somewhere around > :10 to 15 seconds when handling a full feed. > > The innd problem is a different issue entirely, one related > either to dirtying pages via mmap() or to excessive dirty > pages in the buffer cache. > > You might be able to mitigate the problem somewhat by lowering > the 'vfs.hidirtybuffers' sysctl, or maybe not. I'll take door number two, please! Just for grins, I went ahead with 5.0 and tuned the hidirtybuffers down from the default of 1410 in steps down to 400, and nope, I still see the ~6 seconds of freeze that I saw with the higher value. No improvement. No consolation prize. > :I don't see any problems with the latest code changes (of 2 1/2 days > :ago), as the machine has been running without problems for more than > > That's good. I didn't expect any problems with the > write-behind fixes, they are fairly trivial. Now about this ahc0 RECOVERED ERROR that just showed up, I guess it will be time to toss another Sun disk out the window Real Soon Now. Anyway, I'll be looking forward to see what effect the rest of the fix has on things, in hopes of matching either the NetBSD or Slowaris performance but without the problems of either, please, thankyoumuch thanks agin from the fluffy your mother should have warned you about -- *** This was posted with the express permission of *** ****************************************************** ** HIS HIGHNESS KAAZMANN LORD AND MASTER OF USENET ** ****************************************************** ********* We are simple servants of his will ********* To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-fs" in the body of the message From owner-freebsd-fs Fri Apr 7 16:11: 9 2000 Delivered-To: freebsd-fs@freebsd.org Received: from mail.webmonster.de (datasink.webmonster.de [194.162.162.209]) by hub.freebsd.org (Postfix) with SMTP id 16ED437C259 for ; Fri, 7 Apr 2000 16:11:00 -0700 (PDT) (envelope-from karsten@rohrbach.de) Received: (qmail 91812 invoked by uid 1000); 7 Apr 2000 23:10:54 -0000 Date: Sat, 8 Apr 2000 01:10:54 +0200 From: "Karsten W. Rohrbach" To: freebsd-fs@freebsd.org Subject: GlobalFileSystem!? Message-ID: <20000408011053.A90134@rohrbach.de> Reply-To: karsten@rohrbach.de Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0i X-Arbitrary-Number-Of-The-Day: 42 X-Sender: karsten@rohrbach.de Sender: owner-freebsd-fs@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org first of all, there's a nicely written how-to - attach multiple devices to multiple busses (fcal/scsi) - have more hosts adress/access these devices they also appear to have some very interesting links to other information, for example limited locking support on scsi-s/fcal devices they seem to build support for journaling and all the funky things... source is available for linux and irix, that's pretty it. they also got firmware for fcal drives there... i am definately not an integration/migration/porting guru, so the questions are: - would this be possible to adopt in -current? - who can do it? (who's the guy with the big head?) - who will do it? (who's the guy with the big balls?) - how far do the vfs stacks of freebsd and linux or irix differ? afaik, irix has a lot of vm intergration with their fs layer, freebsd also /k -- > Hackers do it with fewer instructions. http://www.webmonster.de http://www.apache.de http://www.splatterworld.de (NIC-HDL KR433/KR11-RIPE) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-fs" in the body of the message From owner-freebsd-fs Sat Apr 8 9:24:33 2000 Delivered-To: freebsd-fs@freebsd.org Received: from wcn4.wcnet.net (mail.wcnet.net [216.88.248.234]) by hub.freebsd.org (Postfix) with ESMTP id A6D9F37BB70; Sat, 8 Apr 2000 09:24:26 -0700 (PDT) (envelope-from jestess@wcnet.net) Received: from wcnet.net [216.88.251.88] by wcn4.wcnet.net with ESMTP (SMTPD32-6.00) id AD3468BB022C; Sat, 08 Apr 2000 11:24:20 -0500 Message-ID: <38EF5E0D.1B06FDD5@wcnet.net> Date: Sat, 08 Apr 2000 11:27:57 -0500 From: John Estess X-Mailer: Mozilla 4.7 [en] (X11; I; Linux 2.2.12 i386) X-Accept-Language: en MIME-Version: 1.0 To: freebsd-current@freebsd.org, adrian@freebsd.org, kris@freebsd.org, freebsd-fs@freebsd.org, freebsd@unix-consult.org Subject: UNIONFS Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-fs@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Timo, Please send your crash dump to me. While I have yet to cause a panic using unionfs, I've noticed a few interesting things - like the inability to umount(no kidding - am I doing something wrong?). Also, a whiteout file was affected. Yes, I'll recheck that - that didn't make sense. I've perused the mailing lists for the union fs and read the scant info in the D&I book, but I want to make sure there isn't a RFC or something for this fs. Is there some guidance besides the source code for this thing or is this a "let your conscience be your guide" scenario? Also, I've switched back to 4.0-Stable because I don't want to ride out the significant 5.0-Current changes coming down the pike . Since the Unionfs doesn't work anyway, can the powers-that-be update both Current and Stable in this case? It would be nice to development this in a working environment. Also, is the vfs code slated for massive overhaul soon? This thread needs to go to freebsd-fs. John Estess jestess@wcnet.net To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-fs" in the body of the message From owner-freebsd-fs Sat Apr 8 10:39:37 2000 Delivered-To: freebsd-fs@freebsd.org Received: from wcn4.wcnet.net (mail.wcnet.net [216.88.248.234]) by hub.freebsd.org (Postfix) with ESMTP id A050437B5DD for ; Sat, 8 Apr 2000 10:39:34 -0700 (PDT) (envelope-from jestess@wcnet.net) Received: from wcnet.net [216.88.251.75] by wcn4.wcnet.net with ESMTP (SMTPD32-6.00) id AED427460362; Sat, 08 Apr 2000 12:39:32 -0500 Message-ID: <38EF6FAD.44DF0965@wcnet.net> Date: Sat, 08 Apr 2000 12:43:09 -0500 From: John Estess X-Mailer: Mozilla 4.7 [en] (X11; I; Linux 2.2.12 i386) X-Accept-Language: en MIME-Version: 1.0 To: freebsd-fs@freebsd.org Subject: Re: UNIONFS References: <38EF5E0D.1B06FDD5@wcnet.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-fs@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org hate to answer my own post, but... > like the inability to umount(no kidding - am I > doing something wrong?). Also, a whiteout file was affected. Yes, I'll > recheck that - that didn't make sense. Works correctly on both counts. (double) Whoops. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-fs" in the body of the message From owner-freebsd-fs Sat Apr 8 14: 8:59 2000 Delivered-To: freebsd-fs@freebsd.org Received: from freefall.freebsd.org (freefall.FreeBSD.ORG [204.216.27.21]) by hub.freebsd.org (Postfix) with ESMTP id 4251F37B544; Sat, 8 Apr 2000 14:08:58 -0700 (PDT) (envelope-from kris@FreeBSD.org) Received: from localhost (kris@localhost) by freefall.freebsd.org (8.9.3/8.9.2) with ESMTP id OAA73307; Sat, 8 Apr 2000 14:08:58 -0700 (PDT) (envelope-from kris@FreeBSD.org) X-Authentication-Warning: freefall.freebsd.org: kris owned process doing -bs Date: Sat, 8 Apr 2000 14:08:57 -0700 (PDT) From: Kris Kennaway To: John Estess Cc: adrian@freebsd.org, freebsd-fs@freebsd.org, freebsd@unix-consult.org Subject: Re: UNIONFS In-Reply-To: <38EF5E0D.1B06FDD5@wcnet.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-fs@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Sat, 8 Apr 2000, John Estess wrote: > I've perused the mailing lists for the union fs and read the scant info > in the D&I book, but I want to make sure there isn't a RFC or something > for this fs. Is there some guidance besides the source code for this > thing or is this a "let your conscience be your guide" scenario? There's no RFC, since it's not an internet service :-) What would be useful in understanding what's going on are the papers by John Heidemann on stacking layers: http://www.isi.edu/~johnh/WORK/index.html (Hmm, apparently John teaches at USC thesedays) > Also, I've switched back to 4.0-Stable because I don't want to ride out > the significant 5.0-Current changes coming down the pike . Since the > Unionfs doesn't work anyway, can the powers-that-be update both Current > and Stable in this case? It would be nice to development this in a > working environment. Also, is the vfs code slated for massive overhaul > soon? A few people have requested that phk's current and forthcoming changes be backported to 4.0 once they've stabilized, but I don't think it's a guaranteed thing. I'm not sure how much the relevant bits of the system are likely to change in the near future. Kris ---- In God we Trust -- all others must submit an X.509 certificate. -- Charles Forsythe To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-fs" in the body of the message