Announcement

**acheron** · Apr 09, 2017, 04:45 AM

Need to find a better reference for this, but...

http://askubuntu.com/questions/78444...rs-to-deadline

We've moved to using CFQ as default for the Ubuntu Zesty 4.10 kernel and also enabled the new CONFIG_BLK_WBT_MQ (Multiqueue writeback throttling) as this resolves the dirty cache writeback issues with slow devices such as flash devices. – Colin Ian King Mar 13 at 22:27

You can obviously changes rules to override that default.

**GreyGeek** · Apr 09, 2017, 05:38 AM

Originally posted by mpathy View Post

Just wanted to know from people who had it installed, if this here is fixed in 17.04?

See article here: http://www.hecticgeek.com/2016/11/ub...rs-comparison/
He normally knows what he is talking about..

Because the tests otherwise were super promising. Could see myself using KDE again after ten years, if such things get fixed, because KDE5 itself seems to be tweaked quite well in the meantime

While Gayan praises the "deadline" scheduling in that article he blames it in another and changes scheduling to cfq.

When someone in the talkbacks responded that deadline was still better his response was:

Thank you for the input. However, ‘Deadline’ is known to perform better under SSDs. For rotating disk drives, in my limited practical experience, even though ‘Deadline’ used to perform better in the past, these days, I prefer ‘CFQ’, it just seems to be more fair and responsive. But if it changes in the future, then yes I’ll switch back to ‘Deadline’…

Maybe he's changed his mind again over the last two years? Or has the deadline scheduling algorithm improved? It's an easy test He shows, in the second article, how to change the I/O Scheduler so that you can find out for yourself on YOUR machine which is faster for the stuff you do..

**wizard10000** · Apr 09, 2017, 06:52 AM

I use a udev rule that sets the scheduler to deadline for non-rotating disks. Swiped from

https://wiki.debian.org/SSDOptimization

Code:

# set deadline scheduler for non-rotating disks

ACTION=="add|change", KERNEL=="sd[a-z]", ATTR{queue/rotational}=="0", ATTR{queue/scheduler}="deadline"

**jlittle** · Apr 10, 2017, 04:48 AM

Weird that this has come up again. Way back, this bit me hard when copying to a USB stick or SD card; desktop I/O starvation occurred rendering the system unusable, to the point where KDE and the OS itself were throwing wobblies. I couldn't understand why anyone thought this was ok; CFQ was a complete dog, total fail, in some circumstances, not just a bit slower. Several bugs were filed showing terrible performance with CFQ, and I concluded that they just didn't believe us.

Checking,

Code:

$ cd /sys/block
$ for x in ?d?;do echo "$x $(<$x/queue/rotational) $(<$x/queue/scheduler)";done
sda 1 noop deadline [cfq] 
sdb 1 noop deadline [cfq] 
sdc 0 noop [deadline] cfq

where the SSD has 0 for "rotational", I see that my SSD is using deadline, and the hard disks CFQ. There is a udev rule the opposite of wizard10000's turning on CFQ for "rotational" devices, so in 16.10 deadline is the default.

Thanks for the warning, all, now I know to check this out when I move to Zesty. Maybe it's academic on my present hardware.

**wizard10000** · Apr 10, 2017, 05:05 AM

Originally posted by jlittle View Post

...so in 16.10 deadline is the default.

Now I'm gonna have to go look at my laptop when I get home. I run Debian Unstable, and when I set up that udev rule default was CFQ - now I'm not so sure

Thanks for the info

**GreyGeek** · Apr 10, 2017, 08:56 AM

My Neon User Edition using Btrfs reports that my 7200RPM rotational device at sda is "deadline".

Maybe cfq is not the default for rotational devices?

Code:

cat sys/block/sda/queue/schedule

Code:

noop [deadline] cfq

Does cfq actually work bettor on rotating storage devices when compared to deadline?

**GreyGeek** · Apr 10, 2017, 09:14 AM

While researching the deadline vs cfq problem I ran across this kernel source code about blacklisting certain storage mediums.

They are listed by various types of problems under Linux:

Code:

