Package: util-linux
Version: 2.20.1-5.7
Followup-For: Bug #749954
Dear Maintainer,
*** Reporter, please consider answering these questions, where appropriate ***
* What led up to the situation?
* What exactly did you do (or not do) that was effective (or
ineffective)?
By doubling the readahead count for the disk to 512 with hdparm, the i/o
starvation disappeared:
# hdparm /dev/sda
/dev/sda:
multcount = 16 (on)
IO_support = 1 (32-bit)
readonly = 0 (off)
readahead = 512 (on)
geometry = 60801/255/63, sectors = 976773168, start = 0
I'm not sure where in the Debian documentation such information might
go to provide some performance tuning advice. It took a few reads of the
hdparm manual page description of readahead to realise that it affected
the filesystem buffering. I'm not even sure where the default readahead
value gets set in the kernel.
This bug can be closed, but I'd appreciate any suggestions where the
solution should be documented.
* What was the outcome of this action?
* What outcome did you expect instead?
*** End of the template - remove these template lines ***
-- System Information:
Debian Release: jessie/sid
APT prefers unstable
APT policy: (500, 'unstable'), (500, 'testing'), (500, 'stable'), (500,
'oldstable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Kernel: Linux 3.15.0-rc7+ (SMP w/4 CPU cores)
Locale: LANG=en_AU.UTF-8, LC_CTYPE=en_AU.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash
Versions of packages util-linux depends on:
ii debconf [debconf-2.0] 1.5.53
ii dpkg 1.17.9
ii initscripts 2.88dsf-53
ii install-info 5.2.0.dfsg.1-3
ii libblkid1 2.20.1-5.7
ii libc6 2.18-7
ii libncurses5 5.9+20140118-1
ii libselinux1 2.3-1
ii libslang2 2.2.4-16
ii libtinfo5 5.9+20140118-1
ii libuuid1 2.20.1-5.7
ii lsb-base 4.1+Debian12
ii tzdata 2014d-1
ii zlib1g 1:1.2.8.dfsg-1
util-linux recommends no packages.
Versions of packages util-linux suggests:
ii dosfstools 3.0.26-2
ii kbd 1.15.5-1
ii util-linux-locales 2.20.1-5.7
-- debconf information:
util-linux/noauto-with-nonzero-passnum:
--
To UNSUBSCRIBE, email to [email protected]
with a subject of "unsubscribe". Trouble? Contact [email protected]