Unfortunately, most of the parameters that might affect the number of map tasks are closer to "suggestions" than hard and fast rules. It is up to the InputFormat to decide how closely it follows those parameters. For example, FileInputFormat does the following:
It computes a splitSize based on: Math.max(minSize, Math.min(maxSize, blockSize)). For each file, it computes how many splits of that size will cover it. For example, if the split size is 1 GB, and you have two files of sizes 1.5 GB and 2.5 GB, you will get 2 + 3 = 5 splits. However, it sometimes stretches these splits by up to 10% when getting toward the end of a file. For instance, a 1 GB split size on a 5.1 GB file will use 5 splits. There are a few more considerations too, based on specific subclass implementations.
My point is, there's some fudging going on, but it's usually reasonable behavior. You should think of the parameters that you're setting as guidelines, and trust that the InputFormat you're using is doing something reasonable when it determines how many mappers to run.
And no, it has nothing to do with the number of cores or number of task slots. That might affect how many mappers can be running concurrently, but not the total number of map tasks.
