FAT fs sanity check patch

FAT fs sanity check patch

[Yokota Hiroshi]

 Hello,

 This patch is required for my 640MB Optical disk.
Because some MS windows based FAT filesystem disk formatter generetes
wrong super bloacks.

-------------------------------------------
--- linux-2.6.0-test10/fs/fat/inode.c.bak	2003-11-24 10:31:52.000000000 +0900
+++ linux-2.6.0-test10/fs/fat/inode.c	2003-11-30 01:12:37.000000000 +0900
@@ -968,6 +968,8 @@
 		/* all is as it should be */
 	} else if (media == 0xf8 && FAT_FIRST_ENT(sb, 0xfe) == first) {
 		/* bad, reported on pc9800 */
+	} else if (media == 0xf0 && FAT_FIRST_ENT(sb, 0xf8) == first) {
+		/* bad, reported with a MO disk */
 	} else if (first == 0) {
 		/* bad, reported with a SmartMedia card */
 	} else {
-------------------------------------------

PS:
 I don't subscribe linux-kernel ML. If you have any questions,
please send mail to my mail address.

---
YOKOTA Hiroshi
E-mail: yokota (at) netlab (dot) is (dot) tsukuba (dot) ac (dot) jp

Re: FAT fs sanity check patch

[OGAWA Hirofumi]

Yokota Hiroshi <yokota@netlab.is.tsukuba.ac.jp> writes:

>  Hello,
> 
>  This patch is required for my 640MB Optical disk.
> Because some MS windows based FAT filesystem disk formatter generetes
> wrong super bloacks.

[...]

> +	} else if (media == 0xf0 && FAT_FIRST_ENT(sb, 0xf8) == first) {

Thanks. I'll submit this patch.

BTW, did this happen in MS windows of which version?
-- 
OGAWA Hirofumi <hirofumi@mail.parknet.co.jp>

Re: FAT fs sanity check patch

[Yokota Hiroshi]

From: OGAWA Hirofumi <hirofumi@mail.parknet.co.jp>
Subject: Re: FAT fs sanity check patch
Date: Wed, 03 Dec 2003 22:17:15 +0900

> > Because some MS windows based FAT filesystem disk formatter generetes
> > wrong super bloacks.

> BTW, did this happen in MS windows of which version?

 I tested on Windows 95 and Windows Me.
But I think it can happen on all version of MS-Windows.

###

I found why MS-Windows uses wrong numbers.

Usually, MO-disk uses "super floppy" format. And all "super floppy" format
disk contains wrong numbers. But "plain (Fixed disk)" format disk contains
correct number.


In "super floppy" format, boot sector's media number is 0xf0 (== 1.44MB 2HD
IBM-PC floppy format).
And FAT entry's media number is 0xf8 (== Fixed disk).

Media number can takes 0xf0-0xff.
Other media number values are used for other format disks.
For example, 1.2MB 2HC NEC-PC9801 floppy format uses 0xf9.


Usually, these two values must be same. But "super floppy" format
disk uses different value.

Why this format uses different value?
I think MS-Windows changes disk cache's caching strategy based on
boot sector's media ID value.

Because any removeable media can eject any time, so disk cache
(espeially write cache) is not usable for removeable disks.

MO disk can treat as Fixed disk, except disk caching strategy.
Because MO disk is removeable.

Anyway, this bad hack is not useful for Linux. Linux uses
mount/unmount command to flush disk cache.

I think the name of "super floppy" comes from this wrong number in
boot sector.

---
YOKOTA Hiroshi

Re: FAT fs sanity check patch

[OGAWA Hirofumi]

Yokota Hiroshi <yokota@netlab.is.tsukuba.ac.jp> writes:

> From: OGAWA Hirofumi <hirofumi@mail.parknet.co.jp>
> Subject: Re: FAT fs sanity check patch
> Date: Wed, 03 Dec 2003 22:17:15 +0900
> 
> > > Because some MS windows based FAT filesystem disk formatter generetes
> > > wrong super bloacks.
> 
> > BTW, did this happen in MS windows of which version?
> 
>  I tested on Windows 95 and Windows Me.
> But I think it can happen on all version of MS-Windows.

Nope, win2k didn't this at least.

> I found why MS-Windows uses wrong numbers.
> 
> Usually, MO-disk uses "super floppy" format. And all "super floppy" format
> disk contains wrong numbers. But "plain (Fixed disk)" format disk contains
> correct number.
>
> In "super floppy" format, boot sector's media number is 0xf0 (== 1.44MB 2HD
> IBM-PC floppy format).
> And FAT entry's media number is 0xf8 (== Fixed disk).
> 
> Media number can takes 0xf0-0xff.
> Other media number values are used for other format disks.
> For example, 1.2MB 2HC NEC-PC9801 floppy format uses 0xf9.

I know.
 
> Usually, these two values must be same. But "super floppy" format
> disk uses different value.
> 
> Why this format uses different value?
> I think MS-Windows changes disk cache's caching strategy based on
> boot sector's media ID value.
> 
> Because any removeable media can eject any time, so disk cache
> (espeially write cache) is not usable for removeable disks.

So?

> MO disk can treat as Fixed disk, except disk caching strategy.
> Because MO disk is removeable.
> 
> Anyway, this bad hack is not useful for Linux. Linux uses
> mount/unmount command to flush disk cache.

Bad hack? Why? Do you know how mount operation is dangerous and it's
difficult for fatfs? Do you want to handle the any format as FAT?

This is completely unrelated to handling the cache.
-- 
OGAWA Hirofumi <hirofumi@mail.parknet.co.jp>

Re: FAT fs sanity check patch

[Maciej Zenczykowski]

> Bad hack? Why? Do you know how mount operation is dangerous and it's
> difficult for fatfs? Do you want to handle the any format as FAT?
> 
> This is completely unrelated to handling the cache.

How about not playing around with fat detection and instead implement a 
force mount flag for FAT, which would ignore all (most?) detection errors.  
Of course if errors occured later you'd end up with a R/O filesystem.  And if 
you forced something that wasn't FAT, you'd be screwed... but that's to be 
expected...

Cheers,
MaZe.

Re: FAT fs sanity check patch

[OGAWA Hirofumi]

Maciej Zenczykowski <maze@cela.pl> writes:

> > Bad hack? Why? Do you know how mount operation is dangerous and it's
> > difficult for fatfs? Do you want to handle the any format as FAT?
> > 
> > This is completely unrelated to handling the cache.
> 
> How about not playing around with fat detection and instead implement a 
> force mount flag for FAT, which would ignore all (most?) detection errors.  
> Of course if errors occured later you'd end up with a R/O filesystem.  And if 
> you forced something that wasn't FAT, you'd be screwed... but that's to be 
> expected...

Yes, this flag would be one of candidates... However the scandisk/chkdisk
of windows fixed this bad format. Such a fsck may be best solution, I think.

Well, since the number of blacklists is three, I would like to wait
the more report before doing anything.

Thanks.
-- 
OGAWA Hirofumi <hirofumi@mail.parknet.co.jp>