All of lore.kernel.org
 help / color / mirror / Atom feed
From: OGAWA Hirofumi <hirofumi@mail.parknet.co.jp>
To: Namjae Jeon <linkinjeon@gmail.com>
Cc: akpm@linux-foundation.org, linux-kernel@vger.kernel.org,
	Ravishankar N <cyberax82@gmail.com>,
	Amit Sahrawat <amit.sahrawat83@gmail.com>
Subject: Re: [PATCH v2] fat: editions to support fat_fallocate()
Date: Mon, 15 Oct 2012 01:20:16 +0900	[thread overview]
Message-ID: <87lif958lb.fsf@devron.myhome.or.jp> (raw)
In-Reply-To: <1350138661-2454-1-git-send-email-linkinjeon@gmail.com> (Namjae Jeon's message of "Sat, 13 Oct 2012 23:31:01 +0900")

Namjae Jeon <linkinjeon@gmail.com> writes:

> Implement preallocation via the fallocate syscall on VFAT partitions.
> This patch is based on an earlier patch of the same name which had some
> issues detailed below and did not get accepted. Refer
> https://lkml.org/lkml/2007/12/22/130.
>
> a)The preallocated space was not persistent across remounts when the
> FALLOC_FL_KEEP_SIZE flag was set. Also, writes to the file allocated new
> clusters instead of using the preallocated area.
>
> Consider the scenario:
> mount-->preallocate space for a file --> unmount.
> In the old patch,the preallocated space was not reflected for that
> file (verified using the 'du' command).
>
> This is now fixed with modifications to fat_fill_inode().

What is real usage pattern of persistent across remounts on FAT? If once
device was unmounted, we can't know the state of FS anymore, there are
many implementations of FAT. And preallocation is not in the spec.

I worry to break something. And I guess the freeing preallocation on
last close may fix the issue for usage.
-- 
OGAWA Hirofumi <hirofumi@mail.parknet.co.jp>

  reply	other threads:[~2012-10-14 16:20 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-10-13 14:31 [PATCH v2] fat: editions to support fat_fallocate() Namjae Jeon
2012-10-14 16:20 ` OGAWA Hirofumi [this message]
2012-10-16  4:12   ` Namjae Jeon
2012-10-16 10:14     ` OGAWA Hirofumi
2012-10-17 10:57       ` Namjae Jeon
2012-10-17 10:57         ` Namjae Jeon
2012-10-21 23:54         ` OGAWA Hirofumi
2012-10-22 15:10           ` Namjae Jeon
2012-10-22 15:10             ` Namjae Jeon
2012-10-23  7:19             ` OGAWA Hirofumi
2012-10-23  7:24               ` Namjae Jeon
2013-02-14  2:40 ` Read support for fat_fallocate()? (was [v2] fat: editions to support fat_fallocate()) Andrew Bartlett
2013-02-14  2:48 ` Andrew Bartlett
2013-02-14  6:44   ` Namjae Jeon
2013-02-14  7:07     ` Andrew Bartlett
2013-02-14  9:52       ` Namjae Jeon
2013-02-15  3:49         ` Andrew Bartlett
2013-02-18 11:36           ` OGAWA Hirofumi
2013-02-18 13:11             ` Andrew Bartlett
2013-02-18 14:25             ` Namjae Jeon
2013-02-18 14:59               ` OGAWA Hirofumi
2013-02-18 15:15                 ` 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=87lif958lb.fsf@devron.myhome.or.jp \
    --to=hirofumi@mail.parknet.co.jp \
    --cc=akpm@linux-foundation.org \
    --cc=amit.sahrawat83@gmail.com \
    --cc=cyberax82@gmail.com \
    --cc=linkinjeon@gmail.com \
    --cc=linux-kernel@vger.kernel.org \
    /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.