From: DervishD <lkml@dervishd.net>
To: OGAWA Hirofumi <hirofumi@mail.parknet.co.jp>
Cc: Andrew Morton <akpm@linux-foundation.org>,
Juergen Beisert <juergen127@kreuzholzen.de>,
linux-kernel@vger.kernel.org
Subject: Re: Wrong free clusters count on FAT32
Date: Sun, 22 Apr 2007 13:26:58 +0200 [thread overview]
Message-ID: <20070422112658.GB5786@DervishD> (raw)
In-Reply-To: <87wt05vxu7.fsf@duaron.myhome.or.jp>
Hi Ogawa (and Andrew) :)
* OGAWA Hirofumi <hirofumi@mail.parknet.co.jp> dixit:
> Andrew Morton <akpm@linux-foundation.org> writes:
> > Is there some way in which we can work out what's happened and fix
> > it up?
>
> It seems that the recent Windows changed specification, and it's
> undocumented. Windows doesn't update ->free_clusters correctly.
>
> Probably, what we can do is to throw away speed of statfs(2) and not
> using ->free_clusters. (And if possible, recover it by optimization.)
Even if Windows updates ->free_clusters correctly, it doesn't even
consider it to compute the number of free clusters, and IMHO Linux
should do the same. If speed is a concern, ->free_clusters can be
computed at mount time. That way statfs won't slow.
The problem is that if a program writes a file onto the filesystem
without using statfs first to check for free space, the free_clusters
entry won't have the real value and the driver may report "disk full" (I
haven't read the code for the vfat driver, sorry, so I'm not sure about
this) when really there are plenty of clusters to write the new file.
Probably it's stupid to update the free clusters count at mount time
(sorry if so...) but it looks like a good idea to me. And of course, I
don't mean to update the value _on disk_, but the kernel's idea of free
clusters (so even FAT filesystems mounted R/O will report correct
values).
Raúl Núñez de Arenas Coronado
--
Linux Registered User 88736 | http://www.dervishd.net
It's my PC and I'll cry if I want to... RAmen!
next prev parent reply other threads:[~2007-04-22 11:25 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-04-19 8:57 Wrong free clusters count on FAT32 DervishD
2007-04-19 10:27 ` Boaz Harrosh
2007-04-19 14:23 ` DervishD
2007-04-19 11:52 ` Juergen Beisert
2007-04-19 14:19 ` DervishD
2007-04-21 22:42 ` OGAWA Hirofumi
2007-04-22 3:18 ` Andrew Morton
2007-04-22 4:26 ` OGAWA Hirofumi
2007-04-22 11:26 ` DervishD [this message]
2007-04-22 11:55 ` OGAWA Hirofumi
2007-04-22 20:08 ` DervishD
2007-04-23 2:27 ` OGAWA Hirofumi
2007-04-23 6:19 ` DervishD
2007-04-22 11:17 ` DervishD
2007-04-22 11:28 ` Juergen Beisert
[not found] <8bAF0-3Yj-29@gated-at.bofh.it>
[not found] ` <8bDta-8rc-31@gated-at.bofh.it>
[not found] ` <8bFEr-3B4-1@gated-at.bofh.it>
[not found] ` <8cwz8-2fE-13@gated-at.bofh.it>
2007-04-22 13:28 ` Bodo Eggert
2007-04-22 14:04 ` OGAWA Hirofumi
2007-04-22 14:29 ` OGAWA Hirofumi
2007-04-22 14:53 ` Andreas Schwab
2007-04-22 15:13 ` OGAWA Hirofumi
2007-04-22 21:46 ` Bodo Eggert
2007-04-23 2:20 ` OGAWA Hirofumi
2007-04-22 20:11 ` DervishD
[not found] ` <8cAMl-du-3@gated-at.bofh.it>
[not found] ` <8cBS7-1Qa-1@gated-at.bofh.it>
[not found] ` <8cIqE-3qZ-9@gated-at.bofh.it>
[not found] ` <8cITG-40H-5@gated-at.bofh.it>
2007-04-22 17:21 ` Bodo Eggert
2007-04-22 17:44 ` OGAWA Hirofumi
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=20070422112658.GB5786@DervishD \
--to=lkml@dervishd.net \
--cc=akpm@linux-foundation.org \
--cc=hirofumi@mail.parknet.co.jp \
--cc=juergen127@kreuzholzen.de \
--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