Re: FAT FSD CETK :: repost :: original post in testtools :: MS help required.
- From: "Joseph Garibaldi" <joseph_garibaldi@xxxxxxxxxxxxx>
- Date: Thu, 18 Aug 2005 05:12:11 +0530
hi,
some answers finally,
1. test case 5030 after running, gives the message:
Creating file \Hard Disk\MULTIVOL\W32FILE.DAT
Filling partition [DSK3:]\Hard Disk so that 4096 bytes remain (quick
version)
Partition [DSK3:]\Hard Disk has 533020672 free bytes
Creating file \Hard Disk\EATFILE.NAM1 of 533016576 bytes to fill disk
Partition [DSK3:]\Hard Disk now has 4096 free bytes
Writing data to \Hard Disk\MULTIVOL\W32FILE.DAT at 10 offsets using
WriteFileWithSeek()...
File \Hard Disk\MULTIVOL\W32FILE.DAT: writing 0x00000000 at offset 0
File \Hard Disk\MULTIVOL\W32FILE.DAT: writing 0x00000001 at offset 10
File \Hard Disk\MULTIVOL\W32FILE.DAT: writing 0x00000002 at offset 20
..
..
..
File \Hard Disk\MULTIVOL\W32FILE.DAT: writing 0x0000019A at offset
4100
Disk filled up while writing to file \Hard
Disk\MULTIVOL\W32FILE.DAT...
Cleaning up "\Hard Disk\MULTIVOL"...
NOTE :: He cleans out \Hard Disk\MULTIVOL\ ..... but what about the
file \Hard Disk\EATFILE.NAM1 (of size 533016576 bytes, which is the entire
partition minus 4096 bytes)? Turns out that this still remains after test
5030 runs. I verified this by just running 5030 and seeing the folder \Hard
Disk after the test got completed.
2. Now, if 5031 (and 8001) is run after 5030 using -r option, the file
\Hard Disk\EATFILE.NAM1 still remains and thus it doesn't have enough
space.
Note that 5031 when fails like this (run after 5030 using -r option)
gives the message:
Creating file \Hard Disk\MULTIVOL\W32FILE.DAT
Writing data to \Hard Disk\MULTIVOL\W32FILE.DAT at 1024 offsets using
WriteFileWithSeek()...
File \Hard Disk\MULTIVOL\W32FILE.DAT: writing 0x00000000 at offset 0
Disk filled up while writing to file \Hard
Disk\MULTIVOL\W32FILE.DAT... continuing test
Reading data from \Hard Disk\MULTIVOL\W32FILE.DAT using
ReadFileWithSeek() and verifying...
File \Hard Disk\MULTIVOL\W32FILE.DAT: read 0x00000000 at offset 0
File \Hard Disk\MULTIVOL\W32FILE.DAT: read 0x00000000 at offset 1024
FAIL in c:\mlqa\private\test\filesys\fsdtst\multivoltests.cpp at line
3565: data mismatch
Cleaning up "\Hard Disk\MULTIVOL"...
Now, the read/write code which performs this operation is in
(private\test\filesys\fsdtst\multivoltests.cpp) lines 3521 to 3561. Refer
to it. The variable maxIterations is initially set to 128 (which is the
number of times the offset is going to be increased and utilized to write in
the file). Because the disk is full, the first WriteFileWithSeek() itself
fails with either ERROR_DISK_FULL or ERROR_OUTOFMEMORY. This leads to a
break in the for loop and the code sets the maxIterations variable to (i-1)
where i is the loop counter. So, when the loop breaks in this case, the
value of maxIterations is set to 0-1 ==> -1 ==> treated as 0xff_ff_ff_ff
because maxIterations is unsigned.
So, when write breaks out like this, read which comes after this thinks
that it should read using offsets incremented by 1024 for 0xff_ff_ff_ff
iterations. which is clearly leading to the error message stating that
there's a data mismatch right in the second read (offset 1024).
3. when test case 5031 is run after 5030 using -p HDProfile, the
observation was that it ran successfully. The reason for that is the
formatting of the Hard Disk partition at the beginning of 5031 (actually,
formatting before all test cases) when -p is used (and in addition -f not
being used) as opposed to no formatting when -r is used (with or
without -f).
The reason behind that being the stubbed (TRUE returning) implementation
(of
the test suite) for formatting in case of file systems other than FAT being
used.
So, when file system used on the partition is FAT and -r and -f
option is not used, ACTUAL FORMATTING is done before each test case
(exceptions do exist for example test case 8001 where formatting is not even
tried). Notice the following messsage when 5031 is run with -p HDProfile
Formatting DSK3:\Part00...
Format on DSK3:\Part00 succeeded.
which clearly does not appear when -r option is used (as indicated
before, the stubbed FORMATTING function is used instead).
4. finally the ONE question remaining is that why do 5024 and 5025 fail
when run with -p HDProfile option but not when run with -r option?
the output when fsdtst is run with -p is :
5024 ::
Filling partition [DSK3:]\Hard Disk so that 4096 bytes remain (quick
version)
Partition [DSK3:]\Hard Disk has 533028864 free bytes
Creating file \Hard Disk\EATFILE.NAM1 of 533024768 bytes to fill disk
Partition [DSK3:]\Hard Disk now has 4096 free bytes
Creating directory \Hard Disk\W32DIR
FAIL in c:\mlqa\private\test\filesys\fsdtst\multivoltests.cpp at line
2758: CreateTestDirectory()
Removing fill file \Hard Disk\EATFILE.NAM1...
5025 ::
Filling partition [DSK3:]\Hard Disk so that 4096 bytes remain (quick
version)
Partition [DSK3:]\Hard Disk has 533028864 free bytes
Creating file \Hard Disk\EATFILE.NAM1 of 533024768 bytes to fill disk
Partition [DSK3:]\Hard Disk now has 4096 free bytes
Creating file \Hard Disk\W32FILE of size 100 bytes
ERROR in c:\mlqa\private\test\filesys\fsdtst\mfs.cpp at line 456:
WriteFile(); error 112
FAIL in c:\mlqa\private\test\filesys\fsdtst\multivoltests.cpp at line
2855: CreateTestFile()
Removing fill file \Hard Disk\EATFILE.NAM1...
and when -r is used ::
FAT Format Information:
Total Bytes: 534,094,848
Usable Bytes: 533,032,960
Used Bytes: 4,096
Free Bytes: 533,028,864
Media Descriptor: 0xF8
Sector Size: 512
Sectors/Cluster: 8
Cluster Size: 4,096
Total Sectors: 1,043,154
Reserved Sectors: 32
Hidden Sectors: 0
Sectors/Track: 1
Number of Heads: 1
Sectors/FAT: 1,019
Number of FATs: 2
Root Entries: 65,535
Usable Clusters: 130,135
Used Clusters: 1
Free Clusters: 130,134
5024::
Filling partition []\Hard Disk so that 4096 bytes remain (quick
version)
Partition []\Hard Disk has 533024768 free bytes
Creating file \Hard Disk\EATFILE.NAM1 of 533020672 bytes to fill disk
Partition []\Hard Disk now has 4096 free bytes
Creating directory \Hard Disk\W32DIR
Removing directory \Hard Disk\W32DIR
Removing fill file \Hard Disk\EATFILE.NAM1...
5025::
Filling partition []\Hard Disk so that 4096 bytes remain (quick
version)
Partition []\Hard Disk has 533024768 free bytes
Creating file \Hard Disk\EATFILE.NAM1 of 533020672 bytes to fill disk
Partition []\Hard Disk now has 4096 free bytes
Creating file \Hard Disk\W32FILE of size 100 bytes
Deleting file \Hard Disk\W32FILE
Removing fill file \Hard Disk\EATFILE.NAM1...
The difference that stands out is the number of bytes considered to be
free in the partition (between running with -p and -r). When -r is used
533024768 bytes are considered as free, whereas when -p is used 533028864 is
considered as the number of free bytes. Now this corresponds to a difference
of exactly 1 cluster (4096 bytes) in this case. GetDiskFreeSpaceEx() call
in
line 299 of mfs.cpp (in private\test\filesys\fsdtst\ ) is the API providing
this information to the test suite in both the cases (-p and -r). However,
it returns a different value in fb for -p and -r way of running the test
case
(even though the partition remains the same). Both cannot be true at the
same time and hence probably one of them is considered wrongly ?!
Why is this difference? I couldn't determine. Probably somebody
from MS can help out.
cheers,
joseph garibaldi.
--
cheers,
Joseph Garibaldi.
B'lore, India.
.
- References:
- FAT FSD CETK :: repost :: original post in testtools.
- From: Joseph Garibaldi
- FAT FSD CETK :: repost :: original post in testtools.
- Prev by Date: Re: Managed code built into OS images.
- Next by Date: Re: Error when using malloc
- Previous by thread: FAT FSD CETK :: repost :: original post in testtools.
- Next by thread: Customise build for PXA270
- Index(es):
Relevant Pages
|
