Re: Merging fails reading /dev/uba1

[Linus Torvalds]

On Mon, 21 Feb 2005, Pete Zaitcev wrote:
> 
> Contiguous pages have nothing to do with it either. I forgot to mention
> that in the first case (whole device), all reads are done with length of
> 4KB, while in the second case (partition), all reads are 512 bytes long.

That's because your partition isn't a full 4kB in size.

So the kernel falls back to 512-byte reads, just because they are the only 
kind that _can_ read the last sector.

> Disk /dev/uba: 1048 MB, 1048576000 bytes

Note: this is a nice multiple of 4kB.

> 64 heads, 32 sectors/track, 1000 cylinders
> Units = cylinders of 2048 * 512 = 1048576 bytes
> 
>    Device Boot      Start         End      Blocks   Id  System
> /dev/uba1   *           1        1000     1023983+   6  FAT16

And note how this is _not_ (see the "+" at the end), you've got a 
1023983.5 kB partition.

> It does not look to me as if the partition started from an odd number
> of sectors. In fact, it starts from a full number of pages.

But it seems to end in an odd number of sectors.

That said, I'm surprised that the difference in performance is _that_ 
large. Regardless of whether the disk blocksize is 512 bytes or 4096 
bytes, you should be getting IO merging - it might use more CPU time, but 
the actual IO should still be done in much larger blocks.

You should be able to try the BLKBSZSET ioctl to set the blocksize by hand 
if you want to try it out:

	int size = 4096;
	ioctl(fd, BLKBSZSET, &size);

or similar. Of course, mounting a filesystem on the device tends to do 
that (or undo it) for you, ie it will set the blocksize to whatever 
blocksize the filesystem wants.

		Linus
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/