[COLOR=#0057AE]static const struct[/COLOR] ata_blacklist_entry ata_device_blacklist [] = {
    [COLOR=#838183][I]/* Devices with DMA related problems under Linux */[/I][/COLOR]
    { [COLOR=#BF0303]"WDC AC11000H"[/COLOR],    NULL,        ATA_HORKAGE_NODMA },
    { [COLOR=#BF0303]"WDC AC22100H"[/COLOR],    NULL,        ATA_HORKAGE_NODMA },
    { [COLOR=#BF0303]"WDC AC32500H"[/COLOR],    NULL,        ATA_HORKAGE_NODMA },
    { [COLOR=#BF0303]"WDC AC33100H"[/COLOR],    NULL,        ATA_HORKAGE_NODMA },
    { [COLOR=#BF0303]"WDC AC31600H"[/COLOR],    NULL,        ATA_HORKAGE_NODMA },
    { [COLOR=#BF0303]"WDC AC32100H"[/COLOR],    [COLOR=#BF0303]"24.09P07"[/COLOR],    ATA_HORKAGE_NODMA },
    { [COLOR=#BF0303]"WDC AC23200L"[/COLOR],    [COLOR=#BF0303]"21.10N21"[/COLOR],    ATA_HORKAGE_NODMA },
    { [COLOR=#BF0303]"Compaq CRD-8241B"[/COLOR],     NULL,        ATA_HORKAGE_NODMA },
    { [COLOR=#BF0303]"CRD-8400B"[/COLOR],        NULL,         ATA_HORKAGE_NODMA },
    { [COLOR=#BF0303]"CRD-848[02]B"[/COLOR],    NULL,        ATA_HORKAGE_NODMA },
    { [COLOR=#BF0303]"CRD-84"[/COLOR],        NULL,        ATA_HORKAGE_NODMA },
    { [COLOR=#BF0303]"SanDisk SDP3B"[/COLOR],    NULL,        ATA_HORKAGE_NODMA },
    { [COLOR=#BF0303]"SanDisk SDP3B-64"[/COLOR],    NULL,        ATA_HORKAGE_NODMA },
    { [COLOR=#BF0303]"SANYO CD-ROM CRD"[/COLOR],    NULL,        ATA_HORKAGE_NODMA },
    { [COLOR=#BF0303]"HITACHI CDR-8"[/COLOR],    NULL,        ATA_HORKAGE_NODMA },
    { [COLOR=#BF0303]"HITACHI CDR-8[34]35"[/COLOR],NULL,        ATA_HORKAGE_NODMA },
    { [COLOR=#BF0303]"Toshiba CD-ROM XM-6202B"[/COLOR], NULL,    ATA_HORKAGE_NODMA },
    { [COLOR=#BF0303]"TOSHIBA CD-ROM XM-1702BC"[/COLOR], NULL,    ATA_HORKAGE_NODMA },
    { [COLOR=#BF0303]"CD-532E-A"[/COLOR],         NULL,        ATA_HORKAGE_NODMA },
    { [COLOR=#BF0303]"E-IDE CD-ROM CR-840"[/COLOR],NULL,        ATA_HORKAGE_NODMA },
    { [COLOR=#BF0303]"CD-ROM Drive/F5A"[/COLOR],    NULL,        ATA_HORKAGE_NODMA },
    { [COLOR=#BF0303]"WPI CDD-820"[/COLOR],     NULL,        ATA_HORKAGE_NODMA },
    { [COLOR=#BF0303]"SAMSUNG CD-ROM SC-148C"[/COLOR], NULL,    ATA_HORKAGE_NODMA },
    { [COLOR=#BF0303]"SAMSUNG CD-ROM SC"[/COLOR],    NULL,        ATA_HORKAGE_NODMA },
    { [COLOR=#BF0303]"ATAPI CD-ROM DRIVE 40X MAXIMUM"[/COLOR],NULL,ATA_HORKAGE_NODMA },
    { [COLOR=#BF0303]"_NEC DV5800A"[/COLOR],     NULL,        ATA_HORKAGE_NODMA },
    { [COLOR=#BF0303]"SAMSUNG CD-ROM SN-124"[/COLOR], [COLOR=#BF0303]"N001"[/COLOR],    ATA_HORKAGE_NODMA },
    { [COLOR=#BF0303]"Seagate STT20000A"[/COLOR], NULL,        ATA_HORKAGE_NODMA },
    { [COLOR=#BF0303]" 2GB ATA Flash Disk"[/COLOR], [COLOR=#BF0303]"ADMA428M"[/COLOR],    ATA_HORKAGE_NODMA },
    { [COLOR=#BF0303]"VRFDFC22048UCHC-TE*"[/COLOR], NULL,        ATA_HORKAGE_NODMA },
    [COLOR=#838183][I]/* Odd clown on sil3726/4726 PMPs */[/I][/COLOR]
    { [COLOR=#BF0303]"Config  Disk"[/COLOR],    NULL,        ATA_HORKAGE_DISABLE },

    [COLOR=#838183][I]/* Weird ATAPI devices */[/I][/COLOR]
    { [COLOR=#BF0303]"TORiSAN DVD-ROM DRD-N216"[/COLOR], NULL,    ATA_HORKAGE_MAX_SEC_128 },
    { [COLOR=#BF0303]"QUANTUM DAT    DAT72-000"[/COLOR], NULL,    ATA_HORKAGE_ATAPI_MOD16_DMA },
    { [COLOR=#BF0303]"Slimtype DVD A  DS8A8SH"[/COLOR], NULL,    ATA_HORKAGE_MAX_SEC_LBA48 },
    { [COLOR=#BF0303]"Slimtype DVD A  DS8A9SH"[/COLOR], NULL,    ATA_HORKAGE_MAX_SEC_LBA48 },

    [COLOR=#838183][I]/*[/I][/COLOR]
[COLOR=#838183][I]     * Causes silent data corruption with higher max sects.[/I][/COLOR]
[COLOR=#838183][I]     * http://lkml.kernel.org/g/x49wpy40ysk.fsf@segfault.boston.devel.redhat.com[/I][/COLOR]
[COLOR=#838183][I]     */[/I][/COLOR]
    { [COLOR=#BF0303]"ST380013AS"[/COLOR],        [COLOR=#BF0303]"3.20"[/COLOR],        ATA_HORKAGE_MAX_SEC_1024 },

    [COLOR=#838183][I]/*[/I][/COLOR]
[COLOR=#838183][I]     * These devices time out with higher max sects.[/I][/COLOR]
[COLOR=#838183][I]     * https://bugzilla.kernel.org/show_bug.cgi?id=121671[/I][/COLOR]
[COLOR=#838183][I]     */[/I][/COLOR]
    { [COLOR=#BF0303]"LITEON CX1-JB*-HP"[/COLOR],    NULL,        ATA_HORKAGE_MAX_SEC_1024 },

    [COLOR=#838183][I]/* Devices we expect to fail diagnostics */[/I][/COLOR]

    [COLOR=#838183][I]/* Devices where NCQ should be avoided */[/I][/COLOR]
    [COLOR=#838183][I]/* NCQ is slow */[/I][/COLOR]
    { [COLOR=#BF0303]"WDC WD740ADFD-00"[/COLOR],    NULL,        ATA_HORKAGE_NONCQ },
    { [COLOR=#BF0303]"WDC WD740ADFD-00NLR1"[/COLOR], NULL,        ATA_HORKAGE_NONCQ, },
    [COLOR=#838183][I]/* http://thread.gmane.org/gmane.linux.ide/14907 */[/I][/COLOR]
    { [COLOR=#BF0303]"FUJITSU MHT2060BH"[/COLOR],    NULL,        ATA_HORKAGE_NONCQ },
    [COLOR=#838183][I]/* NCQ is broken */[/I][/COLOR]
    { [COLOR=#BF0303]"Maxtor *"[/COLOR],        [COLOR=#BF0303]"BANC*"[/COLOR],    ATA_HORKAGE_NONCQ },
    { [COLOR=#BF0303]"Maxtor 7V300F0"[/COLOR],    [COLOR=#BF0303]"VA111630"[/COLOR],    ATA_HORKAGE_NONCQ },
    { [COLOR=#BF0303]"ST380817AS"[/COLOR],        [COLOR=#BF0303]"3.42"[/COLOR],        ATA_HORKAGE_NONCQ },
    { [COLOR=#BF0303]"ST3160023AS"[/COLOR],    [COLOR=#BF0303]"3.42"[/COLOR],        ATA_HORKAGE_NONCQ },
    { [COLOR=#BF0303]"OCZ CORE_SSD"[/COLOR],    [COLOR=#BF0303]"02.10104"[/COLOR],    ATA_HORKAGE_NONCQ },

    [COLOR=#838183][I]/* Seagate NCQ + FLUSH CACHE firmware bug */[/I][/COLOR]
    { [COLOR=#BF0303]"ST31500341AS"[/COLOR],    [COLOR=#BF0303]"SD1[5-9]"[/COLOR],    ATA_HORKAGE_NONCQ |
                        ATA_HORKAGE_FIRMWARE_WARN },

    { [COLOR=#BF0303]"ST31000333AS"[/COLOR],    [COLOR=#BF0303]"SD1[5-9]"[/COLOR],    ATA_HORKAGE_NONCQ |
                        ATA_HORKAGE_FIRMWARE_WARN },

    { [COLOR=#BF0303]"ST3640[36]23AS"[/COLOR],    [COLOR=#BF0303]"SD1[5-9]"[/COLOR],    ATA_HORKAGE_NONCQ |
                        ATA_HORKAGE_FIRMWARE_WARN },

    { [COLOR=#BF0303]"ST3320[68]13AS"[/COLOR],    [COLOR=#BF0303]"SD1[5-9]"[/COLOR],    ATA_HORKAGE_NONCQ |
                        ATA_HORKAGE_FIRMWARE_WARN },

    [COLOR=#838183][I]/* drives which fail FPDMA_AA activation (some may freeze afterwards) */[/I][/COLOR]
    { [COLOR=#BF0303]"ST1000LM024 HN-M101MBB"[/COLOR], [COLOR=#BF0303]"2AR10001"[/COLOR],    ATA_HORKAGE_BROKEN_FPDMA_AA },
    { [COLOR=#BF0303]"ST1000LM024 HN-M101MBB"[/COLOR], [COLOR=#BF0303]"2BA30001"[/COLOR],    ATA_HORKAGE_BROKEN_FPDMA_AA },
    { [COLOR=#BF0303]"VB0250EAVER"[/COLOR],    [COLOR=#BF0303]"HPG7"[/COLOR],        ATA_HORKAGE_BROKEN_FPDMA_AA },

    [COLOR=#838183][I]/* Blacklist entries taken from Silicon Image 3124/3132[/I][/COLOR]
[COLOR=#838183][I]       Windows driver .inf file - also several Linux problem reports */[/I][/COLOR]
    { [COLOR=#BF0303]"HTS541060G9SA00"[/COLOR],    [COLOR=#BF0303]"MB3OC60D"[/COLOR],     ATA_HORKAGE_NONCQ, },
    { [COLOR=#BF0303]"HTS541080G9SA00"[/COLOR],    [COLOR=#BF0303]"MB4OC60D"[/COLOR],     ATA_HORKAGE_NONCQ, },
    { [COLOR=#BF0303]"HTS541010G9SA00"[/COLOR],    [COLOR=#BF0303]"MBZOC60D"[/COLOR],     ATA_HORKAGE_NONCQ, },

    [COLOR=#838183][I]/* https://bugzilla.kernel.org/show_bug.cgi?id=15573 */[/I][/COLOR]
    { [COLOR=#BF0303]"C300-CTFDDAC128MAG"[/COLOR],    [COLOR=#BF0303]"0001"[/COLOR],        ATA_HORKAGE_NONCQ, },

    [COLOR=#838183][I]/* devices which puke on READ_NATIVE_MAX */[/I][/COLOR]
    { [COLOR=#BF0303]"HDS724040KLSA80"[/COLOR],    [COLOR=#BF0303]"KFAOA20N"[/COLOR],    ATA_HORKAGE_BROKEN_HPA, },
    { [COLOR=#BF0303]"WDC WD3200JD-00KLB0"[/COLOR], [COLOR=#BF0303]"WD-WCAMR1130137"[/COLOR], ATA_HORKAGE_BROKEN_HPA },
    { [COLOR=#BF0303]"WDC WD2500JD-00HBB0"[/COLOR], [COLOR=#BF0303]"WD-WMAL71490727"[/COLOR], ATA_HORKAGE_BROKEN_HPA },
    { [COLOR=#BF0303]"MAXTOR 6L080L4"[/COLOR],    [COLOR=#BF0303]"A93.0500"[/COLOR],    ATA_HORKAGE_BROKEN_HPA },

    [COLOR=#838183][I]/* this one allows HPA unlocking but fails IOs on the area */[/I][/COLOR]
    { [COLOR=#BF0303]"OCZ-VERTEX"[/COLOR],            [COLOR=#BF0303]"1.30"[/COLOR],    ATA_HORKAGE_BROKEN_HPA },

    [COLOR=#838183][I]/* Devices which report 1 sector over size HPA */[/I][/COLOR]
    { [COLOR=#BF0303]"ST340823A"[/COLOR],        NULL,        ATA_HORKAGE_HPA_SIZE, },
    { [COLOR=#BF0303]"ST320413A"[/COLOR],        NULL,        ATA_HORKAGE_HPA_SIZE, },
    { [COLOR=#BF0303]"ST310211A"[/COLOR],        NULL,        ATA_HORKAGE_HPA_SIZE, },

    [COLOR=#838183][I]/* Devices which get the IVB wrong */[/I][/COLOR]
    { [COLOR=#BF0303]"QUANTUM FIREBALLlct10 05"[/COLOR], [COLOR=#BF0303]"A03.0900"[/COLOR], ATA_HORKAGE_IVB, },
    [COLOR=#838183][I]/* Maybe we should just blacklist TSSTcorp... */[/I][/COLOR]
    { [COLOR=#BF0303]"TSSTcorp CDDVDW SH-S202[HJN]"[/COLOR], [COLOR=#BF0303]"SB0[01]"[/COLOR],  ATA_HORKAGE_IVB, },

    [COLOR=#838183][I]/* Devices that do not need bridging limits applied */[/I][/COLOR]
    { [COLOR=#BF0303]"MTRON MSP-SATA*"[/COLOR],        NULL,    ATA_HORKAGE_BRIDGE_OK, },
    { [COLOR=#BF0303]"BUFFALO HD-QSU2/R5"[/COLOR],        NULL,    ATA_HORKAGE_BRIDGE_OK, },

    [COLOR=#838183][I]/* Devices which aren't very happy with higher link speeds */[/I][/COLOR]
    { [COLOR=#BF0303]"WD My Book"[/COLOR],            NULL,    ATA_HORKAGE_1_5_GBPS, },
    { [COLOR=#BF0303]"Seagate FreeAgent GoFlex"[/COLOR],    NULL,    ATA_HORKAGE_1_5_GBPS, },

    [COLOR=#838183][I]/*[/I][/COLOR]
[COLOR=#838183][I]     * Devices which choke on SETXFER.  Applies only if both the[/I][/COLOR]
[COLOR=#838183][I]     * device and controller are SATA.[/I][/COLOR]
[COLOR=#838183][I]     */[/I][/COLOR]
    { [COLOR=#BF0303]"PIONEER DVD-RW  DVRTD08"[/COLOR],    NULL,    ATA_HORKAGE_NOSETXFER },
    { [COLOR=#BF0303]"PIONEER DVD-RW  DVRTD08A"[/COLOR],    NULL,    ATA_HORKAGE_NOSETXFER },
    { [COLOR=#BF0303]"PIONEER DVD-RW  DVR-215"[/COLOR],    NULL,    ATA_HORKAGE_NOSETXFER },
    { [COLOR=#BF0303]"PIONEER DVD-RW  DVR-212D"[/COLOR],    NULL,    ATA_HORKAGE_NOSETXFER },
    { [COLOR=#BF0303]"PIONEER DVD-RW  DVR-216D"[/COLOR],    NULL,    ATA_HORKAGE_NOSETXFER },

    [COLOR=#838183][I]/* devices that don't properly handle queued TRIM commands */[/I][/COLOR]
    { [COLOR=#BF0303]"Micron_M500_*"[/COLOR],        NULL,    ATA_HORKAGE_NO_NCQ_TRIM |
                        ATA_HORKAGE_ZERO_AFTER_TRIM, },
    { [COLOR=#BF0303]"Crucial_CT*M500*"[/COLOR],        NULL,    ATA_HORKAGE_NO_NCQ_TRIM |
                        ATA_HORKAGE_ZERO_AFTER_TRIM, },
    { [COLOR=#BF0303]"Micron_M5[15]0_*"[/COLOR],        [COLOR=#BF0303]"MU01"[/COLOR],    ATA_HORKAGE_NO_NCQ_TRIM |
                        ATA_HORKAGE_ZERO_AFTER_TRIM, },
    { [COLOR=#BF0303]"Crucial_CT*M550*"[/COLOR],        [COLOR=#BF0303]"MU01"[/COLOR],    ATA_HORKAGE_NO_NCQ_TRIM |
                        ATA_HORKAGE_ZERO_AFTER_TRIM, },
    { [COLOR=#BF0303]"Crucial_CT*MX100*"[/COLOR],        [COLOR=#BF0303]"MU01"[/COLOR],    ATA_HORKAGE_NO_NCQ_TRIM |
                        ATA_HORKAGE_ZERO_AFTER_TRIM, },
    { [COLOR=#BF0303]"Samsung SSD 8*"[/COLOR],        NULL,    ATA_HORKAGE_NO_NCQ_TRIM |    <--------- I FOUND THIS INTERESTING! Samsung SSD 8** series with TRIM problems.
                        ATA_HORKAGE_ZERO_AFTER_TRIM, },
    { [COLOR=#BF0303]"FCCT*M500*"[/COLOR],            NULL,    ATA_HORKAGE_NO_NCQ_TRIM |
                        ATA_HORKAGE_ZERO_AFTER_TRIM, },

    [COLOR=#838183][I]/* devices that don't properly handle TRIM commands */[/I][/COLOR]
    { [COLOR=#BF0303]"SuperSSpeed S238*"[/COLOR],        NULL,    ATA_HORKAGE_NOTRIM, },

    [COLOR=#838183][I]/*[/I][/COLOR]
[COLOR=#838183][I]     * As defined, the DRAT (Deterministic Read After Trim) and RZAT[/I][/COLOR]
[COLOR=#838183][I]     * (Return Zero After Trim) flags in the ATA Command Set are[/I][/COLOR]
[COLOR=#838183][I]     * unreliable in the sense that they only define what happens if[/I][/COLOR]
[COLOR=#838183][I]     * the device successfully executed the DSM TRIM command. TRIM[/I][/COLOR]
[COLOR=#838183][I]     * is only advisory, however, and the device is free to silently[/I][/COLOR]
[COLOR=#838183][I]     * ignore all or parts of the request.[/I][/COLOR]
[COLOR=#838183][I]     *[/I][/COLOR]
[COLOR=#838183][I]     * Whitelist drives that are known to reliably return zeroes[/I][/COLOR]
[COLOR=#838183][I]     * after TRIM.[/I][/COLOR]
[COLOR=#838183][I]     */[/I][/COLOR]

    [COLOR=#838183][I]/*[/I][/COLOR]
[COLOR=#838183][I]     * The intel 510 drive has buggy DRAT/RZAT. Explicitly exclude[/I][/COLOR]
[COLOR=#838183][I]     * that model before whitelisting all other intel SSDs.[/I][/COLOR]
[COLOR=#838183][I]     */[/I][/COLOR]
    { [COLOR=#BF0303]"INTEL*SSDSC2MH*"[/COLOR],        NULL,    [COLOR=#B07E00]0[/COLOR], },

    { [COLOR=#BF0303]"Micron*"[/COLOR],            NULL,    ATA_HORKAGE_ZERO_AFTER_TRIM, },
    { [COLOR=#BF0303]"Crucial*"[/COLOR],            NULL,    ATA_HORKAGE_ZERO_AFTER_TRIM, },
    { [COLOR=#BF0303]"INTEL*SSD*"[/COLOR],         NULL,    ATA_HORKAGE_ZERO_AFTER_TRIM, },
    { [COLOR=#BF0303]"SSD*INTEL*"[/COLOR],            NULL,    ATA_HORKAGE_ZERO_AFTER_TRIM, },
    { [COLOR=#BF0303]"Samsung*SSD*"[/COLOR],        NULL,    ATA_HORKAGE_ZERO_AFTER_TRIM, },
    { [COLOR=#BF0303]"SAMSUNG*SSD*"[/COLOR],        NULL,    ATA_HORKAGE_ZERO_AFTER_TRIM, },
    { [COLOR=#BF0303]"ST[1248][0248]0[FH]*"[/COLOR],    NULL,    ATA_HORKAGE_ZERO_AFTER_TRIM, },

    [COLOR=#838183][I]/*[/I][/COLOR]
[COLOR=#838183][I]     * Some WD SATA-I drives spin up and down erratically when the link[/I][/COLOR]
[COLOR=#838183][I]     * is put into the slumber mode.  We don't have full list of the[/I][/COLOR]
[COLOR=#838183][I]     * affected devices.  Disable LPM if the device matches one of the[/I][/COLOR]
[COLOR=#838183][I]     * known prefixes and is SATA-1.  As a side effect LPM partial is[/I][/COLOR]
[COLOR=#838183][I]     * lost too.[/I][/COLOR]
[COLOR=#838183][I]     *[/I][/COLOR]
[COLOR=#838183][I]     * https://bugzilla.kernel.org/show_bug.cgi?id=57211[/I][/COLOR]
[COLOR=#838183][I]     */[/I][/COLOR]
    { [COLOR=#BF0303]"WDC WD800JD-*"[/COLOR],        NULL,    ATA_HORKAGE_WD_BROKEN_LPM },
    { [COLOR=#BF0303]"WDC WD1200JD-*"[/COLOR],        NULL,    ATA_HORKAGE_WD_BROKEN_LPM },
    { [COLOR=#BF0303]"WDC WD1600JD-*"[/COLOR],        NULL,    ATA_HORKAGE_WD_BROKEN_LPM },
    { [COLOR=#BF0303]"WDC WD2000JD-*"[/COLOR],        NULL,    ATA_HORKAGE_WD_BROKEN_LPM },
    { [COLOR=#BF0303]"WDC WD2500JD-*"[/COLOR],        NULL,    ATA_HORKAGE_WD_BROKEN_LPM },
    { [COLOR=#BF0303]"WDC WD3000JD-*"[/COLOR],        NULL,    ATA_HORKAGE_WD_BROKEN_LPM },
    { [COLOR=#BF0303]"WDC WD3200JD-*"[/COLOR],        NULL,    ATA_HORKAGE_WD_BROKEN_LPM },

    [COLOR=#838183][I]/* End Marker */[/I][/COLOR]
    { }
};

Checking the Samsung 8* bug I found that it was fixed.

So, which is better, cfq or deadline?
Basically, neither, for the 4.8.0-21 kernel using the EXT4 fs, although deadline is a dog on the EXT3.
http://kernel.ubuntu.com/~cking/fs-t...-os/index.html

Sadly, no results are given for the Btrfs.

So, I will just leave mine set to deadline, which is the default for the 16.04 release.

I was wondering about the NOOP schedular and found this on the WIkipedia article:

However, NOOP is not necessarily the preferred I/O scheduler for the above scenarios. As with any performance tuning, all guidance will be based on observed work load patterns (undermining one's ability to create simplistic rules of thumb). If there is contention for available I/O bandwidth from other applications, it is still possible that other schedulers will generate better performance by virtue of more intelligently carving up that bandwidth for the applications deemed most important. For example, running an LDAP directory server may benefit from deadline's read preference and latency guarantees. At the same time, a user with a desktop system running many different applications may want to have access to CFQ's tunables or its ability to prioritize bandwidth for particular applications over others (ionice).

While watching some processes on KSysmonitor I noticed that delays appeared to be cause by "disk sleep" indications. I changed the HD scheduling to improve performance, but didn't notice any improvements. "disk sleep" msgs still appeared. Maybe I should try cfq.

From RH's CFQ configuration documentation (I don't know how much of this applies to Ubuntu/Kubuntu):

Code:

[COLOR=#1A1A1A][FONT=&amp][B]6.3.5. Tuning the cfq scheduler[/B]



[/FONT][/COLOR]
[COLOR=#1A1A1A][FONT=&amp]When cfq is in use, processes are placed into three classes: real time, best effort, and idle. All real time processes are scheduled before any best effort processes, which are scheduled before any idle processes. By default, processes are classed as best effort. You can manually adjust the class of a process with the ionice command.[/FONT][/COLOR]
[COLOR=#1A1A1A][FONT=&amp]You can further adjust the behavior of the cfq scheduler with the following parameters. These parameters are set on a per-device basis by altering the specified files under the /sys/block/[I]devname[/I]/queue/iosched directory.[/FONT][/COLOR]
[COLOR=#1A1A1A][FONT=&amp]
⁠back_seek_max
The maximum distance in kilobytes that cfq will perform a backward seek. The default value is 16 KB. Backward seeks typically damage performance, so large values are not recommended.

⁠back_seek_penalty
The multiplier applied to backward seeks when the disk head is deciding whether to move forward or backward. The default value is 2. If the disk head position is at 1024 KB, and there are equidistant requests in the system (1008 KB and 1040 KB, for example), the [I]back_seek_penalty[/I] is applied to backward seek distances and the disk moves forward.

⁠fifo_expire_async
The length of time in milliseconds that an asynchronous (buffered write) request can remain unserviced. After this amount of time expires, a single starved asynchronous request is moved to the dispatch list. The default value is 250 milliseconds.
⁠
fifo_expire_sync
The length of time in milliseconds that a synchronous (read or O_DIRECT write) request can remain unserviced. After this amount of time expires, a single starved synchronous request is moved to the dispatch list. The default value is 125 milliseconds.

⁠group_idle
This parameter is set to 0 (disabled) by default. When set to 1 (enabled), the cfq scheduler idles on the last process that is issuing I/O in a control group. This is useful when using proportional weight I/O control groups and when [I]slice_idle[/I] is set to 0 (on fast storage).

⁠group_isolation
This parameter is set to 0 (disabled) by default. When set to 1 (enabled), it provides stronger isolation between groups, but reduces throughput, as fairness is applied to both random and sequential workloads. When [I]group_isolation[/I] is disabled (set to 0), fairness is provided to sequential workloads only. For more information, see the installed documentation in /usr/share/doc/kernel-doc-version/Documentation/cgroups/blkio-controller.txt.

⁠low_latency
This parameter is set to 1 (enabled) by default. When enabled, cfq favors fairness over throughput by providing a maximum wait time of 300 ms for each process issuing I/O on a device. When this parameter is set to 0 (disabled), target latency is ignored and each process receives a full time slice.

⁠quantum
This parameter defines the number of I/O requests that cfq sends to one device at one time, essentially limiting queue depth. The default value is 8 requests. The device being used may support greater queue depth, but increasing the value of quantum will also increase latency, especially for large sequential write work loads.

⁠slice_async
This parameter defines the length of the time slice (in milliseconds) allotted to each process issuing asynchronous I/O requests. The default value is 40 milliseconds.

⁠slice_idle
This parameter specifies the length of time in milliseconds that cfq idles while waiting for further requests. The default value is 0 (no idling at the queue or service tree level). The default value is ideal for throughput on external RAID storage, but can degrade throughput on internal non-RAID storage as it increases the overall number of seek operations.

⁠slice_sync
This parameter defines the length of the time slice (in milliseconds) allotted to each process issuing synchronous I/O requests. The default value is 100 ms.
[/FONT][/COLOR]
[COLOR=#1A1A1A][FONT=&amp][B]6.3.5.1. Tuning cfq for fast storage[/B]




The cfq scheduler is not recommended for hardware that does not suffer a large seek penalty, such as fast external storage arrays or solid-state disks. If your use case requires cfq to be used on this storage, you will need to edit the following configuration files:
[LIST][*]Set /sys/block/[I]devname[/I]/queue/ionice/slice_idle to 0[*]Set /sys/block/[I]devname[/I]/queue/ionice/quantum to 64[*]Set /sys/block/[I]devname[/I]/queue/ionice/group_idle to 1[/LIST]

[/FONT][/COLOR]

**wizard10000** · Apr 10, 2017, 10:01 AM

Originally posted by GreyGeek View Post

...Does cfq actually work better on rotating storage devices when compared to deadline?

Maybe. Found a pretty good read here -

http://stackoverflow.com/questions/9...dline-and-noop

The CFQ scheduler allows you to set priorities via the ionice tool or the ioprio_set system call. This allows giving precedence to some processes or forcing others to do their IO only when the system's block devices are relatively idle. The queues are implemented by segregating the IO requests from processes into queues, and handling the requests from each queue similar to CPU scheduling. Details on configuring it can be found in https://www.kernel.org/Documentation...fq-iosched.txt.

The deadline scheduler by contrast looks at all writes from all processes at once; it sorts the writes by sector number, and writes them all in linear fashion. The deadlines means that it tries to write each block before its deadline expires, but within those deadlines, is free to re-arrange blocks as it sees fit. Details on configuring it can be found in https://www.kernel.org/Documentation...ne-iosched.txt

From what I've read here and in linked kernel.org documents, it seems to me that using deadline on a rotating disk *may* cause stuttering that wouldn't happen with CFQ. SSD are fast enough that forcing disk writes before the deadline expires is probably going to have minimal impact on performance.

**oshunluvr** · Apr 10, 2017, 10:11 AM

The Ubuntu Kernel testing team says currently, deadline is best for the current kernels. Of course, if your use is non-standard you might see a difference: http://kernel.ubuntu.com/~cking/fs-tests/feb-2017/

**acheron** · Apr 10, 2017, 10:31 AM

Originally posted by acheron View Post

Need to find a better reference for this, but...

Not so much reference, but confirmation.

http://changelogs.ubuntu.com/changel...9.21/changelog

linux (4.10.0-3.5) zesty; urgency=low

* KVM module handling different per Architecture - ppc64el (LP: #1657734)
- [Config] powerpc: Add kvm-hv and kvm-pr to the generic inclusion list

* ENA network driver moved to -extra (LP: #1657767)
- [Config] Move Amazon ENA network driver to the main kernel package

* [Hyper-V] mkfs regression in 4.10 fixed by patch in "for-4.11"
(LP: #1657539)
- block: relax check on sg gap

* i915 module requests unreleased GUC firmware files (LP: #1626740)
- SAUCE: (no-up) i915: Remove MODULE_FIRMWARE statements for unreleased
firmware

* [17.04 FEAT] Integrate kernel message catalogue for s390x into Ubuntu
distribution (LP: #1628889)
- [Config] CONFIG_KMSG_IDS=y for s390
- SAUCE: s390 Kernel message catalog

* Miscellaneous Ubuntu changes
- ubuntu: vbox -- Update to 5.1.14-dfsg-1
- SAUCE: vbox -- remove .readlink assignment
- Enable vbox build
- [Config] CONFIG_DEFAULT_IOSCHED=cfq
- [Config] Bump CONFIG_NR_CPUS up to 256 on arm64
- [Config] Fix up s390x config options changed during 4.10 rebase
- [Config] Update annotations for 4.10
- Disable all flavors for the powerpc architecture

[ Upstream Kernel Changes ]

* rebase to v4.10-rc5

-- Seth Forshee <seth.forshee@canonical.com> Mon, 23 Jan 2017 15:48:35 -0600

**GreyGeek** · Apr 10, 2017, 10:40 AM

So, Zesty defaults to cfq! Wonder why the change, since on my 16.04 base it is deadline?

I decided to leave my I/O Scheduler as deadline, even though I do not have an SSD's on board, and pendrives work fine. The reason is that the kernel tests of the schedulers showed, IMO, insignificant differences between CFQ and Deadline on EXT4. I have no clue how they would differ on my Btrfs, with its COW, but I'm satisfied with its overall performance. It is the default that "RealTime" scheduling is not allowed for non root users, which is why one is asked for the root password when they change the ionice using KSystemMonitor.

**acheron** · Apr 10, 2017, 11:16 AM

Originally posted by GreyGeek View Post

So, Zesty defaults to cfq! Wonder why the change, since on my 16.04 base it is deadline?

On the change to CFQ by default from the kernel team for kernel 4.10 :

http://kernel.ubuntu.com/git/ubuntu/...146fcd9a28070d

UBUNTU: [Config] CONFIG_DEFAULT_IOSCHED=cfq

Hi there,

after several days of running (way too) many tests, I've got some data to show that it may be a good idea to drop the DEADLINE I/O scheduler for Zesty and move to CFQ with buffered writeback throttling (WBT) + WBT_MQ (WBT multi-queu) enabled.

We originally moved to DEADLINE because of the issues with slow I/O (say to flash drives) causing applications to hang while blocked on the slow I/O being flushed out. It seems that with the recent 4.10 WBT driver and (possibly other block driver changes) we see some performance benefits also with CFQ, namely:

1. Faster boots. On a 8 thread Xeon CPU E3-1275 I'm seeing a reduction in usertime boots from 33.92s (Deadline) to ~24.5s (CFQ)

See: http://kernel.ubuntu.com/~cking/wbt/iosched-boot.ods

2. Faster build times (yay!) and better performance when writing across multiple devices (especially when one of these is a slow flash device).

See: http://kernel.ubuntu.com/~cking/wbt/blk-mq-sq.ods

There are some places where CFQ + MQ is less performant than CFQ + MQ + SQ, and vice-versa. However, my general feeling for Zesty is that we should give this a try as it seems to work well.

The config changes are:

1. disable CONFIG_DEFAULT_DEADLINE
2. enable CONFIG_DEFAULT_CFQ
3. enable CONFIG_BLK_WBT
4. enable CONFIG_BLK_WBT_MQ

This will give us plenty of time to give this a good test in the next few months and revert them if we find any problematic corner cases. (The win on boot time, build times and writes to slow devices) is probably the most compelling choice for these changes IMHO.

**GreyGeek** · Apr 10, 2017, 11:32 AM

Thanks, Acheron!
So, on my 16.04 4.8.0-42 generic deadline is still preferred?

**oshunluvr** · Apr 10, 2017, 11:48 AM

Yeah, my understanding is added features in 4.10 kernel give CFQ a slight advantage. BFQ should be even better, if they ever get into the kernel.

Announcement

Stll wrong i/o scheduler used in 17.04?

Stll wrong i/o scheduler used in 17.04?

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment