Page 3 of 3 FirstFirst 123
Results 21 to 29 of 29

Thread: Linux I/O Scheduler Comparison On The Linux 3.4 Desktop

  1. #21
    Join Date
    Jun 2010
    Location
    ฿ 16LDJ6Hrd1oN3nCoFL7BypHSEYL84ca1JR
    Posts
    1,039

    Default

    Quote 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

  2. #22
    Join Date
    Nov 2011
    Location
    France
    Posts
    52

    Default

    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


    Quote 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

  3. #23
    Join Date
    Nov 2011
    Location
    France
    Posts
    52

    Default

    Quote 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

  4. #24
    Join Date
    Jun 2010
    Location
    ฿ 16LDJ6Hrd1oN3nCoFL7BypHSEYL84ca1JR
    Posts
    1,039

    Default

    Quote 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)?

  5. #25
    Join Date
    Nov 2011
    Location
    France
    Posts
    52

    Default

    Quote 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

  6. #26
    Join Date
    Jun 2010
    Location
    ฿ 16LDJ6Hrd1oN3nCoFL7BypHSEYL84ca1JR
    Posts
    1,039

    Default

    I don't really know, but I have read this:
    Quote 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.

  7. #27
    Join Date
    Nov 2011
    Location
    France
    Posts
    52

    Default

    Quote 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.

  8. #28
    Join Date
    Jun 2011
    Posts
    78

    Default Re: Responsiveness

    Quote 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.

  9. #29
    Join Date
    May 2012
    Location
    Rostock
    Posts
    2

    Default

    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.

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •