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 19:16:11 +0900	[thread overview]
Message-ID: <CAKYAXd951bjgSkzFKOKigPx7Ut+=DPCUFQLdH-3DS-0mhp+f+Q@mail.gmail.com> (raw)
In-Reply-To: <8761oiqhh0.fsf@devron.myhome.or.jp>

2014-02-14 16:30 GMT+09:00, OGAWA Hirofumi <hirofumi@mail.parknet.co.jp>:
> Namjae Jeon <linkinjeon@gmail.com> writes:
>
>>>> [...]
>>>>
>>>>> +		/* 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.
>
> Yeah, this situation bothers us. However, the inode is not marked as
> dirty after I_FREEING. And in fatfs case, all related dirty buffers
> should goes into blockdev inode buffers (i.e. metadata only), right?
Right.
>
> So, I thought sync is not necessary.
Yes, I will add it as you pointed.

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

      reply	other threads:[~2014-02-14 10:16 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
2014-02-14  7:30       ` OGAWA Hirofumi
2014-02-14 10:16         ` Namjae Jeon [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='CAKYAXd951bjgSkzFKOKigPx7Ut+=DPCUFQLdH-3DS-0mhp+f+Q@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.