All of lore.kernel.org
 help / color / mirror / Atom feed
From: Andrea Arcangeli <andrea@suse.de>
To: Andrew Morton <akpm@zip.com.au>
Cc: Alexander Viro <viro@math.psu.edu>, lkml <linux-kernel@vger.kernel.org>
Subject: Re: [patch] truncate fixes
Date: Mon, 7 Jan 2002 04:16:36 +0100	[thread overview]
Message-ID: <20020107041636.I1561@athlon.random> (raw)
In-Reply-To: <3C36DEA9.AEA2A402@zip.com.au>, <3C36DEA9.AEA2A402@zip.com.au>; <20020107034654.G1561@athlon.random> <3C390DAA.3339768C@zip.com.au>
In-Reply-To: <3C390DAA.3339768C@zip.com.au>; from akpm@zip.com.au on Sun, Jan 06, 2002 at 06:53:30PM -0800

On Sun, Jan 06, 2002 at 06:53:30PM -0800, Andrew Morton wrote:
> Andrea Arcangeli wrote:
> > 
> > I prefer my fix that simply recalls the ->truncate callback if -ENOSPC
> > is returned by prepare_write. vmtruncate seems way overkill,
> 
> No opinion on that here.  This is what was in -ac.  Perhaps Al can
> comment?
> 
> > and after
> > calling ->truncate the __block_prepare_changes above won't be necessary
> > because the leftover will be correctly deallocated (no need to clear
> > them out and to mark them dirty, they will just go away before any
> > readpage can see them).
> 
> No, this code is needed if the write is _inside_ i_size, to an
> uninstantiated block.  truncate won't remove those blocks, and we've
> gone and added them to the file.

I see, I got mistaken because here we're not in a i_sem-less writepage, so
in those cases I wanted to always deallocate the blocks rather than
lefting zeroed leftovers. if the leftover blocks are over i_size (common
case I was thinking about incidentally :) that's automatica with
->truncate, but if they aren't over i_size that's not enough and we miss
a lowlevel API to decallocate a range of blocks, so your patch is the
only way indeed.

> 
> -


Andrea

  reply	other threads:[~2002-01-07  3:16 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2002-01-05 11:08 [patch] truncate fixes Andrew Morton
2002-01-07  2:46 ` Andrea Arcangeli
2002-01-07  2:53   ` Andrew Morton
2002-01-07  3:16     ` Andrea Arcangeli [this message]
2002-01-07  5:24     ` Alexander Viro
2002-01-07  3:11   ` Andrew Morton
2002-01-07  3:58     ` Andrea Arcangeli
2002-01-07  3:32 ` Andrea Arcangeli
2002-01-07  3:48   ` Andrew Morton
2002-01-07  4:12     ` Andrea Arcangeli
2002-01-07  4:28       ` Andrew Morton
2002-01-07  5:09         ` Andrea Arcangeli
2002-01-07 12:41         ` Daniel Phillips

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=20020107041636.I1561@athlon.random \
    --to=andrea@suse.de \
    --cc=akpm@zip.com.au \
    --cc=linux-kernel@vger.kernel.org \
    --cc=viro@math.psu.edu \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.