lkml.org 
[lkml]   [2003]   [Dec]   [13]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: FAT fs sanity check patch
Date
From


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
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-03-22 13:59    [W:1.520 / U:0.112 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site