From owner-freebsd-fs@FreeBSD.ORG Tue Oct 3 06:51:42 2006 Return-Path: X-Original-To: freebsd-fs@freebsd.org 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 1C2C416A403 for ; Tue, 3 Oct 2006 06:51:42 +0000 (UTC) (envelope-from scottl@samsco.org) Received: from pooker.samsco.org (pooker.samsco.org [168.103.85.57]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7E75343D45 for ; Tue, 3 Oct 2006 06:51:41 +0000 (GMT) (envelope-from scottl@samsco.org) Received: from [192.168.254.11] (phobos.samsco.home [192.168.254.11]) (authenticated bits=0) by pooker.samsco.org (8.13.4/8.13.4) with ESMTP id k936pYWM056298; Tue, 3 Oct 2006 00:51:40 -0600 (MDT) (envelope-from scottl@samsco.org) Message-ID: <45220876.1060109@samsco.org> Date: Tue, 03 Oct 2006 00:51:34 -0600 From: Scott Long User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X; en-US; rv:1.8.0.7) Gecko/20060910 SeaMonkey/1.0.5 MIME-Version: 1.0 To: Shane Adams References: <20061003062648.24344.qmail@web31810.mail.mud.yahoo.com> In-Reply-To: <20061003062648.24344.qmail@web31810.mail.mud.yahoo.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-1.4 required=3.8 tests=ALL_TRUSTED autolearn=failed version=3.1.1 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on pooker.samsco.org Cc: freebsd-fs@freebsd.org Subject: Re: curiosity between bread and UFS_BALLOC on struct buf X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Oct 2006 06:51:42 -0000 Ok, that makes more sense. Yes, you need to use getblk(). Once you've modified the bp->b_data, you need to set appropriate flags on the buf so the the VM system knows that buffer is dirty and needs to be flushed to disk. Although B_DIRTY looks like the obvious flag, it apparently only has meaning to ext2fs. What you need to do is clear B_INVAL if it is set. You might also need to twiddle B_CACHE, but I can't recall for sure anymore. Scott Shane Adams wrote: > Hey thanks for the response! I should of mentioned that I am hacking on my own filesystem, using UFS/FFS as a basis. So I'm actually below VOP_*. I did find in my digging throught the code that UFS_BALLOC ultimatly for my code path gets the bufer from a call to getblk. > > From the documentation I've read I would think that I could then immediatly bwrite on that buffer, which I attempt, but my change application specific changes to the buffer do not persist. I have a couple of anciallary functions that do the bread/bwrite and those work perfectly. > > *shrug* > > Hopefully I'll nail it! > > Cheers, > Shane > > > ----- Original Message ---- > From: Scott Long > To: Shane Adams > Cc: freebsd-fs@freebsd.org > Sent: Monday, October 2, 2006 8:31:44 PM > Subject: Re: curiosity between bread and UFS_BALLOC on struct buf > > > > On Mon, 2 Oct 2006, Shane Adams wrote: > >> Hey all, > >> I've been puzzling with a bit of code. I'm creating a file from within >> a kernel module, that works fine, but I've got a question if perhaps I'm >> missing something: >> >> I use UFS_BALLOC to allocate some space. That function has a struct buf >> thats returned. What I would expect is that I could manipulate the >> bp->b_data field then do a bwrite and have my changes saved. Doesnt >> workthat way. Only way I can get it to work is >> >> 1 UFS_BALLOC( ... ) >> >> 2 bwrite( .. ) >> >> 3 bread( ... ) >> >> 4 /* Make changes to what I read */ >> >> 5 bwrite() >> >> Seems like I could get rid of, 2 and 3. I'm not sure why I have to >> bwrite the buffer returned from UFS_BALLOC. I dug around and there are >> a few examples of where ffs/ufs manipulate the buffer returned from >> UFS_BALLOC so I am guessing I'm missing a flag or something. >> >> Hope the question is clear enough! > > You shouldn't be groping around in UFS internals like this. Using > VOP_WRITE will probably serve you much better. Look at something like > kern_ktrace.c to see how file writing in the kernel is done. > > Scott > > > >