public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Scott Bronson <bronson@rinspin.com>
To: OGAWA Hirofumi <hirofumi@mail.parknet.co.jp>
Cc: "Randy.Dunlap" <rddunlap@osdl.org>, linux-kernel@vger.kernel.org
Subject: Re: FAT/VFAT and the sync flag
Date: 04 Oct 2002 10:57:51 -0700	[thread overview]
Message-ID: <1033754272.5296.338.camel@emma> (raw)
In-Reply-To: <87d6qq1an5.fsf@devron.myhome.or.jp>

On Fri, 2002-10-04 at 08:33, OGAWA Hirofumi wrote:
> You are right. The fatfs just ignore the sync flag.

"Randy.Dunlap" <rddunlap@osdl.org> writes:
> What advantage would implementing sync have for FAT-fs?
> When you unmount a device (before removing it), the filesystem
> is automatically sync-ed (with some possible delay time here to
> perform I/O).  That could provide a quicker unmount, at the
> expense of spreading the device (filesystem) I/O out across
> all device reads/writes over time.  (did that make sense?) ...
> Is there some usage scenario that you are interested in that I am
> just missing?

That made perfect sense.  However, I'm happy with the unmount times. 
I'm worried about ham-fisted users.

When you unplug a VFAT-mounted device from FireWire or USB without
remembering to unmount it first, you get instant file system
corruption.  I've done it a few times myself even though I know better! 
I'm in a hurry, I grab the device, poof!  It's now broken until I can
run fsck.vfat on it and restore missing files.  It's not fun.

If VFAT supported the sync flag, then neglecting to unmount it would not
be so catastrophic.  Well, unless you unplug it in the middle of disk
activity, in which case you're asking for it.  :)

I'd just like Linux to try to avoid dying catastrophically if someone
makes a simple mistake.  Any idea how much effort it would take to add
sync support to VFAT?  Thanks,

    - Scott



      reply	other threads:[~2002-10-04 17:57 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2002-10-04  4:51 FAT/VFAT and the sync flag Scott Bronson
2002-10-04  5:26 ` Randy.Dunlap
2002-10-04 15:33   ` OGAWA Hirofumi
2002-10-04 17:57     ` Scott Bronson [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=1033754272.5296.338.camel@emma \
    --to=bronson@rinspin.com \
    --cc=hirofumi@mail.parknet.co.jp \
    --cc=linux-kernel@vger.kernel.org \
    --cc=rddunlap@osdl.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox