linux-fsdevel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Vyacheslav Dubeyko <slava@dubeyko.com>
To: Sergei Antonov <saproj@gmail.com>
Cc: linux-fsdevel@vger.kernel.org,
	Anton Altaparmakov <aia21@cam.ac.uk>,
	Al Viro <viro@zeniv.linux.org.uk>,
	Christoph Hellwig <hch@infradead.org>,
	Hin-Tak Leung <htl10@users.sourceforge.net>,
	Kyle Laracey <kalaracey@gmail.com>,
	Andrew Morton <akpm@linux-foundation.org>
Subject: Re: [PATCH] hfsplus: fix "unused node is not erased" error
Date: Wed, 21 May 2014 20:40:45 +0400	[thread overview]
Message-ID: <1400690445.15260.14.camel@slavad-CELSIUS-H720> (raw)
In-Reply-To: <1400607863-14633-1-git-send-email-saproj@gmail.com>

On Tue, 2014-05-20 at 19:44 +0200, Sergei Antonov wrote:

[snip]
>  
> -int hfsplus_file_extend(struct inode *inode)
> +int hfsplus_file_extend(struct inode *inode, bool zeroout)
>  {
>  	struct super_block *sb = inode->i_sb;
>  	struct hfsplus_sb_info *sbi = HFSPLUS_SB(sb);
> @@ -463,6 +463,12 @@ int hfsplus_file_extend(struct inode *inode)
>  		}
>  	}
>  
> +	if (zeroout) {
> +		res = sb_issue_zeroout(sb, start, len, GFP_NOFS);

As I can see, sb_issue_zeroout() initiate request for write. But
previously the hfsplus_file_extend() operated by page cache only during
file extending. From one point of view, we can fail during operation of
file extending but, anyway, we will zero out blocks by means of writing.
>From another point of view, prepared pages are returned as tree's nodes
for filling by some data and, finally, it will be written on volume as a
result of node creation.

So, I think that it makes sense to zero out namely prepared pages but
not to initiate request for write via sb_issue_zeroout().

> +		if (res)
> +			goto out;
> +	}
> +
>  	hfs_dbg(EXTENT, "extend %lu: %u,%u\n", inode->i_ino, start, len);
>  
>  	if (hip->alloc_blocks <= hip->first_blocks) {
> diff --git a/fs/hfsplus/hfsplus_fs.h b/fs/hfsplus/hfsplus_fs.h
> index 83dc292..3c872b2 100644
> --- a/fs/hfsplus/hfsplus_fs.h
> +++ b/fs/hfsplus/hfsplus_fs.h
> @@ -417,6 +417,7 @@ void hfs_bnode_free(struct hfs_bnode *);
>  struct hfs_bnode *hfs_bnode_create(struct hfs_btree *, u32);
>  void hfs_bnode_get(struct hfs_bnode *);
>  void hfs_bnode_put(struct hfs_bnode *);
> +bool hfs_bnode_need_zeroout(struct hfs_btree *);
>  
>  /* brec.c */
>  u16 hfs_brec_lenoff(struct hfs_bnode *, u16, u16 *);
> @@ -463,7 +464,7 @@ int hfsplus_ext_write_extent(struct inode *);
>  int hfsplus_get_block(struct inode *, sector_t, struct buffer_head *, int);
>  int hfsplus_free_fork(struct super_block *, u32,
>  		struct hfsplus_fork_raw *, int);
> -int hfsplus_file_extend(struct inode *);
> +int hfsplus_file_extend(struct inode *, bool zeroout);

I think that it doesn't make sense to keep name of second argument here.

Thanks,
Vyacheslav Dubeyko.



  reply	other threads:[~2014-05-21 16:41 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-05-20 17:44 [PATCH] hfsplus: fix "unused node is not erased" error Sergei Antonov
2014-05-21 16:40 ` Vyacheslav Dubeyko [this message]
2014-05-21 18:15   ` Sergei Antonov
2014-05-22 13:07     ` Vyacheslav Dubeyko
2014-05-22 13:18       ` Sergei Antonov
2014-05-23  6:21         ` Vyacheslav Dubeyko
2014-05-23 10:54           ` Sergei Antonov
  -- strict thread matches above, loose matches on Subject: below --
2014-05-21 20:12 Hin-Tak Leung
2014-05-22  6:29 ` Vyacheslav Dubeyko
2014-05-22  7:07   ` Andrew Morton
2014-05-22 12:48     ` Sergei Antonov
2014-05-22 13:13       ` Vyacheslav Dubeyko
2014-05-22 13:25         ` Sergei Antonov
2014-05-22 14:55           ` Vyacheslav Dubeyko
2014-05-22 17:35             ` Sergei Antonov

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=1400690445.15260.14.camel@slavad-CELSIUS-H720 \
    --to=slava@dubeyko.com \
    --cc=aia21@cam.ac.uk \
    --cc=akpm@linux-foundation.org \
    --cc=hch@infradead.org \
    --cc=htl10@users.sourceforge.net \
    --cc=kalaracey@gmail.com \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=saproj@gmail.com \
    --cc=viro@zeniv.linux.org.uk \
    /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;
as well as URLs for NNTP newsgroup(s).