All of lore.kernel.org
 help / color / mirror / Atom feed
From: Namjae Jeon <linkinjeon@gmail.com>
To: OGAWA Hirofumi <hirofumi@mail.parknet.co.jp>
Cc: akpm@linux-foundation.org, linux-fsdevel@vger.kernel.org,
	linux-kernel@vger.kernel.org,
	Namjae Jeon <namjae.jeon@samsung.com>,
	Amit Sahrawat <a.sahrawat@samsung.com>
Subject: Re: [PATCH v3 2/6] fat: add fat_fallocate operation
Date: Fri, 14 Feb 2014 13:53:26 +0900	[thread overview]
Message-ID: <CAKYAXd80BFUMGYrON22Ui4xSMaxNJaHD1ss8bMVgdQqC4xG48A@mail.gmail.com> (raw)
In-Reply-To: <CAKYAXd_EYrfF0iQVw5FJRHkGCeMTUoQdx+BogV+-g9vqXeGZdw@mail.gmail.com>

>> [...]
>>
>>> +		/* Release unwritten fallocated blocks on inode eviction. */
>>> +		if (MSDOS_I(inode)->mmu_private < MSDOS_I(inode)->i_disksize) {
>>> +			int err;
>>> +			fat_truncate_blocks(inode, MSDOS_I(inode)->mmu_private);
>>> +			/* Fallocate results in updating the i_start/iogstart
>>> +			 * for the zero byte file. So, make it return to
>>> +			 * original state during evict and commit it
>>> +			 * synchrnously to avoid any corruption on the next
>>> +			 * access to the cluster chain for the file.
>>> +			 */
>>> +			err = fat_sync_inode(inode);
>>
>> Ah, good catch. We have to update i_size. I was forgetting about this.
>> Well, sync inode unconditionally would not be good. Maybe, we better to
>> use __fat_write_inode() with inode_needs_sync() or such.
> Okay, I will change it.
Hi OGAWA

When I checked more, we should wait till inode is sync. Because in the
eviction it will leave the inode/buffers being marked dirty.
Not waiting for it get sync over here. It will leave cluster chain
corrupted when remounting.
It mean we cannot use __fat_write_inode with inode_needs_sync() conditionally.

Thanks.
>
> Thanks.
>> --
>> OGAWA Hirofumi <hirofumi@mail.parknet.co.jp>
>>
>

  reply	other threads:[~2014-02-14  4:53 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-12-25  6:31 [PATCH v3 2/6] fat: add fat_fallocate operation Namjae Jeon
2014-02-03  4:14 ` OGAWA Hirofumi
2014-02-03 23:04   ` Namjae Jeon
2014-02-14  4:53     ` Namjae Jeon [this message]
2014-02-14  7:30       ` OGAWA Hirofumi
2014-02-14 10:16         ` Namjae Jeon

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=CAKYAXd80BFUMGYrON22Ui4xSMaxNJaHD1ss8bMVgdQqC4xG48A@mail.gmail.com \
    --to=linkinjeon@gmail.com \
    --cc=a.sahrawat@samsung.com \
    --cc=akpm@linux-foundation.org \
    --cc=hirofumi@mail.parknet.co.jp \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=namjae.jeon@samsung.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 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.