Re: Wrong free clusters count on FAT32
Hi Ogawa :) * OGAWA Hirofumi <[EMAIL PROTECTED]> dixit: > DervishD <[EMAIL PROTECTED]> writes: > >> It would add the limitation to following simple usage, > >> > >># mount -t vfat /dev/sda1 /mnt > >> # cp -a * /mnt > >> # umount > >> > >> if /dev/sda1 was the large and slow device, "mount" will need several > >> minutes to counts free clusters. I think the user will be hard to > >> accept the several minutes at "mount". > > > > I can carry some tests, but if Windows does that tasks lightning > > fast, Linux surely does it faster ;) I don't think, anyway, that having > > a huge USB disk is a common practice when using "modest" machines. > > > > If you want, I can perform a couple of tests. I have a 80GB disk > > that I can connect using an USB adapter and my machine is AMD Athlon XP > > 1900+ with 1GB of RAM, which looks pretty slow nowadays O:) > > Yes, I think it's not common practice too. But I don't see why do you > want to scanning at the mount. Just because I was thinking that, otherwise, the scanning would need to be done at each statfs call, but I was wrong: once the scanning is done and the count is right, it is written at free_clusters and used afterwards. I thought the mount was the best point in time for doing this. 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! - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Wrong free clusters count on FAT32
DervishD <[EMAIL PROTECTED]> writes: >> It would add the limitation to following simple usage, >> >> # mount -t vfat /dev/sda1 /mnt >> # cp -a * /mnt >> # umount >> >> if /dev/sda1 was the large and slow device, "mount" will need several >> minutes to counts free clusters. I think the user will be hard to >> accept the several minutes at "mount". > > I can carry some tests, but if Windows does that tasks lightning > fast, Linux surely does it faster ;) I don't think, anyway, that having > a huge USB disk is a common practice when using "modest" machines. > > If you want, I can perform a couple of tests. I have a 80GB disk > that I can connect using an USB adapter and my machine is AMD Athlon XP > 1900+ with 1GB of RAM, which looks pretty slow nowadays O:) Yes, I think it's not common practice too. But I don't see why do you want to scanning at the mount. Thanks. -- OGAWA Hirofumi <[EMAIL PROTECTED]> - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Wrong free clusters count on FAT32
Bodo Eggert <[EMAIL PROTECTED]> writes: >> > - usefree is a bad name (I'd suggest recalc_free instead), >> >> Is it about nofree option? > > Yes. I think recalc_free is way more descriptive. Recalc is already default on current patch. -- OGAWA Hirofumi <[EMAIL PROTECTED]> - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Wrong free clusters count on FAT32
On Sun, 22 Apr 2007, OGAWA Hirofumi wrote: > Bodo Eggert <[EMAIL PROTECTED]> writes: > > Windows _does_ care*, it will pretend the disk to be full. > > Did you test on 2000 or XP? (e.g. write 0 to free_clusters, then > create new file.) That was back when I still used W98. > > - usefree is a bad name (I'd suggest recalc_free instead), > > Is it about nofree option? Yes. I think recalc_free is way more descriptive. > > and your description is too cryptic to be understood by a non-linux > > FAT expert. > > Um... why do we need to care about non-linux people in the patch? Non-experts in Linux FAT implementation details. "recalc sounds like might take long, let's try to disable it" should be all it takes to get a fast mount. -- Top 100 things you don't want the sysadmin to say: 35. Ummm... Didn't you say you turned it off? - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Wrong free clusters count on FAT32
Hi Bodo :)
* Bodo Eggert <[EMAIL PROTECTED]> dixit:
> OGAWA Hirofumi <[EMAIL PROTECTED]> wrote:
> >> * Juergen Beisert <[EMAIL PROTECTED]> dixit:
>
> >>> So the last free sector count is also stored. When mounting this
> >>> filesystem you don't need to walk through the whole FAT to calculate
> >>> the available space, you can use this "cached" value instead. And this
> >>> cached value seems not to be updated in your portable device.
> >>
> >> It doesn't, certainly, but Windows doesn't care. Moreover, the
> >> device doesn't seem to recalculate the value on every run (unless it
> >> does it lightning fast!), so maybe the number is stored elsewhere (the
> >> count can be stored in many places as far as I've read, but I don't know
> >> the details).
>
> AFAIR it's stored twice on FAT32, once in a backup sector and once in the
> superblock or extended superblock (don't remember, I think it was the
> extended ~). It's not stored on FAT{12,16}.
I hadn't noticed the same problem with FAT16 pendrives, so I
suspected that. Thanks for confirming :)
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!
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Wrong free clusters count on FAT32
Hi Ogawa :) * OGAWA Hirofumi <[EMAIL PROTECTED]> dixit: > DervishD <[EMAIL PROTECTED]> writes: > > 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. > > No need to worry about it. If we ignored the ->free_clusters in > FSINFO, the fat drivers counts the current free clusters by scaning > FAT entries if needed. Cool! :) > > 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). > > It would add the limitation to following simple usage, > > # mount -t vfat /dev/sda1 /mnt > # cp -a * /mnt > # umount > > if /dev/sda1 was the large and slow device, "mount" will need several > minutes to counts free clusters. I think the user will be hard to > accept the several minutes at "mount". I can carry some tests, but if Windows does that tasks lightning fast, Linux surely does it faster ;) I don't think, anyway, that having a huge USB disk is a common practice when using "modest" machines. If you want, I can perform a couple of tests. I have a 80GB disk that I can connect using an USB adapter and my machine is AMD Athlon XP 1900+ with 1GB of RAM, which looks pretty slow nowadays O:) 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! - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Wrong free clusters count on FAT32
OGAWA Hirofumi <[EMAIL PROTECTED]> wrote:
> DervishD <[EMAIL PROTECTED]> writes:
>> 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).
>
> It would add the limitation to following simple usage,
>
> # mount -t vfat /dev/sda1 /mnt
> # cp -a * /mnt
> # umount
>
> if /dev/sda1 was the large and slow device, "mount" will need several
> minutes to counts free clusters. I think the user will be hard to
> accept the several minutes at "mount".
I simulated recalculating the FAT using a suboptimal perl script on my
32 GB FAT32 partition on a 40 GB drive. The results should show the worst
case for my system.
The results were below 2 seconds (optimized perl at 0.5 s) on my AMD Athlon
XP 2400+. (BTW: I don't think the device speed itself will be relevant in
many cases even if you'd asume a slow link, since you'll need to read the
FAT anyway.)
I think this is acceptable, and on this system, I'd like to enable
recalculating by default. On slower systems, you'll need to chose another
default.
I think you'll want that option as a module parameter to make all users happy.
And while you're at it, fmask and dmask are good candidates for module
parameters, too.-)
# echo 3 > /proc/sys/vm/drop_caches
# /usr/bin/time sh -c "dd if=/dev/hda2 bs=$((77834925/64)) count=4 | perl -e
'"'use POSIX;while (sysread STDIN,$x,4) {$n++ if $x eq "\0\0\0\0"} print
$n*32,"\n"'\'
4+0 records in
4+0 records out
13954720
0.76user 0.60system 0:01.95elapsed 69%CPU (0avgtext+0avgdata 0maxresident)k
0inputs+0outputs (8major+1583minor)pagefaults 0swaps
# /usr/bin/time sh -c "dd if=/dev/hda2 bs=$((77834925/64)) count=4 | perl -e
'"'use POSIX;while (sysread STDIN,$x,4) {$n++ if $x eq "\0\0\0\0"} print
$n*32,"\n"'\'
4+0 records in
4+0 records out
13955392
0.74user 0.69system 0:01.50elapsed 95%CPU (0avgtext+0avgdata 0maxresident)k
0inputs+0outputs (0major+1591minor)pagefaults 0swaps
# /usr/bin/time sh -c "dd if=/dev/hda2 bs=$((77834925/64)) count=4 | perl -e
'"'use POSIX;while (sysread STDIN,$x,4096) {for (unpack "L*",$x){$n++ if !$_}}
print $n*32,"\n"'\'
4+0 records in
4+0 records out
13955392
0.43user 0.06system 0:00.50elapsed 97%CPU (0avgtext+0avgdata 0maxresident)k
0inputs+0outputs (0major+1599minor)pagefaults 0swaps
--
The worse the weather, the more you are required to be out in it.
Friß, Spammer: [EMAIL PROTECTED] [EMAIL PROTECTED]
[EMAIL PROTECTED] [EMAIL PROTECTED]
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Wrong free clusters count on FAT32
Bodo Eggert <[EMAIL PROTECTED]> writes:
> # /usr/bin/time sh -c "dd if=/dev/hda2 bs=$((77834925/64)) count=4 | perl -e
> '"'use POSIX;while (sysread STDIN,$x,4) {$n++ if $x eq "\0\0\0\0"} print
> $n*32,"\n"'\'
> 4+0 records in
> 4+0 records out
> 13954720
> 0.76user 0.60system 0:01.95elapsed 69%CPU (0avgtext+0avgdata 0maxresident)k
> 0inputs+0outputs (8major+1583minor)pagefaults 0swaps
dd will use readahead, and I'm thinking about usb. Well, anyway,
recalc is default in new patch.
Thanks.
--
OGAWA Hirofumi <[EMAIL PROTECTED]>
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Wrong free clusters count on FAT32
OGAWA Hirofumi <[EMAIL PROTECTED]> wrote:
>> * Juergen Beisert <[EMAIL PROTECTED]> dixit:
>>> So the last free sector count is also stored. When mounting this
>>> filesystem you don't need to walk through the whole FAT to calculate
>>> the available space, you can use this "cached" value instead. And this
>>> cached value seems not to be updated in your portable device.
>>
>> It doesn't, certainly, but Windows doesn't care. Moreover, the
>> device doesn't seem to recalculate the value on every run (unless it
>> does it lightning fast!), so maybe the number is stored elsewhere (the
>> count can be stored in many places as far as I've read, but I don't know
>> the details).
AFAIR it's stored twice on FAT32, once in a backup sector and once in the
superblock or extended superblock (don't remember, I think it was the
extended ~). It's not stored on FAT{12,16}.
>> A mount option to force walking the FAT and getting the real info
>> could be interesting. That way, it will be only done for certain devices
>> (small disks, for example).
>
> Yes. It seems that Windows does not update the ->free_clusters correctly.
> Probably, I think the option is good for now. What do you think about
> an attached patch?
Windows _does_ care*, it will pretend the disk to be full. Therefore the
stored value *SHOULD* be updated. (I think your patch does this.)
Recalculating the free space is a nice idea, and modern hardware might be
fast enough to recalculate the value on mount by default. (I didn't try this
for years.) Maybe the default should depend on arch?
About this patch: (news:[EMAIL PROTECTED])
- usefree is a bad name (I'd suggest recalc_free instead), and your
description is too cryptic to be understood by a non-linux FAT expert.
- You forgot to update Documentation/
--
Never forget: 2 + 2 = 5 for extremely large values of 2.
Friß, Spammer: [EMAIL PROTECTED] [EMAIL PROTECTED]
[EMAIL PROTECTED] [EMAIL PROTECTED]
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Wrong free clusters count on FAT32
Andreas Schwab <[EMAIL PROTECTED]> writes:
> OGAWA Hirofumi <[EMAIL PROTECTED]> writes:
>
>> diff -puN
>> Documentation/filesystems/vfat.txt~fat_dont-use_free_clusters-for-fat32
>> Documentation/filesystems/vfat.txt
>> ---
>> linux-2.6/Documentation/filesystems/vfat.txt~fat_dont-use_free_clusters-for-fat32
>> 2007-04-22 23:06:21.0 +0900
>> +++ linux-2.6-hirofumi/Documentation/filesystems/vfat.txt2007-04-22
>> 23:28:19.0 +0900
>> @@ -34,6 +34,13 @@ iocharset=name -- Character set to use f
>> NOTE: "iocharset=utf8" is not recommended. If unsure,
>> you should consider the following option instead.
>
> "the following option" is no longer correct.
Whoops. Thanks for correcting it.
The patch was fixed.
--
OGAWA Hirofumi <[EMAIL PROTECTED]>
It seems that the recent Windows changed specification, and it's
undocumented. Windows doesn't update ->free_clusters correctly.
This patch doesn't use ->free_clusters by default. (instead, add
"usefree" for forcing to use it)
Signed-off-by: OGAWA Hirofumi <[EMAIL PROTECTED]>
---
Documentation/filesystems/vfat.txt |7 +++
fs/fat/inode.c | 14 +++---
include/linux/msdos_fs.h |3 ++-
3 files changed, 20 insertions(+), 4 deletions(-)
diff -puN fs/fat/inode.c~fat_dont-use_free_clusters-for-fat32 fs/fat/inode.c
--- linux-2.6/fs/fat/inode.c~fat_dont-use_free_clusters-for-fat32
2007-04-22 13:07:05.0 +0900
+++ linux-2.6-hirofumi/fs/fat/inode.c 2007-04-22 13:18:07.0 +0900
@@ -825,6 +825,8 @@ static int fat_show_options(struct seq_f
}
if (opts->name_check != 'n')
seq_printf(m, ",check=%c", opts->name_check);
+ if (opts->usefree)
+ seq_puts(m, ",usefree");
if (opts->quiet)
seq_puts(m, ",quiet");
if (opts->showexec)
@@ -850,7 +852,7 @@ static int fat_show_options(struct seq_f
enum {
Opt_check_n, Opt_check_r, Opt_check_s, Opt_uid, Opt_gid,
- Opt_umask, Opt_dmask, Opt_fmask, Opt_codepage, Opt_nocase,
+ Opt_umask, Opt_dmask, Opt_fmask, Opt_codepage, Opt_usefree, Opt_nocase,
Opt_quiet, Opt_showexec, Opt_debug, Opt_immutable,
Opt_dots, Opt_nodots,
Opt_charset, Opt_shortname_lower, Opt_shortname_win95,
@@ -872,6 +874,7 @@ static match_table_t fat_tokens = {
{Opt_dmask, "dmask=%o"},
{Opt_fmask, "fmask=%o"},
{Opt_codepage, "codepage=%u"},
+ {Opt_usefree, "usefree"},
{Opt_nocase, "nocase"},
{Opt_quiet, "quiet"},
{Opt_showexec, "showexec"},
@@ -951,7 +954,7 @@ static int parse_options(char *options,
opts->quiet = opts->showexec = opts->sys_immutable = opts->dotsOK = 0;
opts->utf8 = opts->unicode_xlate = 0;
opts->numtail = 1;
- opts->nocase = 0;
+ opts->usefree = opts->nocase = 0;
*debug = 0;
if (!options)
@@ -979,6 +982,9 @@ static int parse_options(char *options,
case Opt_check_n:
opts->name_check = 'n';
break;
+ case Opt_usefree:
+ opts->usefree = 1;
+ break;
case Opt_nocase:
if (!is_vfat)
opts->nocase = 1;
@@ -1306,7 +1312,9 @@ int fat_fill_super(struct super_block *s
le32_to_cpu(fsinfo->signature2),
sbi->fsinfo_sector);
} else {
- sbi->free_clusters = le32_to_cpu(fsinfo->free_clusters);
+ if (sbi->options.usefree)
+ sbi->free_clusters =
+ le32_to_cpu(fsinfo->free_clusters);
sbi->prev_free = le32_to_cpu(fsinfo->next_cluster);
}
diff -puN include/linux/msdos_fs.h~fat_dont-use_free_clusters-for-fat32
include/linux/msdos_fs.h
--- linux-2.6/include/linux/msdos_fs.h~fat_dont-use_free_clusters-for-fat32
2007-04-22 13:07:05.0 +0900
+++ linux-2.6-hirofumi/include/linux/msdos_fs.h 2007-04-22 13:09:14.0
+0900
@@ -205,7 +205,8 @@ struct fat_mount_options {
numtail:1, /* Does first alias have a numeric '~1' type
tail? */
atari:1, /* Use Atari GEMDOS variation of MS-DOS fs */
flush:1, /* write things quickly */
-nocase:1;/* Does this need case conversion? 0=need
case conversion*/
+nocase:1,/* Does this need case conversion? 0=need
case conversion*/
+usefree:1; /* Use free_clusters for FAT32 */
};
#define FAT_HASH_BITS 8
diff -puN
Documentation/filesystems/vfat.txt~fat_dont-use_free_clusters-for-fat32
Documentation/filesystems/vfat.txt
---
linux-2.6/Documentation/filesystems/vfat.txt~fat_dont-use_free_clusters-for-fat32
2007-04-22
Re: Wrong free clusters count on FAT32
OGAWA Hirofumi <[EMAIL PROTECTED]> writes:
>> - You forgot to update Documentation/
>
> Sure. If you can post the patch, it'll be great.
Updated patch is here.
Thanks.
--
OGAWA Hirofumi <[EMAIL PROTECTED]>
It seems that the recent Windows changed specification, and it's
undocumented. Windows doesn't update ->free_clusters correctly.
This patch doesn't use ->free_clusters by default. (instead, add
"usefree" for forcing to use it)
Signed-off-by: OGAWA Hirofumi <[EMAIL PROTECTED]>
---
Documentation/filesystems/vfat.txt |7 +++
fs/fat/inode.c | 14 +++---
include/linux/msdos_fs.h |3 ++-
3 files changed, 20 insertions(+), 4 deletions(-)
diff -puN fs/fat/inode.c~fat_dont-use_free_clusters-for-fat32 fs/fat/inode.c
--- linux-2.6/fs/fat/inode.c~fat_dont-use_free_clusters-for-fat32
2007-04-22 13:07:05.0 +0900
+++ linux-2.6-hirofumi/fs/fat/inode.c 2007-04-22 13:18:07.0 +0900
@@ -825,6 +825,8 @@ static int fat_show_options(struct seq_f
}
if (opts->name_check != 'n')
seq_printf(m, ",check=%c", opts->name_check);
+ if (opts->usefree)
+ seq_puts(m, ",usefree");
if (opts->quiet)
seq_puts(m, ",quiet");
if (opts->showexec)
@@ -850,7 +852,7 @@ static int fat_show_options(struct seq_f
enum {
Opt_check_n, Opt_check_r, Opt_check_s, Opt_uid, Opt_gid,
- Opt_umask, Opt_dmask, Opt_fmask, Opt_codepage, Opt_nocase,
+ Opt_umask, Opt_dmask, Opt_fmask, Opt_codepage, Opt_usefree, Opt_nocase,
Opt_quiet, Opt_showexec, Opt_debug, Opt_immutable,
Opt_dots, Opt_nodots,
Opt_charset, Opt_shortname_lower, Opt_shortname_win95,
@@ -872,6 +874,7 @@ static match_table_t fat_tokens = {
{Opt_dmask, "dmask=%o"},
{Opt_fmask, "fmask=%o"},
{Opt_codepage, "codepage=%u"},
+ {Opt_usefree, "usefree"},
{Opt_nocase, "nocase"},
{Opt_quiet, "quiet"},
{Opt_showexec, "showexec"},
@@ -951,7 +954,7 @@ static int parse_options(char *options,
opts->quiet = opts->showexec = opts->sys_immutable = opts->dotsOK = 0;
opts->utf8 = opts->unicode_xlate = 0;
opts->numtail = 1;
- opts->nocase = 0;
+ opts->usefree = opts->nocase = 0;
*debug = 0;
if (!options)
@@ -979,6 +982,9 @@ static int parse_options(char *options,
case Opt_check_n:
opts->name_check = 'n';
break;
+ case Opt_usefree:
+ opts->usefree = 1;
+ break;
case Opt_nocase:
if (!is_vfat)
opts->nocase = 1;
@@ -1306,7 +1312,9 @@ int fat_fill_super(struct super_block *s
le32_to_cpu(fsinfo->signature2),
sbi->fsinfo_sector);
} else {
- sbi->free_clusters = le32_to_cpu(fsinfo->free_clusters);
+ if (sbi->options.usefree)
+ sbi->free_clusters =
+ le32_to_cpu(fsinfo->free_clusters);
sbi->prev_free = le32_to_cpu(fsinfo->next_cluster);
}
diff -puN include/linux/msdos_fs.h~fat_dont-use_free_clusters-for-fat32
include/linux/msdos_fs.h
--- linux-2.6/include/linux/msdos_fs.h~fat_dont-use_free_clusters-for-fat32
2007-04-22 13:07:05.0 +0900
+++ linux-2.6-hirofumi/include/linux/msdos_fs.h 2007-04-22 13:09:14.0
+0900
@@ -205,7 +205,8 @@ struct fat_mount_options {
numtail:1, /* Does first alias have a numeric '~1' type
tail? */
atari:1, /* Use Atari GEMDOS variation of MS-DOS fs */
flush:1, /* write things quickly */
-nocase:1;/* Does this need case conversion? 0=need
case conversion*/
+nocase:1,/* Does this need case conversion? 0=need
case conversion*/
+usefree:1; /* Use free_clusters for FAT32 */
};
#define FAT_HASH_BITS 8
diff -puN
Documentation/filesystems/vfat.txt~fat_dont-use_free_clusters-for-fat32
Documentation/filesystems/vfat.txt
---
linux-2.6/Documentation/filesystems/vfat.txt~fat_dont-use_free_clusters-for-fat32
2007-04-22 23:06:21.0 +0900
+++ linux-2.6-hirofumi/Documentation/filesystems/vfat.txt 2007-04-22
23:28:19.0 +0900
@@ -34,6 +34,13 @@ iocharset=name -- Character set to use f
NOTE: "iocharset=utf8" is not recommended. If unsure,
you should consider the following option instead.
+usefree -- Use the "free clusters" value stored on FSINFO. It'll
+ be used to determine number of free clusters without
+ scanning disk. But it's not used by default, because
+ recent Windows don't update it correctly
Re: Wrong free clusters count on FAT32
OGAWA Hirofumi <[EMAIL PROTECTED]> writes: > diff -puN > Documentation/filesystems/vfat.txt~fat_dont-use_free_clusters-for-fat32 > Documentation/filesystems/vfat.txt > --- > linux-2.6/Documentation/filesystems/vfat.txt~fat_dont-use_free_clusters-for-fat32 > 2007-04-22 23:06:21.0 +0900 > +++ linux-2.6-hirofumi/Documentation/filesystems/vfat.txt 2007-04-22 > 23:28:19.0 +0900 > @@ -34,6 +34,13 @@ iocharset=name -- Character set to use f >NOTE: "iocharset=utf8" is not recommended. If unsure, >you should consider the following option instead. "the following option" is no longer correct. > > +usefree -- Use the "free clusters" value stored on FSINFO. It'll > + be used to determine number of free clusters without > + scanning disk. But it's not used by default, because > + recent Windows don't update it correctly in some > + case. If you are sure the "free clusters" on FSINFO is > + correct, by this option you can avoid scanning disk. > + > utf8= -- UTF-8 is the filesystem safe version of Unicode that >is used by the console. It can be enabled for the >filesystem with this option. If 'uni_xlate' gets set, Andreas. -- Andreas Schwab, SuSE Labs, [EMAIL PROTECTED] SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany PGP key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different." - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Wrong free clusters count on FAT32
Bodo Eggert <[EMAIL PROTECTED]> writes: > Windows _does_ care*, it will pretend the disk to be full. Did you test on 2000 or XP? (e.g. write 0 to free_clusters, then create new file.) > - usefree is a bad name (I'd suggest recalc_free instead), Is it about nofree option? > and your description is too cryptic to be understood by a non-linux > FAT expert. Um... why do we need to care about non-linux people in the patch? Anyway, if you correct it, I'll update it gladly. > - You forgot to update Documentation/ Sure. If you can post the patch, it'll be great. Thanks. -- OGAWA Hirofumi <[EMAIL PROTECTED]> - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Wrong free clusters count on FAT32
DervishD <[EMAIL PROTECTED]> writes: > 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. No need to worry about it. If we ignored the ->free_clusters in FSINFO, the fat drivers counts the current free clusters by scaning FAT entries if needed. > 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). It would add the limitation to following simple usage, # mount -t vfat /dev/sda1 /mnt # cp -a * /mnt # umount if /dev/sda1 was the large and slow device, "mount" will need several minutes to counts free clusters. I think the user will be hard to accept the several minutes at "mount". Thanks. -- OGAWA Hirofumi <[EMAIL PROTECTED]> - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Wrong free clusters count on FAT32
Hi, On Sunday 22 April 2007 00:42, OGAWA Hirofumi wrote: > Yes. It seems that Windows does not update the ->free_clusters correctly. > Probably, I think the option is good for now. What do you think about > an attached patch? Please don't ask me, because I'm not a filesystem expert. Sorry. My suggestion was only a tiny idea. Juergen - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Wrong free clusters count on FAT32
Hi Ogawa (and Andrew) :) * OGAWA Hirofumi <[EMAIL PROTECTED]> dixit: > Andrew Morton <[EMAIL PROTECTED]> 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! - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Wrong free clusters count on FAT32
Hi Ogawa :) * OGAWA Hirofumi <[EMAIL PROTECTED]> dixit: > DervishD <[EMAIL PROTECTED]> writes: > > A mount option to force walking the FAT and getting the real > > info could be interesting. That way, it will be only done for > > certain devices (small disks, for example). > > Yes. It seems that Windows does not update the ->free_clusters > correctly. Probably, I think the option is good for now. What do you > think about an attached patch? The option ignores ->free_clusters by default, am I wrong? I'm not sure about this: given that nobody cared before, chances are that this problem didn't bite anyone, so I think that the default behaviour should be the _old_ behaviour (that is, nofree=0, as if the option never existed). Moreover, I'm not sure if Windows updates correctly or not the free_clustes FSINFO entry, this problem has happened (by now) in a portable device only. What I can ensure is that both the portable device and any Windows box I've tested ignores this value and properly calculate the real free space. Linux doesn't because it relies on an invalid value. Again, the fault is in the portable device, but the workaround seems common practice out there... So I will suggest just "nofree:0" instead of "nofree:1". And thanks a lot for the patch :))) I'm not sure about this: given that nobody cared before, chances are that this problem didn't bite anyone, so I think that the default behaviour should be the _old_ behaviour (that is, nofree=0, as if the option never existed). Moreover, I'm not sure if Windows updates correctly or not the free_clustes FSINFO entry, this problem has happened (by now) in a portable device only. What I can ensure is that both the portable device and any Windows box I've tested ignores this value and properly calculate the real free space. Linux doesn't because it relies on an invalid value. Again, the fault is in the portable device, but the workaround seems common practice out there... So I will suggest just "nofree:0" instead of "nofree:1". And thanks a lot for the patch :))) 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! - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Wrong free clusters count on FAT32
Andrew Morton <[EMAIL PROTECTED]> writes:
> On Sun, 22 Apr 2007 07:42:22 +0900 OGAWA Hirofumi <[EMAIL PROTECTED]> wrote:
>
>> Recent Windows doesn't update ->free_clusters correctly. The "nofree"
>> option ignores the ->free_clusters stored on FSINFO.
>
> It'd be better to avoid the new mount option if possible: fatfs is used by
> a *lot* of people who aren't particualrly expert, and we want to make things
> easy for them.
Ok.
> 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.)
This patch doesn't use ->free_clusters by default. (instead, add
"usefree" for forcing to use it)
--
OGAWA Hirofumi <[EMAIL PROTECTED]>
It seems that the recent Windows changed specification, and it's
undocumented. Windows doesn't update ->free_clusters correctly.
This patch doesn't use ->free_clusters by default. (instead, add
"usefree" for forcing to use it)
Signed-off-by: OGAWA Hirofumi <[EMAIL PROTECTED]>
---
fs/fat/inode.c | 14 +++---
include/linux/msdos_fs.h |3 ++-
2 files changed, 13 insertions(+), 4 deletions(-)
diff -puN fs/fat/inode.c~fat_dont-use_free_clusters-for-fat32 fs/fat/inode.c
--- linux-2.6/fs/fat/inode.c~fat_dont-use_free_clusters-for-fat32 2007-04-22 13:07:05.0 +0900
+++ linux-2.6-hirofumi/fs/fat/inode.c 2007-04-22 13:18:07.0 +0900
@@ -825,6 +825,8 @@ static int fat_show_options(struct seq_f
}
if (opts->name_check != 'n')
seq_printf(m, ",check=%c", opts->name_check);
+ if (opts->usefree)
+ seq_puts(m, ",usefree");
if (opts->quiet)
seq_puts(m, ",quiet");
if (opts->showexec)
@@ -850,7 +852,7 @@ static int fat_show_options(struct seq_f
enum {
Opt_check_n, Opt_check_r, Opt_check_s, Opt_uid, Opt_gid,
- Opt_umask, Opt_dmask, Opt_fmask, Opt_codepage, Opt_nocase,
+ Opt_umask, Opt_dmask, Opt_fmask, Opt_codepage, Opt_usefree, Opt_nocase,
Opt_quiet, Opt_showexec, Opt_debug, Opt_immutable,
Opt_dots, Opt_nodots,
Opt_charset, Opt_shortname_lower, Opt_shortname_win95,
@@ -872,6 +874,7 @@ static match_table_t fat_tokens = {
{Opt_dmask, "dmask=%o"},
{Opt_fmask, "fmask=%o"},
{Opt_codepage, "codepage=%u"},
+ {Opt_usefree, "usefree"},
{Opt_nocase, "nocase"},
{Opt_quiet, "quiet"},
{Opt_showexec, "showexec"},
@@ -951,7 +954,7 @@ static int parse_options(char *options,
opts->quiet = opts->showexec = opts->sys_immutable = opts->dotsOK = 0;
opts->utf8 = opts->unicode_xlate = 0;
opts->numtail = 1;
- opts->nocase = 0;
+ opts->usefree = opts->nocase = 0;
*debug = 0;
if (!options)
@@ -979,6 +982,9 @@ static int parse_options(char *options,
case Opt_check_n:
opts->name_check = 'n';
break;
+ case Opt_usefree:
+ opts->usefree = 1;
+ break;
case Opt_nocase:
if (!is_vfat)
opts->nocase = 1;
@@ -1306,7 +1312,9 @@ int fat_fill_super(struct super_block *s
le32_to_cpu(fsinfo->signature2),
sbi->fsinfo_sector);
} else {
- sbi->free_clusters = le32_to_cpu(fsinfo->free_clusters);
+ if (sbi->options.usefree)
+sbi->free_clusters =
+ le32_to_cpu(fsinfo->free_clusters);
sbi->prev_free = le32_to_cpu(fsinfo->next_cluster);
}
diff -puN include/linux/msdos_fs.h~fat_dont-use_free_clusters-for-fat32 include/linux/msdos_fs.h
--- linux-2.6/include/linux/msdos_fs.h~fat_dont-use_free_clusters-for-fat32 2007-04-22 13:07:05.0 +0900
+++ linux-2.6-hirofumi/include/linux/msdos_fs.h 2007-04-22 13:09:14.0 +0900
@@ -205,7 +205,8 @@ struct fat_mount_options {
numtail:1, /* Does first alias have a numeric '~1' type tail? */
atari:1, /* Use Atari GEMDOS variation of MS-DOS fs */
flush:1, /* write things quickly */
- nocase:1; /* Does this need case conversion? 0=need case conversion*/
+ nocase:1, /* Does this need case conversion? 0=need case conversion*/
+ usefree:1; /* Use free_clusters for FAT32 */
};
#define FAT_HASH_BITS 8
_
Re: Wrong free clusters count on FAT32
On Sun, 22 Apr 2007 07:42:22 +0900 OGAWA Hirofumi <[EMAIL PROTECTED]> wrote: > Recent Windows doesn't update ->free_clusters correctly. The "nofree" > option ignores the ->free_clusters stored on FSINFO. It'd be better to avoid the new mount option if possible: fatfs is used by a *lot* of people who aren't particualrly expert, and we want to make things easy for them. Is there some way in which we can work out what's happened and fix it up? - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Wrong free clusters count on FAT32
DervishD <[EMAIL PROTECTED]> writes:
> * Juergen Beisert <[EMAIL PROTECTED]> dixit:
>> On Thursday 19 April 2007 10:57, DervishD wrote:
>> > I have a portable device with a FAT32 formatted hard disk in it, and
>> > everytime I delete a file in the device *using the device itself to
>> > do it* the device increases its count of free space and if I plug
>> > the device in a Windows system, Windows agrees on the free space.
>> > Linux doesn't. Linux believes that the files are still there
>> > ocuppying space, and I have to run fsck.vfat to fix the problem.
>>
>> As I remember: It needs a large amount of time to calculate the free
>> space on a big FAT32 system.
>
> Big fat truth, I'm afraid. The thing is that I thought that Linux
> did that from time to time to update the count. Obviously, doing it for
> every statfs call would be very expensive :((
>
>> So the last free sector count is also stored. When mounting this
>> filesystem you don't need to walk through the whole FAT to calculate
>> the available space, you can use this "cached" value instead. And this
>> cached value seems not to be updated in your portable device.
>
> It doesn't, certainly, but Windows doesn't care. Moreover, the
> device doesn't seem to recalculate the value on every run (unless it
> does it lightning fast!), so maybe the number is stored elsewhere (the
> count can be stored in many places as far as I've read, but I don't know
> the details).
>
> A mount option to force walking the FAT and getting the real info
> could be interesting. That way, it will be only done for certain devices
> (small disks, for example).
Yes. It seems that Windows does not update the ->free_clusters correctly.
Probably, I think the option is good for now. What do you think about
an attached patch?
--
OGAWA Hirofumi <[EMAIL PROTECTED]>
Recent Windows doesn't update ->free_clusters correctly. The "nofree"
option ignores the ->free_clusters stored on FSINFO.
Signed-off-by: OGAWA Hirofumi <[EMAIL PROTECTED]>
---
fs/fat/inode.c | 13 ++---
include/linux/msdos_fs.h |3 ++-
2 files changed, 12 insertions(+), 4 deletions(-)
diff -puN fs/fat/inode.c~fat_ignore_free_clusters fs/fat/inode.c
--- linux-2.6/fs/fat/inode.c~fat_ignore_free_clusters 2007-04-22 07:30:13.0 +0900
+++ linux-2.6-hirofumi/fs/fat/inode.c 2007-04-22 07:30:13.0 +0900
@@ -825,6 +825,8 @@ static int fat_show_options(struct seq_f
}
if (opts->name_check != 'n')
seq_printf(m, ",check=%c", opts->name_check);
+ if (opts->nofree)
+ seq_puts(m, ",nofree");
if (opts->quiet)
seq_puts(m, ",quiet");
if (opts->showexec)
@@ -850,7 +852,7 @@ static int fat_show_options(struct seq_f
enum {
Opt_check_n, Opt_check_r, Opt_check_s, Opt_uid, Opt_gid,
- Opt_umask, Opt_dmask, Opt_fmask, Opt_codepage, Opt_nocase,
+ Opt_umask, Opt_dmask, Opt_fmask, Opt_codepage, Opt_nofree, Opt_nocase,
Opt_quiet, Opt_showexec, Opt_debug, Opt_immutable,
Opt_dots, Opt_nodots,
Opt_charset, Opt_shortname_lower, Opt_shortname_win95,
@@ -872,6 +874,7 @@ static match_table_t fat_tokens = {
{Opt_dmask, "dmask=%o"},
{Opt_fmask, "fmask=%o"},
{Opt_codepage, "codepage=%u"},
+ {Opt_nofree, "nofree"},
{Opt_nocase, "nocase"},
{Opt_quiet, "quiet"},
{Opt_showexec, "showexec"},
@@ -951,7 +954,7 @@ static int parse_options(char *options,
opts->quiet = opts->showexec = opts->sys_immutable = opts->dotsOK = 0;
opts->utf8 = opts->unicode_xlate = 0;
opts->numtail = 1;
- opts->nocase = 0;
+ opts->nofree = opts->nocase = 0;
*debug = 0;
if (!options)
@@ -979,6 +982,9 @@ static int parse_options(char *options,
case Opt_check_n:
opts->name_check = 'n';
break;
+ case Opt_nofree:
+ opts->nofree = 1;
+ break;
case Opt_nocase:
if (!is_vfat)
opts->nocase = 1;
@@ -1352,7 +1358,8 @@ int fat_fill_super(struct super_block *s
sbi->max_cluster = total_clusters + FAT_START_ENT;
/* check the free_clusters, it's not necessarily correct */
- if (sbi->free_clusters != -1 && sbi->free_clusters > total_clusters)
+ if ((sbi->free_clusters != -1 && sbi->free_clusters > total_clusters) ||
+ sbi->options.nofree)
sbi->free_clusters = -1;
/* check the prev_free, it's not necessarily correct */
sbi->prev_free %= sbi->max_cluster;
diff -puN include/linux/msdos_fs.h~fat_ignore_free_clusters include/linux/msdos_fs.h
--- linux-2.6/include/linux/msdos_fs.h~fat_ignore_free_clusters 2007-04-22 07:30:13.0 +0900
+++ linux-2.6-hirofumi/include/linux/msdos_fs.h 2007-04-22 07:30:13.0 +0900
@@ -205,7 +205,8 @@ struct fat_mount_options {
numtail:1, /* Does first alias have a numeric '~1' type tail? */
atari:1, /* Use Atari GEMDOS variation of MS-DOS fs */
flush:1, /* write things quickly */
- nocase:1; /* Does this need case conversion? 0=need case conversion*/
+ nocase:1, /* Does this need case conversion? 0=need case conversion*/
+ nofree:1; /* Does use free_clusters */
};
#define FAT
Re: Wrong free clusters count on FAT32
Hi Boaz :) * Boaz Harrosh <[EMAIL PROTECTED]> dixit: > > Apart from not using the device itself to delete files (and probably > > not using Windows for that, either) and to run fsck.vfat now and > > then, is anything I can do to avoid this problem? > > > Not that I know how to fix it. But have you tried running chkdsk on a > device deleted files in windows. Just that I know, that windows would > silently ignore fat errors and will only report them in chkdsk. I've done that and the problem is not fixed. I have to use fsck.vfat instead. > Deleting files in windows works fine. There is no problems with it and > windows updates everything. I do that all the time. True, I've tested it, too. I'm going to report the problem to the device manufacturer (it's a Cowon iAUDIO), but probably doing it in the device will be very slow :( > (I would even theorize that if you delete files on the device and than > farther delete more files on windows, than windows will fix the > problem on the fly) Probably, and it may be a good fix, but I seldom plug the device on Windows. Thanks for the answer :) 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! - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Wrong free clusters count on FAT32
Hi Juergen :) * Juergen Beisert <[EMAIL PROTECTED]> dixit: > On Thursday 19 April 2007 10:57, DervishD wrote: > > I have a portable device with a FAT32 formatted hard disk in it, and > > everytime I delete a file in the device *using the device itself to > > do it* the device increases its count of free space and if I plug > > the device in a Windows system, Windows agrees on the free space. > > Linux doesn't. Linux believes that the files are still there > > ocuppying space, and I have to run fsck.vfat to fix the problem. > > As I remember: It needs a large amount of time to calculate the free > space on a big FAT32 system. Big fat truth, I'm afraid. The thing is that I thought that Linux did that from time to time to update the count. Obviously, doing it for every statfs call would be very expensive :(( > So the last free sector count is also stored. When mounting this > filesystem you don't need to walk through the whole FAT to calculate > the available space, you can use this "cached" value instead. And this > cached value seems not to be updated in your portable device. It doesn't, certainly, but Windows doesn't care. Moreover, the device doesn't seem to recalculate the value on every run (unless it does it lightning fast!), so maybe the number is stored elsewhere (the count can be stored in many places as far as I've read, but I don't know the details). A mount option to force walking the FAT and getting the real info could be interesting. That way, it will be only done for certain devices (small disks, for example). Thanks for your answer :) 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! - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Wrong free clusters count on FAT32
On Thursday 19 April 2007 10:57, DervishD wrote: > I have a portable device with a FAT32 formatted hard disk in it, and > everytime I delete a file in the device *using the device itself to do > it* the device increases its count of free space and if I plug the > device in a Windows system, Windows agrees on the free space. Linux > doesn't. Linux believes that the files are still there ocuppying space, > and I have to run fsck.vfat to fix the problem. As I remember: It needs a large amount of time to calculate the free space on a big FAT32 system. So the last free sector count is also stored. When mounting this filesystem you don't need to walk through the whole FAT to calculate the available space, you can use this "cached" value instead. And this cached value seems not to be updated in your portable device. Maybe it helps, but maybe I'm wrong. Juergen - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Wrong free clusters count on FAT32
DervishD wrote: > Hi all :) > > I have a portable device with a FAT32 formatted hard disk in it, and > everytime I delete a file in the device *using the device itself to do > it* the device increases its count of free space and if I plug the > device in a Windows system, Windows agrees on the free space. Linux > doesn't. Linux believes that the files are still there ocuppying space, > and I have to run fsck.vfat to fix the problem. > > As far as I've seen, the device is probably not updating correctly > the list of free clusters, but it doesn't seem to worry about it, > neither does Windows. So my question is: is there any way of making > Linux "bug compatible" with Windows? If Windows itself don't worry about > the free cluster count and computes the free space in some other way, > then it can be done. I haven't seen anything in mount(8) neither > googling. > > Apart from not using the device itself to delete files (and probably > not using Windows for that, either) and to run fsck.vfat now and then, > is anything I can do to avoid this problem? > > Thanks a lot in advance :) > > Raúl Núñez de Arenas Coronado > Not that I know how to fix it. But have you tried running chkdsk on a device deleted files in windows. Just that I know, that windows would silently ignore fat errors and will only report them in chkdsk. Deleting files in windows works fine. There is no problems with it and windows updates everything. I do that all the time. (I would even theorize that if you delete files on the device and than farther delete more files on windows, than windows will fix the problem on the fly) So it is "bug compatible" with the device, and error recovery compatible with windows. Boaz - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
