Announcement

Collapse
No announcement yet.

Linux I/O Scheduler Comparison On The Linux 3.4 Desktop

Collapse
X
  • Filter
  • Time
  • Show
Clear All
new posts

  • #21
    Originally posted by ChrisXY View Post
    Code:
    64 heads, 32 sectors/track, 228936 cylinders, total 468862128 sectors
    Units = sectors of 1 * 512 = 512 bytes
    Sector size (logical/physical): 512 bytes / 512 bytes
    I/O size (minimum/optimal): 512 bytes / 512 bytes
    Disk identifier: 0x1d172924
    
     Device Boot      Start         End      Blocks   Id  System
    /dev/sda1   *        2048   419432447   209715200   83  Linux
    
    .....
    
    Number  Start   End    Size   Type     File system  Flags
     1      1049kB  215GB  215GB  primary  ext4         boot
    That output doesn't really match up. Fdisk says my sector size is 512 byte and the partition 1 begins at sector 2048. And 512 * 2048 / (1024*1024) = 1.

    How does parted think that this is at 1049 kB? And why does it still think it is optimally aligned?

    Code:
     % sudo parted /dev/sda align-check opt 1
    1 aligned

    Comment


    • #22
      hdparm -I should give you more detail information.

      for instance , mine (sdb) which is a Corsair 64GB SSD with a Samsung firmware, outputs the following :

      Code:
      $ sudo hdparm -I /dev/sdb
      
      /dev/sdb:
      
      ATA device, with non-removable media
              Model Number:       CORSAIR CMFSSD-64GBG2D
      ...
              Firmware Revision:  VBM19C1Q
      Standards:
              Used: ATA/ATAPI-7 T13 1532D revision 1 
              Supported: 7 6 5 4 
      Configuration:
              Logical         max     current
              cylinders       16383   16383
              heads           16      16
              sectors/track   63      63
              --
              CHS current addressable sectors:   16514064
              LBA    user addressable sectors:  125045424
              LBA48  user addressable sectors:  125045424
              Logical/Physical Sector size:           512 bytes
              device size with M = 1024*1024:       61057 MBytes
              device size with M = 1000*1000:       64023 MBytes (64 GB)
              cache/buffer size  = unknown
              Nominal Media Rotation Rate: Solid State Device
      ...
      However to be sure of the size, I have checked @ Corsair product support which confirms that the physical size is actually 512

      Using fdisk -l /dev/sdb gives the same. May come from the same source that hdparm.

      Code:
      $ sudo fdisk -l /dev/sdb
      
      Disk /dev/sdb: 64.0 GB, 64023257088 bytes
      255 heads, 63 sectors/track, 7783 cylinders, total 125045424 sectors
      Units = sectors of 1 * 512 = 512 bytes
      Sector size (logical/physical): 512 bytes / 512 bytes
      I/O size (minimum/optimal): 512 bytes / 512 bytes
      Disk identifier: 0x1687aa3a
      
         Device Boot      Start         End      Blocks   Id  System
      /dev/sdb1            2048    50333695    25165824    7  HPFS/NTFS/exFAT
      /dev/sdb2   *    50333696   101963775    25815040   83  Linux
      
      $ sudo fdisk -l /dev/sda
      
      Disk /dev/sda: 1000.2 GB, 1000204886016 bytes
      255 heads, 63 sectors/track, 121601 cylinders, total 1953525168 sectors
      Units = sectors of 1 * 512 = 512 bytes
      Sector size (logical/physical): 512 bytes / 512 bytes
      I/O size (minimum/optimal): 512 bytes / 512 bytes
      Disk identifier: 0xca100020
      
         Device Boot      Start         End      Blocks   Id  System
      /dev/sda1            2048   100665343    50331648    7  HPFS/NTFS/exFAT
      /dev/sda2       100665344   257039999    78187328   83  Linux
      /dev/sda3       257040000  1953525167   848242584    5  Extended
      /dev/sda5       257040063   484681049   113820493+  83  Linux
      /dev/sda6       484681113  1953525167   734422027+  83  Linux
      
      $ df -h
      Filesystem      Size  Used Avail Use% Mounted on
      rootfs           25G  8.1G   16G  35% /
      /dev            3.0G     0  3.0G   0% /dev
      run             3.0G  316K  3.0G   1% /run
      /dev/sdb2        25G  8.1G   16G  35% /
      shm             3.0G   76K  3.0G   1% /dev/shm
      tmpfs           2.0G  105M  1.9G   6% /tmp
      tmpfs            64M  412K   64M   1% /var/log
      /dev/sda2        75G   45G   27G  63% /vm
      /dev/sda5       109G   71G   33G  69% /users
      /dev/sda6       700G  441G  225G  67% /data
      tmpfs           1.0G  1.1M 1023M   1% /home/cyril/tmp

      Because I had doubts about Linux alignment, I did this way :
      1. Backup my root FS with the tar command ( as show above my root FS is onto the SSD, the others on the HDD )
      2. Prepared all partition with Seven but without formatting them, at least for the Linux one
      3. Tagged the Linux part as Extended FS using fdisk
      4. Formatted it with mkfs.ext4 , because Ext4 seems to be the only one to offer the discard option to trim SSD
      5. Restored the root FS from the tar.gz backup


      Btw, I'm also doing I/O Scheduler benchmark and I have eratic results with the SSD !
      They change all the time whatever the scheduler is noop , deadline or cfq

      Fyi, I'm simply benchmarking with the dd command
      Code:
      dd if=/dev/zero of=./outfile bs=NNNNN count=100000 oflag=noatime,direct
      so far the SSD with a bs=32768

      Code:
      noop     = 51 MB/s
      deadline = 83 MB/s
      cfq      = 55 MB/s
      just after executing
      Code:
      fstrim -v /
      Code:
      noop     = 132 MB/s
      deadline = 143 MB/s
      cfq      = 96 MB/s
      with a bs=16384

      Code:
      noop     = 99 MB/s
      deadline = 79 MB/s
      cfq      = 102 MB/s
      still bs=16384, right after triming

      Code:
      noop     = 104 MB/s
      deadline = 94 MB/s
      cfq      = 78 MB/s

      with a bs=8192 and 'nocache' rather than 'direct' in oflag

      Code:
      noop     = 164 MB/s
      deadline = 153 MB/s
      cfq      = 170 MB/s


      while the HDD is constant with a bs=32768

      Code:
      noop     = 107  MB/s [30.5302s]
      deadline = 107  MB/s [30.7194s]
      cfq      = 107  MB/s [30.5122s]

      for now I choose noop for the SSD and cfq for the HDD


      Originally posted by ChrisXY View Post
      That's what I meant. What is a "physical sector" size in a SSD?

      Would resizing the beginning of the partition to the correct "sector" be the right thing to do or do I have to recreate the whole partition (and/or table)?


      Right, english is better:
      Code:
       ~ % sudo LC_ALL=C fdisk -u -l /dev/sda
      
      Disk /dev/sda: 240.1 GB, 240057409536 bytes
      64 heads, 32 sectors/track, 228936 cylinders, total 468862128 sectors
      Units = sectors of 1 * 512 = 512 bytes
      Sector size (logical/physical): 512 bytes / 512 bytes
      I/O size (minimum/optimal): 512 bytes / 512 bytes
      Disk identifier: 0x1d172924
      
         Device Boot      Start         End      Blocks   Id  System
      /dev/sda1   *        2048   419432447   209715200   83  Linux
      
      
       % sudo LC_ALL=C parted --list
      Model: ATA SanDisk SDSSDX24 (scsi)
      Disk /dev/sda: 240GB
      Sector size (logical/physical): 512B/512B
      Partition Table: msdos
      Disk Flags: 
      
      Number  Start   End    Size   Type     File system  Flags
       1      1049kB  215GB  215GB  primary  ext4         boot
      I have read that 64 heads and 32 sectors align to 1 MiB EBS blocks (64 * 32 * 512 = 1048576 byte = 1 MiB) so I tried that. I did this because the original default alignment of util linux fdisk 2.20 seemed to be wrong but it's more probable I only thought it was wrong when it was in fact correct.

      Hopefully 1049kB (not 2049) is actually 512 kbyte * 2.

      But it doesn't matter that much since I don't have too much bandwidth on this notebook anyway (will get replaced in the not so far future):
      Code:
       % sudo LC_ALL=C hdparm -t /dev/sda
      
      /dev/sda:
       Timing buffered disk reads: 776 MB in  3.00 seconds = 258.59 MB/sec

      Comment


      • #23
        Originally posted by ChrisXY View Post
        That output doesn't really match up. Fdisk says my sector size is 512 byte and the partition 1 begins at sector 2048. And 512 * 2048 / (1024*1024) = 1.

        How does parted think that this is at 1049 kB? And why does it still think it is optimally aligned?

        Code:
         % sudo parted /dev/sda align-check opt 1
        1 aligned
        I also have the same issue

        Code:
        $ sudo parted --list
        
        Model: ATA CORSAIR CMFSSD-6 (scsi)
        Disk /dev/sdb: 64.0GB
        Sector size (logical/physical): 512B/512B
        Partition Table: msdos
        Disk Flags: 
        
        Number  Start   End     Size    Type     File system  Flags
         1      1049kB  25.8GB  25.8GB  primary  ntfs
         2      25.8GB  52.2GB  26.4GB  primary  ext4         boot
        Notice that my first part is NTFS and not Linux.
        I mainly use fdisk and don't bother with parted.

        Your alignment sounds OK

        Comment


        • #24
          Originally posted by cyring View Post
          Your alignment sounds OK
          Ok, thanks. I'll leave it this way until I can at least test with SATA3.

          And sorry for hijacking the article thread.

          Your benchmarks seem so random. It seems to be coincidence what data it writes fast and what it writes slow. Was your SSD used much before these benchmarks and have you tried a "factory reset" (however unhealthy it may be)?

          Comment


          • #25
            Originally posted by ChrisXY View Post
            Ok, thanks. I'll leave it this way until I can at least test with SATA3.

            And sorry for hijacking the article thread.

            Your benchmarks seem so random. It seems to be coincidence what data it writes fast and what it writes slow. Was your SSD used much before these benchmarks and have you tried a "factory reset" (however unhealthy it may be)?
            Nop since a long time : more than 2 years a go I did a firmware update which refreshed the SSD

            I wonder if the fstrim command is enough to keep it in a good state ?
            Whenever I enter this it replies immediately with a
            Code:
            $ sudo fstrim -v /
            /: 17685495808 bytes were trimmed

            Comment


            • #26
              I don't really know, but I have read this:
              Originally posted by https://wiki.archlinux.org/index.php/SSD#SSD_Memory_Cell_Clearing
              On occasion, users may wish to completely reset an SSD's cells to the same virgin state they were at the time he/she installed the device thus restoring it to its factory default write performance. Write performance is known to degrade over time even on SSDs with native TRIM support. TRIM only safeguards against file deletes, not replacements such as an incremental save.

              Comment


              • #27
                Originally posted by ChrisXY View Post
                I don't really know, but I have read this:
                I did once a secure erase, however my SSD is dual booting Linux and Seven. This last one is a pain to backup/restore keeping a right alignment while Linux is a piece of cake
                Beside package management, I don't do so much writings on the SSD, throwing much of them on a ram fs. I also keep around 18% of unused space for wear leveling.

                I have followed ArchLinux's template for SSD benchmarking and here are my published results, selecting noop as an I/O scheduler.

                Comment


                • #28
                  Re: Responsiveness

                  Originally posted by talvik View Post
                  For years I've had problems using the desktop while a intensive IO operation is running. Even when simply transferring file to pendrive.

                  https://bugzilla.kernel.org/show_bug.cgi?id=12309
                  Some other site covered the issue.
                  I don't think we will see anything like it on Phoronix, but framejitter and uneven load is fairly important issues.

                  Comment


                  • #29
                    It's nice to see, that this topic has still a scientific relevance. Unfortunately most of the results don't find the way to us :/
                    The paper about the "Selective Timeout Bundling" scheduler for example was very exciting to me.

                    Seungyup Kang, Hyunchan Park, Chuck Yoo, "Performance Enhancements of I/O Schedulers for Solid State Drive", 2011 IEEE International Conference on Consumer Electronics (ICCE), Jan. 2011.(PDF)

                    I'm using now the deadline I/O scheduler for my Samsung 830 SSD.

                    Comment

                    Working...
                    X