public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Chris Mason <mason@suse.com>
To: Andi Kleen <ak@suse.de>
Cc: Neil Brown <neilb@cse.unsw.edu.au>,
	Linus Torvalds <torvalds@transmeta.com>,
	linux-kernel@vger.kernel.org
Subject: Re: Caching files in nfsd was Re: [patch 12/16] fix race between writeback and unlink
Date: 04 Jun 2002 09:29:44 -0400	[thread overview]
Message-ID: <1023197384.2920.97.camel@tiny> (raw)
In-Reply-To: <20020604141649.A29334@wotan.suse.de>

On Tue, 2002-06-04 at 08:16, Andi Kleen wrote:
> > The only issue that I can see (except for simple coding) is that as
> > NFS cannot be precise about closing at the *right* time we would be
> > changing from closing too early (and so re-opening) to closing too
> > late.
> > Would this be an issue for any filesystem?  My feeling is not, but I'm
> > open to opinions....
> 
> The only potential issue I see is that forcing a flush when the file system
> fills up may be a good idea to drop preallocations (but then one would hope 
> that a fs with preallocation does this already automatically, so it hopefully 
> won't be needed in nfsd) 

reiserfs does, but I'm not sure about ext2.  reiserfs doesn't carry
preallocated blocks from one transaction to another.  So when the
transaction closes, we free preallocated blocks.

When the FS runs out of space, we stop the transaction to give everyone
a chance to free up what they can (not just preallocation), and then
start a new transaction.  So nfs closing too late won't hurt.

-chris


      reply	other threads:[~2002-06-04 13:31 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <1023142233.31475.23.camel@tiny.suse.lists.linux.kernel>
     [not found] ` <Pine.LNX.4.44.0206031514110.868-100000@home.transmeta.com.suse.lists.linux.kernel>
2002-06-04 10:38   ` Caching files in nfsd was Re: [patch 12/16] fix race between writeback and unlink Andi Kleen
2002-06-04 11:37     ` Neil Brown
2002-06-04 12:16       ` Andi Kleen
2002-06-04 13:29         ` Chris Mason [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1023197384.2920.97.camel@tiny \
    --to=mason@suse.com \
    --cc=ak@suse.de \
    --cc=linux-kernel@vger.kernel.org \
    --cc=neilb@cse.unsw.edu.au \
    --cc=torvalds@transmeta.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox