Re: CoolPix 950, FAT16 problem with large card
- From: dplatt@xxxxxxxxxxxx (Dave Platt)
- Date: Tue, 15 Jan 2008 22:18:17 -0800
In article <kdgno35h2565gs01auhq7mt4ndoq12c3pv@xxxxxxx>,
John Navas <spamfilter1@xxxxxxxxxxxxxx> wrote:
2 GB is actually 65 K *clusters* times a *cluster* size of 32 KB.
Each cluster is 64 sectors.
However, you can only reach the 2-gib limit if you use 32k-byte
sectors.
32 KB *clusters*. Sector size is still 512 bytes.
*sigh*. Right you are. I shouldn't type in long messages when I'm
tired... fingers run ahead of brain and eyes don't see the typos.
The apparent problem is that your Linux disto was misinterpreting the
FAT16 partition format.
That explanation, although perhaps convenient, fails to account for
another important fact I've just confirmed:
->> Windows 98 also says that the filesystem format is bad! <<-
I reformatted the CF card in the camera, powered down, moved the card
to an adapter in an old Windows 98 laptop I keep around (I knew there
was a reason to keep it!) and ran the Win98 Scandisk utility on the
filesystem.
Scandisk reported no less than 6 severe errors. Everything on the
card (two subdirectories and one file) were reported as being stored
in an illegal location. Scandisk's final diagnosis was along the
lines of "Seriously ill".
I then used Win98 to reformat the filesystem. This worked
fine... Windows used a cluster size of 32 sectors (16kb), just as the
Linux utilities had done. The Linux and Win98 formattings are nearly
identical... Windows set aside some hidden sectors, and didn't use the
last odd sector in the partition, but there are no other significant
differences.
The camera accepted the Windows-formatted card without complaint. So
does my Linux laptop. So, it seems that the 950's formatter is the
odd-man-out: neither Windows 98 nor Linux consider its formatting of
this card to be correct, while Windows and Linux produce compatible
formattings that the 950 will also accept.
In order to get a Linux-independent description of how the filesystem
should look, I went back to the Wikipedia page you cited, and followed
the link to the ECMA EC-107 standard, which documents the FAT12 and
FAT16 filesystem interchange formats.
Experimental procedure: I zeroed out the first megabyte of the
CF card, erasing the MBR if present, the partition table, and the boot
block and FAT and root directory of the filesystem on the card. I
then inserted the card into the Coolpix 950 camera and powered it on.
The camera quite properly reported that the card was not formatted,
and offered to do the formatting. I accepted. A few seconds later,
when formatting was complete and the camera was ready to record
photos, I powered it off, removed the card, and put the card back into
my laptop's slot.
Once again, Linux recognized a valid partition table, but objected to
the FAT16 filesystem, saying that it had too many clusters.
I bulk-copied the first megabyte of partition 1 and saved it for
further analysis.
Here's a hex dump of the boot block and the first sector of the first
copy of the FAT:
0000000 e9 00 00 20 20 20 20 20 20 20 20 00 02 08 01 00
0000016 02 00 02 00 00 f8 c8 03 3f 00 10 00 3f 00 00 00
0000032 f1 38 1e 00 00 00 00 00 00 00 00 00 00 00 00 00
0000048 00 00 00 00 00 00 46 41 54 31 36 20 20 20 00 00
0000064 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
*
0000496 00 00 00 00 00 00 00 00 00 00 00 00 00 00 55 aa
0000512 f8 ff ff ff ff ff ff ff ff ff 00 00 00 00 00 00
0000528 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
*
0001024
Offsets from the beginning are in decimal, counting from 0 (the EC-107
spec starts counting from 1, and I'll use that convention below).
Multibyte integers are of course in little-endian storage order.
My interpretation of this, based on the EC-107 spec, is as follows:
- The creating system identifier, in byte positions 4 through 11, is
all blanks.
- The SS (sector size) in byte positions 12 and 13 is 0x0200, or 512.
- The SC (sectors per cluster) count in byte position 14 is 8. Since
the cluster size equals SS*SC, the cluster size is therefore 4096
bytes.
- The RSC (reserved sector count) in byte position 15 and 16 is 1.
- The FN (number of FATs) in byte position 17 is 2.
- The RDE (count of entries in the root directory) in byte positions
18 and 19 is 0x0200, or 512.
- The TS (total sector count) in byte positions 20 and 21 is zero.
This is to be expected for an extended FDC descriptor which
describes a filesystem having more than 63353 sectors.
- The SF (sectors per FAT) in byte positions 23 and 24 is 0x03C8,
or 968.
- The SPT (sectors per track) in byte positions 25 and 26 is 0x003F,
or 63.
- The NOS (number of sides/heads) in byte positions 27 and 28 is
0x0010, or 16.
- The TS (total sector count) value in byte positions 33 through 36 is
0x1E38F1, or 1980657.
- The volume ID number in byte positions 40 through 43, and the volume
label in byte positions 44 through 54, are all zeros.
- The file system type in byte positions 55 through 62 is "FAT16 ".
Looking at the partition table itself with the Linux "fdisk" program, I
see:
Disk /dev/sdb: 1014 MB, 1014644736 bytes
16 heads, 63 sectors/track, 1966 cylinders
Units = cylinders of 1008 * 512 = 516096 bytes
Disk identifier: 0x00000000
Device Boot Start End Blocks Id System
/dev/sdb1 * 1 1965 990328+ 6 FAT16
The block count is in 1k blocks, and the "+" indicates that there's an
additional sector at the end. Twice 990328, plus 1, equals 1980657,
indicating that the space described by the disk's partition table, and
the space described by the filesystem boot block, are identical.
The boot block / FDC says that the filesystem has 1980657 sectors, and
that there are 8 sectors per cluster. This would require 247582
clusters (minus a few to account for the size of the system area).
Since a FAT16 FAT uses two bytes per cluster, each sector in the FAT
will hold 256 cluster entries. Dividing 247582 clusters by 256 clusters
per FAT sector, and rounding up, we find that we'd need 968 sectors of
FAT... and that's just what the SF value in the boot block says that
the filesystem is using.
If I run the Linux "fsck.vfat" program on the partition, here's how it
interprets what it sees:
dosfsck 2.11, 12 Mar 2005, FAT32, LFN
Checking we can access the last sector of the filesystem
Boot sector contents:
System ID " "
Media byte 0xf8 (hard disk)
512 bytes per logical sector
4096 bytes per cluster
1 reserved sector
First FAT starts at byte 512 (sector 1)
2 FATs, 16 bit entries
495616 bytes per FAT (= 968 sectors)
Root directory starts at byte 991744 (sector 1937)
512 root directory entries
Data area starts at byte 1008128 (sector 1969)
247336 data clusters (1013088256 bytes)
63 sectors/track, 16 heads
63 hidden sectors
1980657 sectors total
The data cluster count shown by the checker accounts for the size of
the system area, while my crude calculation above does not, so the
smaller number of clusters is to be expected.
So, Mr. Navas, I'd like to ask you two questions:
(1) Based on the actual data shown above, do you agree that the
CoolPix 950 did create a FAT16 filesystem which contains more
than 247,000 clusters of 8 sectors (4kb) each?
(2) Is a FAT16 filesystem capable of being legal and self-consistent
if its maximum number of clusters exceeds 0xFFF7?
As far as I can tell, the way that the Linux kernel and utilities are
interpreting the FAT16 boot block are quite consistent with ECMA
EC-107, and also to match the Win98 interpretation. The camera really
did create a filesystem which is not capable of correct operation -
disaster will occur once the camera starts trying to use clusters
numbered above 0xFFFF. Neither the directory entries (Table 5) nor
the cluster chains in the FAT can store such cluster numbers without
truncation. Lost data and "duplicate allocation" errors are sure to
result.
As an experiment, I instructed the Linux mkfs.vfat program to format
the partition in FAT16 mode with 8 sectors per cluster (-F 16 -S 8).
The program flatly refused to do so, telling me that this would
require more clusters than the FAT can hold and that I should
specify a larger number of sectors per cluster.
The sectors-per-cluster value of 8 used by the Coolpix 950 would work
correctly with CF cards of up to 128 MB, and it should work correctly
with a 256 MB card. With a 512MB card or above, the cluster-number
indices will exceed 16 bits in width, will be truncated, and Bad
Things will happen.
If you disagree with my conclusions about the (in)correctness of the
filesystem created by the CoolPix 950, I'd really appreciate a
*specific* pointer to how you disagree with my interpretation of the
data in the filesystem boot block, or a pointer to technical documents
which show how a FAT16 filesystem can actually hold more than 2^16
clusters.
--
Dave Platt <dplatt@xxxxxxxxxxxx> AE6EO
Friends of Jade Warrior home page: http://www.radagast.org/jade-warrior
I do _not_ wish to receive unsolicited commercial email, and I will
boycott any company which has the gall to send me such ads!
.
- Follow-Ups:
- Re: CoolPix 950, FAT16 problem with large card
- From: John Navas
- Re: CoolPix 950, FAT16 problem with large card
- References:
- CoolPix 950, FAT16 problem with large card
- From: Dave Platt
- Re: CoolPix 950, FAT16 problem with large card
- From: John Navas
- Re: CoolPix 950, FAT16 problem with large card
- From: Dave Platt
- Re: CoolPix 950, FAT16 problem with large card
- From: John Navas
- CoolPix 950, FAT16 problem with large card
- Prev by Date: Re: Sigma SD 14
- Next by Date: Re: Digital Photography On Aircraft Not Permitted on Take Off or Landing
- Previous by thread: Re: CoolPix 950, FAT16 problem with large card
- Next by thread: Re: CoolPix 950, FAT16 problem with large card
- Index(es):
Relevant Pages
|
|
