Re: Merging fails reading /dev/uba1

From: Linus Torvalds (torvalds_at_osdl.org)
Date: 02/21/05

  • Next message: Cameron Harris: "Re: cifs connection loss hangs" 
    Date:	Mon, 21 Feb 2005 12:00:48 -0800 (PST)
To: Pete Zaitcev <zaitcev@redhat.com>

    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@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  • Next message: Cameron Harris: "Re: cifs connection loss hangs"

    Relevant Pages

    • Re: Suspend2 2.1.9.8 for 2.6.12: 622-swapwriter.patch
      ... Depending upon how ... > the user has set the blocksize when they created the filesystem (in the ... send the line "unsubscribe linux-kernel" in ...
      (Linux-Kernel)
    • Re: [RFC][PATCH 1/3] radix priority search tree - objrmap complexity fix
      ... > What really happens is that you get errors with my tree because xfs in ... that case would be a filesystem with blocksize < PAGE_SIZE and a buffer ... send the line "unsubscribe linux-kernel" in ...
      (Linux-Kernel)
    • Re: [PATCH] fs: remove s_old_blocksize from struct super_block
      ... This gives you _consistently_ the blocksize you should get. ... of sectors, you need to set blocksize to just 512). ... And of course, if multiple openers exist, there is no consistent value at ... throughput) and iirc correctness problems (it would stick a 1kB blocksize ...
      (Linux-Kernel)
    • Re: [RFD] FS behavior (I/O failure) in kernel summit
      ... > Eric> I'd rather have a filesystem which I can tell to warn me immediately ... If the device hits bad sectors then NTFS adds them to the $BadClust list ... _Some_ bad sectors don't mean the disk is dying: ... send the line "unsubscribe linux-kernel" in ...
      (Linux-Kernel)
    • RAID1 Corruption
      ... randomly corrupting it's filesystem. ... I'm really quite baffled as to why this is happening, and my friend is ... Read ahead sectors 0 ... To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ ...
      (Linux-Kernel)