From owner-freebsd-fs Mon Jul 15 02:21:49 1996 Return-Path: owner-fs Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id CAA20772 for fs-outgoing; Mon, 15 Jul 1996 02:21:49 -0700 (PDT) Received: from proxy.siemens.at (proxy.siemens.at [192.138.228.19]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id CAA20750; Mon, 15 Jul 1996 02:21:31 -0700 (PDT) Received: from sol1.gud.siemens.co.at (sol-f.gud.siemens-austria) by proxy.siemens.at with SMTP id AA28633 (5.67a/IDA-1.5); Mon, 15 Jul 1996 11:20:51 +0200 Received: from ws2301.gud.siemens.co.at by sol1.gud.siemens.co.at with smtp (Smail3.1.28.1 #7 for ) id m0ufjpi-00021UC; Mon, 15 Jul 96 11:20 MET DST Received: by ws2301.gud.siemens.co.at (1.37.109.16/1.37) id AA254952338; Mon, 15 Jul 1996 11:18:58 +0200 From: "Hr.Ladavac" Message-Id: <199607150918.AA254952338@ws2301.gud.siemens.co.at> Subject: Re: strangest weirdness To: adam@veda.is (Adam David) Date: Mon, 15 Jul 1996 11:18:58 +0200 (MESZ) Cc: freebsd-current@freebsd.org, freebsd-fs@freebsd.org In-Reply-To: <199607130027.AAA07477@veda.is> from "Adam David" at Jul 13, 96 00:27:54 am X-Mailer: ELM [version 2.4 PL24 ME8a] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-fs@freebsd.org X-Loop: FreeBSD.org Precedence: bulk In his e-mail Adam David wrote: > Well I have just seen what seems to be an unusual filesystem glitch. > I was doing 'make depend' in 2 kernel directories concurrently, and at the > same time as another kernel 'make all' was getting towards the end of its > processing. Both instances of 'make depend' broke by invoking the editor > 'ex' on an empty temporary file, following the first invocation of 'mkdep'. > No other instances of 'ex' were running at the time as far as I can tell. > > This was with an NFS /usr, and I believe that the 'make' executable was > reinstalled after the 'make all' was started but before the 'make depend' > was started. (yes, it's called stress testing. ;) > > I have also noticed that executables dump core often on client machines when > the files on the fileserver have been updated "under their feet". Okay I know > "if it hurts, don't do that", but why do these glitches occur? Well, to cut the long story short, that's sadly the way NFS works. Namely, executable is being paged in from the server. If you change the executable file between (or during) pages, who knows what will be read. Nonsense, most likely :( This does not happen on non-NFS mounted volumes (read: local) since then the ETXTBUSY is returned to the potential writer. Alas, NFS server does not know what is being done to the file it serves (i.e. it does not know that it's actually being executed, rather than just randomly read.) A possible workaround would be commiting all nfs mounted executables to swap, but to the best of my knowledge nobody does that (yes, the big commercial boys suffer from the same illness.) Terry will probably correct me :) /Marino > > -- > Adam David > From owner-freebsd-fs Fri Jul 19 04:10:05 1996 Return-Path: owner-fs Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id EAA20127 for fs-outgoing; Fri, 19 Jul 1996 04:10:05 -0700 (PDT) Received: from ccs.sogang.ac.kr (ccs.sogang.ac.kr [163.239.1.1]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id EAA20083 for ; Fri, 19 Jul 1996 04:09:59 -0700 (PDT) Received: from cslsun10.sogang.ac.kr by ccs.sogang.ac.kr (8.7.5/Sogang) id UAA07273; Fri, 19 Jul 1996 20:06:52 +0900 (KST) Received: by cslsun10.sogang.ac.kr (4.1/SMI-4.1) id AA05286; Fri, 19 Jul 96 20:08:53 KST Date: Fri, 19 Jul 96 20:08:53 KST From: heo@cslsun10.sogang.ac.kr (Heo Sung Gwan) Message-Id: <9607191108.AA05286@cslsun10.sogang.ac.kr> Apparently-To: freebsd-fs@FreeBSD.ORG Sender: owner-fs@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Hi I plan to modify the buffer cache to support multimedia files which are accessed sequentially and do not have no locality of reference. I want to know something about FreeBSD buffer cache implementation. 1) Where can I get the document about it?. 2) Which files in kernel src directory is concerned with it? 3) How can I enlarge the part for buffer cache in physical memory? 4) How can user process access the file in ufs filesystem through raw disk? Thanks in advance. Heo Sung-Gwan --- E-mail : heo@cslsun10.sogang.ac.kr From owner-freebsd-fs Fri Jul 19 04:28:13 1996 Return-Path: owner-fs Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id EAA20968 for fs-outgoing; Fri, 19 Jul 1996 04:28:13 -0700 (PDT) Received: from ccs.sogang.ac.kr (ccs.sogang.ac.kr [163.239.1.1]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id EAA20963 for ; Fri, 19 Jul 1996 04:28:10 -0700 (PDT) Received: from cslsun10.sogang.ac.kr by ccs.sogang.ac.kr (8.7.5/Sogang) id UAA07665; Fri, 19 Jul 1996 20:25:17 +0900 (KST) Received: by cslsun10.sogang.ac.kr (4.1/SMI-4.1) id AA05315; Fri, 19 Jul 96 20:27:19 KST From: heo@cslsun10.sogang.ac.kr (Heo Sung Gwan) Message-Id: <9607191127.AA05315@cslsun10.sogang.ac.kr> Subject: About buffer cache To: freebsd-fs@FreeBSD.ORG Date: Fri, 19 Jul 1996 20:27:19 +0900 (KST) Content-Type: text Sender: owner-fs@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Hi I plan to modify the buffer cache to support multimedia files which are accessed sequentially and do not have no locality of reference. I want to know something about FreeBSD buffer cache implementation. 1) Where can I get the document about it?. 2) Which files in kernel src directory is concerned with it? 3) How can I enlarge the part for buffer cache in physical memory? 4) How can user process access the file in ufs filesystem through raw disk? Thanks in advance. Heo Sung-Gwan --- E-mail : heo@cslsun10.sogang.ac.kr From owner-freebsd-fs Fri Jul 19 05:10:40 1996 Return-Path: owner-fs Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id FAA22383 for fs-outgoing; Fri, 19 Jul 1996 05:10:40 -0700 (PDT) Received: from elbe.desy.de (elbe.desy.de [131.169.82.208]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id FAA22378 for ; Fri, 19 Jul 1996 05:10:31 -0700 (PDT) From: Lars Gerhard Kuehl Date: Fri, 19 Jul 96 14:11:07 +0200 Message-Id: <9607191211.AA20344@elbe.desy.de> To: heo@cslsun10.sogang.ac.kr Subject: Re: About buffer cache Cc: freebsd-fs@FreeBSD.org Sender: owner-fs@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk a) How many of your mails shall we have to read? b) > 3) How can I enlarge the part for buffer cache in physical memory? > 4) How can user process access the file in ufs filesystem through raw disk? Why do you want to enlarge the buffer cache if you are going to access the filesystem through the raw device? The way to do the latter you can easily find in the fsck(8) sources. But if you use the raw disk you have to manage buffering for yourself and of course in order to keep your data in a consistant state, the file system must not be mounted. c) How about an mmap(2) aproach? FreeBSD is the OS of choice for that purpose. Lars From owner-freebsd-fs Fri Jul 19 06:39:40 1996 Return-Path: owner-fs Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id GAA26270 for fs-outgoing; Fri, 19 Jul 1996 06:39:40 -0700 (PDT) Received: from ccs.sogang.ac.kr (ccs.sogang.ac.kr [163.239.1.1]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id GAA26252 for ; Fri, 19 Jul 1996 06:39:36 -0700 (PDT) Received: from cslsun10.sogang.ac.kr by ccs.sogang.ac.kr (8.7.5/Sogang) id WAA09921; Fri, 19 Jul 1996 22:36:43 +0900 (KST) Received: by cslsun10.sogang.ac.kr (4.1/SMI-4.1) id AA05500; Fri, 19 Jul 96 22:38:45 KST From: heo@cslsun10.sogang.ac.kr (Heo Sung Gwan) Message-Id: <9607191338.AA05500@cslsun10.sogang.ac.kr> Subject: RE: RE:About buffer cache To: freebsd-fs@FreeBSD.ORG Date: Fri, 19 Jul 1996 22:38:44 +0900 (KST) Content-Type: text Sender: owner-fs@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk I think that UNIX file system with buffer cache is not proper to support multimedia files(e.g mpeg files) becasue buffer cache is based on locality of referece(i.e. the recently referened block have high probabiliey to be referenced again). But multimedia files are accessed sequentially and therefore caching of the referenced block is not suitable and the block of mpeg file referenced by a process has low probability to be accessed by the other processes. So I think a FIFO buffer per each open file and the read-ahead to each FIFO buffer are good choice for multimedia file retrieval. In fact the many filesystems for multimedia adopted this approach( e.g. UC Berkeley CMFS). And there are two possible approaches: 1. Modification of buffer cache to FIFO buffers dynamically allocated. 2. User-level process that manages that FIFO buffers that access files through raw disk without buffer cache. Thanks for your resposes. Heo Sung-Gwan --- E-mail : heo@cslsun10.sogang.ac.kr From owner-freebsd-fs Fri Jul 19 07:32:07 1996 Return-Path: owner-fs Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id HAA28802 for fs-outgoing; Fri, 19 Jul 1996 07:32:07 -0700 (PDT) Received: from dyson.iquest.net (dyson.iquest.net [198.70.144.127]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id HAA28783 for ; Fri, 19 Jul 1996 07:32:02 -0700 (PDT) Received: (from root@localhost) by dyson.iquest.net (8.7.5/8.6.9) id JAA00152; Fri, 19 Jul 1996 09:31:05 -0500 (EST) From: "John S. Dyson" Message-Id: <199607191431.JAA00152@dyson.iquest.net> Subject: Re: RE:About buffer cache To: heo@cslsun10.sogang.ac.kr (Heo Sung Gwan) Date: Fri, 19 Jul 1996 09:31:05 -0500 (EST) Cc: freebsd-fs@FreeBSD.ORG In-Reply-To: <9607191338.AA05500@cslsun10.sogang.ac.kr> from "Heo Sung Gwan" at Jul 19, 96 10:38:44 pm X-Mailer: ELM [version 2.4 PL24 ME8] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-fs@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > > And there are two possible approaches: > 1. Modification of buffer cache to FIFO buffers dynamically allocated. > 2. User-level process that manages that FIFO buffers that access files > through raw disk without buffer cache. > > > Thanks for your resposes. > On some OSes there is the ability to tune the buffer cache/filesystem to be warned of certain behavior. Specifically, on sequential file reads we will currently retain the old, sequentially read data, non-preferentially. We do have some code in our vfs_bio to remember if a buffer is being accessed repeatedly, but I know that a large, multimedia read will still flush the buffer cache. Should we consider an fcntl or somesuch that will send a hint to the buffer cache code to forget old sequentially read data? This would allow reuse of essentially the same buffer space for multimedia apps. So, instead of a multimedia read taking up the entire cache with stale data, we could free the stale data. And reuse the buffer space. Shouldn't be too hard, but the keepers of the API should tell me where/how to implement the system call hooks... Bruce?, Kirk?, David???, Anyone else have an idea as to where to put the hints? John From owner-freebsd-fs Fri Jul 19 08:57:45 1996 Return-Path: owner-fs Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id IAA04742 for fs-outgoing; Fri, 19 Jul 1996 08:57:45 -0700 (PDT) Received: from freefall.freebsd.org (localhost.cdrom.com [127.0.0.1]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id IAA04733; Fri, 19 Jul 1996 08:57:43 -0700 (PDT) Message-Id: <199607191557.IAA04733@freefall.freebsd.org> To: "John S. Dyson" cc: heo@cslsun10.sogang.ac.kr (Heo Sung Gwan), freebsd-fs@FreeBSD.ORG Subject: Re: About buffer cache In-reply-to: Your message of "Fri, 19 Jul 1996 09:31:05 CDT." <199607191431.JAA00152@dyson.iquest.net> Date: Fri, 19 Jul 1996 08:57:42 -0700 From: "Justin T. Gibbs" Sender: owner-fs@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk >Shouldn't be too hard, but the keepers >of the API should tell me where/how to implement the system call >hooks... Bruce?, Kirk?, David???, Anyone else have an idea as to >where to put the hints? > >John What about doing an mmap followed by an madvise(MADV_SEQUENTIAL)? -- Justin T. Gibbs =========================================== FreeBSD: Turning PCs into workstations =========================================== From owner-freebsd-fs Fri Jul 19 09:13:05 1996 Return-Path: owner-fs Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id JAA05503 for fs-outgoing; Fri, 19 Jul 1996 09:13:05 -0700 (PDT) Received: from darkstar.isi.edu (darkstar.isi.edu [128.9.128.127]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id JAA05498 for ; Fri, 19 Jul 1996 09:13:04 -0700 (PDT) Received: from dash.isi.edu by darkstar.isi.edu (5.65c/5.61+local-23) id ; Fri, 19 Jul 1996 09:12:59 -0700 Received: from dash.isi.edu (johnh@localhost.isi.edu [127.0.0.1]) by dash.isi.edu (8.7.5/8.7.3) with ESMTP id JAA29334 for ; Fri, 19 Jul 1996 09:12:53 -0700 Message-Id: <199607191612.JAA29334@dash.isi.edu> X-Url: To: freebsd-fs@freebsd.org Subject: Re: About buffer cache In-Reply-To: <199607191431.JAA00152@dyson.iquest.net> Date: Fri, 19 Jul 1996 09:12:52 -0700 From: John Heidemann Sender: owner-fs@freebsd.org X-Loop: FreeBSD.org Precedence: bulk On Fri, 19 Jul 1996 09:31:05 CDT, "John S. Dyson" wrote: >On some OSes there is the ability to tune the buffer cache/filesystem >to be warned of certain behavior. Specifically, on sequential file >reads we will currently retain the old, sequentially read data, >non-preferentially. SunOS has an madvise option MADV_SEQUENTIAL, and code in the kernel to optimize access for these pages. The BSD madvise(2) man page has the same option. The assumption is that the pages will only be accessed once (like in a cp), so it tries to free the pages as soon as they're no longer in use. This sounds like the behavior you want when reading large multimedia files. Although this approach only works with mmap'ed regions, if you're doing multimedia I hope you're doing mmap'ing and not paying an extra data copy with the read/write interface. -John Heidemann