From: "Austin S. Hemmelgarn" <ahferroin7@gmail.com>
To: Anssi Hannula <anssi.hannula@bitwise.fi>,
OGAWA Hirofumi <hirofumi@mail.parknet.co.jp>,
linux-fsdevel@vger.kernel.org
Cc: Oleksij Rempel <bug-track@fisher-privat.net>,
linux-kernel@vger.kernel.org
Subject: Re: fat: changed filesystem dirty bit behavior
Date: Thu, 21 Apr 2016 09:24:43 -0400 [thread overview]
Message-ID: <5718D49B.3090908@gmail.com> (raw)
In-Reply-To: <5718D0F8.5090502@bitwise.fi>
On 2016-04-21 09:09, Anssi Hannula wrote:
> Hi all!
>
> Starting with commit b88a105802e9aeb [1] ("fat: mark fs as dirty on
> mount and clean on umount") FAT(32) filesystems are now marked as
> "dirty" on mount and clean on unmount.
>
> The commit message says that this is similar to Win 7 behavior - "Win 7,
> set dirty flag on first write and remove it on umount".
> However, I have been unable to coerce my Windows 7 system to set this
> flag on a FAT32 filesystem, when tested both with portable (USB) and
> fixed disks. Have they maybe changed this with an update, or does
> someone else still see this bit set on Win7 or later?
>
> This change is a bit problematic on a legacy embedded application I'm
> working on, as the user interface doesn't have any separate
> eject/unmount button for a USB stick - it relies on the user not
> unplugging the stick while a data transfer is in progress.
> So, when the system is upgraded to a modern vanilla kernel version, this
> bit is set when the USB stick is unplugged, causing Windows to always
> prompt whether to scan and fix the drive, which is annoying/confusing
> for users.
>
> Would a patch to add a filesystem option to restore the previous (and
> seemingly Win7) behavior be accepted?
>
> Or is this a case where the application is just considered to be broken?
> (as setting the dirty bit seems technically correct, even if Windows
> doesn't do it)
>
> Or anything else I'm missing?
Based on some recent testing I did on Windows 10, and assuming it has
similar behavior to the current Windows 7 behavior (which isn't a far
stretch, they actually back-ported a lot of the lower level stuff that
they reasonably can), it appears to set the dirty bit only when
something is actually written to on the disk, which makes some sense,
because the filesystem really isn't dirty until we've written something
to it.
prev parent reply other threads:[~2016-04-21 13:25 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-04-21 13:09 fat: changed filesystem dirty bit behavior Anssi Hannula
2016-04-21 13:24 ` Austin S. Hemmelgarn [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=5718D49B.3090908@gmail.com \
--to=ahferroin7@gmail.com \
--cc=anssi.hannula@bitwise.fi \
--cc=bug-track@fisher-privat.net \
--cc=hirofumi@mail.parknet.co.jp \
--cc=linux-fsdevel@vger.kernel.org \
--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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox