From owner-freebsd-current@FreeBSD.ORG Thu Feb 17 21:19:03 2005 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 721F516A4CE for ; Thu, 17 Feb 2005 21:19:03 +0000 (GMT) Received: from mh2.centtech.com (moat3.centtech.com [207.200.51.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6E12343D2D for ; Thu, 17 Feb 2005 21:19:00 +0000 (GMT) (envelope-from anderson@centtech.com) Received: from [10.177.171.220] (neutrino.centtech.com [10.177.171.220]) by mh2.centtech.com (8.13.1/8.13.1) with ESMTP id j1HLIwKO073137; Thu, 17 Feb 2005 15:18:58 -0600 (CST) (envelope-from anderson@centtech.com) Message-ID: <42150A3D.8080500@centtech.com> Date: Thu, 17 Feb 2005 15:18:53 -0600 From: Eric Anderson User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.7.5) Gecko/20050210 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Chuck Swiger References: <1108584730.95661.12.camel@server.mcneil.com> <20050216201716.GA28436@odin.ac.hmc.edu> <4213B3C8.3090508@centtech.com> <1108588393.12275.9.camel@server.mcneil.com> <20050216214031.GA2787@odin.ac.hmc.edu> <4213D3AA.70809@elischer.org> <84dead72050217081540fd7640@mail.gmail.com> <4214FD67.7060801@mac.com> In-Reply-To: <4214FD67.7060801@mac.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.82/707/Wed Feb 16 16:00:07 2005 on mh2.centtech.com X-Virus-Status: Clean cc: Julian Elischer cc: current@freebsd.org Subject: Re: where did all my memory go? (file system cache) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Feb 2005 21:19:03 -0000 Chuck Swiger wrote: > Joseph Koshy wrote: > >>> what I want is: >>> >>> int fd = open("myfile",...); >>> write1GBfiletodisk(fd, data); >>> ioctl(fd, PURGEFROMCACHE); >>> perform_md5(fd); >>> >>> and be sure that teh MD5 is that of what is on the disk. >>> not what is in RAM. >> >> >> unmount(file-system-of("myfile")) (even if it fails) ? > > > That's actually a pretty good suggestion, and is less intrusive than, > say rebooting, which is probably the only way to be entirely sure that > the write cache on the drive itself has been flushed. If the write > cache is off, Julian probably ought to be able to trust fsync(2)...? Wouldn't there be a way to take the code that does the cache dumping (excuse my bad lingo here) and make a little tool that does it without any actual unmounting? Suppose the filesystem actually unmounted.. yikes! Eric -- ------------------------------------------------------------------------ Eric Anderson Sr. Systems Administrator Centaur Technology I have seen the future and it is just like the present, only longer. ------------------------------------------------------------------------