>>
>>But you see, Dmitry, you are not putting the stuff is separate "drives". They are all on the same drive. But yes, you do get different drive letters.
>>
>>Here's a way around that. Do a network mapping to each of the 'main drive directories'.
>>For example, if you have a 'main driver directory' called "DriveD", then map the directory C:\DriveD to a drive letter. Same for C:\DriveE, to a different drive letter.
>>Partitions, at least when NTFS is used, in my opinion make for erratic performance.
>
>Jim,
>
>I never thought about mapping a folder into a drive letter. That's very smart idea. Thank you very much.
>
>When you are saying "erratic performance", any specific symptoms of that? I have had 2 notebook (one before and one I am using now) that were partitioned into three partitions. Both computers used NTFS. But I have not seen performance issues. How would they manifest?

Since you've not used notebooks any way but partitioned, you can't know < s >.

The HD on my notebook (about 5 years old) makes faint noise when the head moves.
Head movement is the single biggest performance degrader on a HD and the farther the movement, the slower the performance. When you make partitions you not only force head movement as you move between partitions, but that head movement virtually always has to cross 'empty' space too (the free space left in partitions). If you are 'in' partition #1 and you need data in partition #3 you force crossing the balance of partition #1 and the whole of partition #2 just to get at partition #3. That's "expensive", time-wise.

I also *guess* that OS cache for the HD directory suffers by virtue of having to manage 3 different full directory trees rather than just a single one.

HDs are fast these days, so the evidence of performance degradation may be slight, but nonetheless it is happening. And the erratic part comes from sequences of event, where in some cases you may stick to a single partition and in other cases flit back-and-forth between partitions. Another cause for erratic performance might be **when** a file needs to have a new extent (fragment) allocated. An actual file's current allocation is kept in RAM. Now suppose you were merrily writing to a file in P#3 and then you did something unrelated that required P#1. P#1's directory might need refresh to RAM. When done with P#1 the application using P#3 gets control again. But it's very next record needs a new extent (fragment). This requires re-reading P#3 directory/space structure to allocate the new extent. With a single partition my guess is that the up-to-date directory/space structure for the single partition is already present and up-to-date in RAM.