Re: The 9997th file specific DOSFS problem
- From: peter.mitsis@xxxxxxxxx
- Date: Fri, 11 Jul 2008 07:49:22 -0700 (PDT)
Unfortunately, I'm running out of ideas.
On Jul 11, 3:06 am, y...@xxxxxx wrote:
Thanks alot Peter. You helped me to understand the problem better.
A few things i need to clarify:
1) The average performance of accessing the raid, single file I/O, is
~40 MB/s, except when it hits the ~10000th file. i.e., it takes ~0.1
second
to write a 4 MB file normally. When it hits the ~10000th file, it
takes
~30 seconds, which is ~300 times slower. Writing the file right after
it will then take the normal 0.1 seconds, until it hits the next one.
It seems to me not a pure performance problem.
2) Thought it is already using 32 KB sector size. Will double check
on that. We do need it to be compatible with Windows / Solaris, so
32 KB is the max. We need it to be on a single partition as well for
a few reasons.
3) Adjusting size of the cache of the dcacheLib(?) didn't affect the
problem much.
If we consider the volumn, two FATs and the # 9997, it's exactly 10000
(speculating). This makes me think that there has to be this magic #
somewhere in the code that's related to the problem.
If there is a magic number, I am thinking that it is non-obvious (or
perhaps my memory is going); I don't recall seeing anything that would
suggest this behaviour.
The 512 bytes "tiny cache" for the FAT is very intersting. Is it
possible
that a break down of the algorithm, say, an overflow / underflow, is
causing
it to "re-caching" every sector of the FAT. I just realized the 30
second
time duration is very consistent every time it hits this magic file.
Anyidea this 512B "tiny cache" canbe adjusted? Does dosFs try to
remember
/ use the last searched sector?
The tiny cache is not configurable. It is the same size as the sector
(512 bytes in most cases), and should not be confused with the cluster
size. Yes, the VxWorks DosFS implementation does try to track and
begin the search from the last searched FAT entry.
Any other idea? Appreciated you help!
This may not be relevant, but according to wikipedia's entry on the
File Allocation Table (http://en.wikipedia.org/wiki/
File_Allocation_Table), earlier versions of windows had a limitation
of 128 GB to the FAT32 partition size. I do recall the group
mentionning trying to abide by that limitation, but I don't know off
the top of my head whether such a limitation was actually inserted
into the code. I note this as you mentionned single partitions and
raid volumes of 128 GB -> 900 GB. This avenue might be a red
herring. Even so, I don't really see it coming into play that much.
10000 files * 4MB each = 40 GB, which is well under these limits.
Even with any preallocation that may have been done (to reduce
possible fragmentation), we should still be well shy of that 128 GB.
I think one of the show routines displays the preferred number of
clusters that are allocated in one go.
Hmm, playing with some more numbers, I get ....
Assuming 1 sector = 512 bytes, ...
FAT32 = 4 byte FAT entries --> 128 FAT entries per sector
32 kB cluster size means that each FAT sector (and tiny cache) can
hold cluster numbers to address up to 4 MB of data.
If the normal files are 4 MB, that is one FAT sector per file.
9997 mod 128 = 13
9997 / 128 = 78 + some change
I'm not really sure where I am going with these numbers ... just
looking for something that may give a better clue as to where to go
next.
Peter
.
- Follow-Ups:
- References:
- The 9997th file specific DOSFS problem
- From: yue
- Re: The 9997th file specific DOSFS problem
- From: peter . mitsis
- Re: The 9997th file specific DOSFS problem
- From: yue
- The 9997th file specific DOSFS problem
- Prev by Date: Re: The 9997th file specific DOSFS problem
- Next by Date: Re: The 9997th file specific DOSFS problem
- Previous by thread: Re: The 9997th file specific DOSFS problem
- Next by thread: Re: The 9997th file specific DOSFS problem
- Index(es):
Relevant Pages
|
