Debian Bug report logs - #232240
e2fsprogs: -c <number of blocks> should perhaps default to a higher number

version graph

Package: e2fsprogs; Maintainer for e2fsprogs is Theodore Y. Ts'o <tytso@mit.edu>; Source for e2fsprogs is src:e2fsprogs.

Reported by: chris@chiappa.net

Date: Wed, 11 Feb 2004 14:18:02 UTC

Severity: wishlist

Found in version 1.34+1.35-WIP-2004.01.31-1

Fixed in version e2fsprogs/1.35-1

Done: tytso@mit.edu (Theodore Y. Ts'o)

Bug is archived. No further changes may be made.

Toggle useless messages

View this report as an mbox folder, status mbox, maintainer mbox


Report forwarded to debian-bugs-dist@lists.debian.org, tytso@mit.edu (Theodore Y. Ts'o):
Bug#232240; Package e2fsprogs. Full text and rfc822 format available.

Acknowledgement sent to chris@chiappa.net:
New Bug report received and forwarded. Copy sent to tytso@mit.edu (Theodore Y. Ts'o). Full text and rfc822 format available.

Message #5 received at submit@bugs.debian.org (full text, mbox):

From: Chris Chiappa <chris+debian@chiappa.net>
To: Debian Bug Tracking System <submit@bugs.debian.org>
Subject: e2fsprogs: -c <number of blocks> should perhaps default to a higher number
Date: Wed, 11 Feb 2004 09:10:37 -0500
Package: e2fsprogs
Version: 1.34+1.35-WIP-2004.01.31-1
Severity: wishlist


On modern hardware, it seems like the default of -c 16 might be a long in
the tooth.  Running badblocks -w on a new 80GB drive with the -c 16 looks
like it would have taken about 18 hours or so.  Increasing it to -c 2048
seems to have reduced the time to ~2 hours (both estimated but within
the ballpark).  The manpage implies that the principal drawback to a high
number is memory usage, but with machines these days rarely having less than
128MB, it seems unlikely anyone is going to have problems there.

-- System Information:
Debian Release: testing/unstable
  APT prefers unstable
  APT policy: (500, 'unstable')
Architecture: i386 (i686)
Kernel: Linux 2.4.24
Locale: LANG=C, LC_CTYPE=C

Versions of packages e2fsprogs depends on:
ii  e2fslibs      1.34+1.35-WIP-2004.01.31-1 The EXT2 filesystem libraries
ii  libblkid1     1.34+1.35-WIP-2004.01.31-1 Block device id library
ii  libc6         2.3.2.ds1-11               GNU C Library: Shared libraries an
ii  libcomerr2    1.34+1.35-WIP-2004.01.31-1 The Common Error Description libra
ii  libss2        1.34+1.35-WIP-2004.01.31-1 Command-line interface parsing lib
ii  libuuid1      1.34+1.35-WIP-2004.01.31-1 Universally unique id library

-- no debconf information




Information forwarded to debian-bugs-dist@lists.debian.org, tytso@mit.edu (Theodore Y. Ts'o):
Bug#232240; Package e2fsprogs. Full text and rfc822 format available.

Acknowledgement sent to Theodore Ts'o <tytso@mit.edu>:
Extra info received and forwarded to list. Copy sent to tytso@mit.edu (Theodore Y. Ts'o). Full text and rfc822 format available.

Message #10 received at 232240@bugs.debian.org (full text, mbox):

From: Theodore Ts'o <tytso@mit.edu>
To: chris@chiappa.net, 232240@bugs.debian.org
Subject: Re: Bug#232240: e2fsprogs: -c <number of blocks> should perhaps default to a higher number
Date: Fri, 13 Feb 2004 15:02:34 -0500
On Wed, Feb 11, 2004 at 09:10:37AM -0500, Chris Chiappa wrote:
> 
> On modern hardware, it seems like the default of -c 16 might be a long in
> the tooth.  Running badblocks -w on a new 80GB drive with the -c 16 looks
> like it would have taken about 18 hours or so.  Increasing it to -c 2048
> seems to have reduced the time to ~2 hours (both estimated but within
> the ballpark).  The manpage implies that the principal drawback to a high
> number is memory usage, but with machines these days rarely having less than
> 128MB, it seems unlikely anyone is going to have problems there.

Good point.  What blocksize are you using, out of curiosity?  The
default 1k or 4k blocksize?  Certainly 16k at a time is pretty small
these days.

						- Ted



Information forwarded to debian-bugs-dist@lists.debian.org, tytso@mit.edu (Theodore Y. Ts'o):
Bug#232240; Package e2fsprogs. Full text and rfc822 format available.

Acknowledgement sent to chris@chiappa.net:
Extra info received and forwarded to list. Copy sent to tytso@mit.edu (Theodore Y. Ts'o). Full text and rfc822 format available.

Message #15 received at 232240@bugs.debian.org (full text, mbox):

From: Chris Chiappa <chris@chiappa.net>
To: Theodore Ts'o <tytso@mit.edu>
Cc: 232240@bugs.debian.org
Subject: Re: Bug#232240: e2fsprogs: -c <number of blocks> should perhaps default to a higher number
Date: Fri, 13 Feb 2004 21:53:31 -0500
On Fri, Feb 13, 2004 at 03:02:34PM -0500, Theodore Ts'o wrote:
> Good point.  What blocksize are you using, out of curiosity?  The
> default 1k or 4k blocksize?  Certainly 16k at a time is pretty small
> these days.
-c was the only think I tweaked, so the blocksize would have been the default.

-- 

..ooOO chris@chiappa.net              | My opinions are my own  OOoo..
..ooOO chris.chiappa@oracle.com       | and certainly not those OOoo..
..ooOO http://www.chiappa.net/~chris/ | of my employer          OOoo..



Information forwarded to debian-bugs-dist@lists.debian.org, tytso@mit.edu (Theodore Y. Ts'o):
Bug#232240; Package e2fsprogs. Full text and rfc822 format available.

Acknowledgement sent to Theodore Ts'o <tytso@mit.edu>:
Extra info received and forwarded to list. Copy sent to tytso@mit.edu (Theodore Y. Ts'o). Full text and rfc822 format available.

Message #20 received at 232240@bugs.debian.org (full text, mbox):

From: Theodore Ts'o <tytso@mit.edu>
To: chris@chiappa.net, 232240@bugs.debian.org
Subject: Re: Bug#232240: e2fsprogs: -c <number of blocks> should perhaps default to a higher number
Date: Sun, 22 Feb 2004 08:42:30 -0500
On Fri, Feb 13, 2004 at 09:53:31PM -0500, Chris Chiappa wrote:
> On Fri, Feb 13, 2004 at 03:02:34PM -0500, Theodore Ts'o wrote:
> > Good point.  What blocksize are you using, out of curiosity?  The
> > default 1k or 4k blocksize?  Certainly 16k at a time is pretty small
> > these days.
> -c was the only think I tweaked, so the blocksize would have been the default.

Hmm....  I just did some tests using the command:

	time badblocks -svw -c <n> /dev/hda2 131072

and varied <n> from 16, 32, 64, 128, 256, and 1024.  I tried it on a
laptop harddrive running Linux 2.6, as well as a 80gig Maxtor IDE disk
on a Linux 2.4 system, and just for yucks and grins, I tried it on an
older 18 gig SCSI2-LVD disk, on a 2-CPU Pentium II-Xeon running Linux
2.4.  On all cases, the clock time required to do the badblocks
read/write test was more-or-less identical, and in a few cases the
time required to do the test actually went *up* with larger values of
-c.  (I suspect the latter was due to natural variance in the test.)

Can you tell me a bit more about the system where you got your
numbers, and how specifically you got them?  I can increase the
default some, and intuitively it makes sense that the -c default
should probably be at least 64 these days, but I'm having trouble
justifying 1024, and I'm certainly not seeing the sort of performance
differentials which you reported.

Many thanks,

						- Ted




Information forwarded to debian-bugs-dist@lists.debian.org, tytso@mit.edu (Theodore Y. Ts'o):
Bug#232240; Package e2fsprogs. Full text and rfc822 format available.

Acknowledgement sent to chris@chiappa.net:
Extra info received and forwarded to list. Copy sent to tytso@mit.edu (Theodore Y. Ts'o). Full text and rfc822 format available.

Message #25 received at 232240@bugs.debian.org (full text, mbox):

From: Chris Chiappa <chris@chiappa.net>
To: Theodore Ts'o <tytso@mit.edu>
Cc: 232240@bugs.debian.org
Subject: Re: Bug#232240: e2fsprogs: -c <number of blocks> should perhaps default to a higher number
Date: Sun, 22 Feb 2004 10:11:19 -0500
On Sun, Feb 22, 2004 at 08:42:30AM -0500, Theodore Ts'o wrote:
> Can you tell me a bit more about the system where you got your
> numbers, and how specifically you got them?  I can increase the
> default some, and intuitively it makes sense that the -c default
> should probably be at least 64 these days, but I'm having trouble
> justifying 1024, and I'm certainly not seeing the sort of performance
> differentials which you reported.
Interesting.  Unfortunately the drives are in use now and I can't easily
pull them to repeat the test.  I was seeing similar results with two drives:
a Seagate and a Hitachi, both 7200RPM ~80GB.  They were plugged into an
Athlon XP 2500+ (1.8GHz) on an Asus A7V600 motherboard via an 80 core IDE
cable.  I'm just using the Via chipset IDE controller on the board, not the
RAID SATA on it.

Looking at .bash_history, it looks like I did tune the drives a bit with
hdparm beforehand.

Ahhh, I think I might have just seen the difference.  Doing a read-only test
on a different machine which now has the two drives in it, I see big
differences when running *two badblocks at the same time*.  They're both on
the same IDE controller (this time on a Highpoint HPT366 on an ABIT BP6).
Doing only one at a time I see roughly similar throughput rates fiddling
with -c.  Running them both at the same time however causes the one with the
higher block count to run away from the other.  ^Cing after about 10 seconds:

Different sizes:
lumberjack:~# badblocks -c 64 -v /dev/hdg
Checking blocks 0 to 80418240
Checking for bad blocks (read-only test):    105216/ 80418240
lumberjack:~# 
vs
lumberjack:~# badblocks -c 1024 -v /dev/hdh
Checking blocks 0 to 78150744
Checking for bad blocks (read-only test):    385024/ 78150744
lumberjack:~# 

Same sizes:
Checking blocks 0 to 80418240
Checking for bad blocks (read-only test):    197328/ 80418240
lumberjack:~#
vs
lumberjack:~# badblocks -v /dev/hdh
Checking blocks 0 to 78150744
Checking for bad blocks (read-only test):    195968/ 78150744
lumberjack:~#

and

lumberjack:~# badblocks -c 1024 -v /dev/hdg
Checking blocks 0 to 80418240
Checking for bad blocks (read-only test):    221184/ 80418240
lumberjack:~#
vs
lumberjack:~# badblocks -c 1024 -v /dev/hdh
Checking blocks 0 to 78150744
Checking for bad blocks (read-only test):    203776/ 78150744
lumberjack:~#

I'm fairly sure that on the Athlon, I was seeing a bigger performance
difference - without the -c I had left both running in parallel for over 12
hours before I restarted them, with the ^C I believe it finished in the
order of 3-4 hours.  So I guess this could be heavily dependant on the IDE
chipset or somesuch.

-- 

..ooOO chris@chiappa.net              | My opinions are my own  OOoo..
..ooOO chris.chiappa@oracle.com       | and certainly not those OOoo..
..ooOO http://www.chiappa.net/~chris/ | of my employer          OOoo..



Information forwarded to debian-bugs-dist@lists.debian.org, tytso@mit.edu (Theodore Y. Ts'o):
Bug#232240; Package e2fsprogs. Full text and rfc822 format available.

Acknowledgement sent to Theodore Ts'o <tytso@mit.edu>:
Extra info received and forwarded to list. Copy sent to tytso@mit.edu (Theodore Y. Ts'o). Full text and rfc822 format available.

Message #30 received at 232240@bugs.debian.org (full text, mbox):

From: Theodore Ts'o <tytso@mit.edu>
To: chris@chiappa.net, 232240@bugs.debian.org
Subject: Re: Bug#232240: e2fsprogs: -c <number of blocks> should perhaps default to a higher number
Date: Sun, 22 Feb 2004 15:52:10 -0500
On Sun, Feb 22, 2004 at 10:11:19AM -0500, Chris Chiappa wrote:
> Ahhh, I think I might have just seen the difference.  Doing a read-only test
> on a different machine which now has the two drives in it, I see big
> differences when running *two badblocks at the same time*.  They're both on
> the same IDE controller (this time on a Highpoint HPT366 on an ABIT BP6).
> Doing only one at a time I see roughly similar throughput rates fiddling
> with -c.  Running them both at the same time however causes the one with the
> higher block count to run away from the other.  

I'm not seing this on my system with SCSI disks, and I can't really do
the test on my other machines without doing some hardware
re-arranagements.  That's not surpising that it would only show up
with IDE.  That's because since you can only talk to one disk at a
time when you have two disks connected to the same IDE controller.
(There's a reason why Google only bothers to put one disk per IDE
controller; two disks per IDE controller is fine if you need the raw
storage, but not if you want maximum disk transfer bandwidth.)

Based on this, I will increase the default size, but probably not to
1024, since trying to do two IDE disks at the same time is probably a
bad idea in general.

						- Ted



Tags added: pending Request was from "Theodore Ts'o" <tytso@mit.edu> to control@bugs.debian.org. Full text and rfc822 format available.

Reply sent to tytso@mit.edu (Theodore Y. Ts'o):
You have taken responsibility. Full text and rfc822 format available.

Notification sent to chris@chiappa.net:
Bug acknowledged by developer. Full text and rfc822 format available.

Message #37 received at 232240-close@bugs.debian.org (full text, mbox):

From: tytso@mit.edu (Theodore Y. Ts'o)
To: 232240-close@bugs.debian.org
Subject: Bug#232240: fixed in e2fsprogs 1.35-1
Date: Sat, 28 Feb 2004 11:17:08 -0500
Source: e2fsprogs
Source-Version: 1.35-1

We believe that the bug you reported is fixed in the latest version of
e2fsprogs, which is due to be installed in the Debian FTP archive:

comerr-dev_2.1-1.35-1_i386.deb
  to pool/main/e/e2fsprogs/comerr-dev_2.1-1.35-1_i386.deb
e2fsck-static_1.35-1_i386.deb
  to pool/main/e/e2fsprogs/e2fsck-static_1.35-1_i386.deb
e2fslibs-dev_1.35-1_i386.deb
  to pool/main/e/e2fsprogs/e2fslibs-dev_1.35-1_i386.deb
e2fslibs_1.35-1_i386.deb
  to pool/main/e/e2fsprogs/e2fslibs_1.35-1_i386.deb
e2fsprogs-udeb_1.35-1_i386.udeb
  to pool/main/e/e2fsprogs/e2fsprogs-udeb_1.35-1_i386.udeb
e2fsprogs_1.35-1.diff.gz
  to pool/main/e/e2fsprogs/e2fsprogs_1.35-1.diff.gz
e2fsprogs_1.35-1.dsc
  to pool/main/e/e2fsprogs/e2fsprogs_1.35-1.dsc
e2fsprogs_1.35-1_i386.deb
  to pool/main/e/e2fsprogs/e2fsprogs_1.35-1_i386.deb
e2fsprogs_1.35.orig.tar.gz
  to pool/main/e/e2fsprogs/e2fsprogs_1.35.orig.tar.gz
libblkid-dev_1.35-1_i386.deb
  to pool/main/e/e2fsprogs/libblkid-dev_1.35-1_i386.deb
libblkid1-udeb_1.35-1_i386.udeb
  to pool/main/e/e2fsprogs/libblkid1-udeb_1.35-1_i386.udeb
libblkid1_1.35-1_i386.deb
  to pool/main/e/e2fsprogs/libblkid1_1.35-1_i386.deb
libcomerr2_1.35-1_i386.deb
  to pool/main/e/e2fsprogs/libcomerr2_1.35-1_i386.deb
libss2_1.35-1_i386.deb
  to pool/main/e/e2fsprogs/libss2_1.35-1_i386.deb
libuuid1-udeb_1.35-1_i386.udeb
  to pool/main/e/e2fsprogs/libuuid1-udeb_1.35-1_i386.udeb
libuuid1_1.35-1_i386.deb
  to pool/main/e/e2fsprogs/libuuid1_1.35-1_i386.deb
ss-dev_2.0-1.35-1_i386.deb
  to pool/main/e/e2fsprogs/ss-dev_2.0-1.35-1_i386.deb
uuid-dev_1.2-1.35-1_i386.deb
  to pool/main/e/e2fsprogs/uuid-dev_1.2-1.35-1_i386.deb



A summary of the changes between this version and the previous one is
attached.

Thank you for reporting the bug, which will now be closed.  If you
have further comments please address them to 232240@bugs.debian.org,
and the maintainer will reopen the bug report if appropriate.

Debian distribution maintenance software
pp.
Theodore Y. Ts'o <tytso@mit.edu> (supplier of updated e2fsprogs package)

(This message was generated automatically at their request; if you
believe that there is a problem with it please contact the archive
administrators by mailing ftpmaster@debian.org)


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Format: 1.7
Date: Sat, 28 Feb 2004 10:14:19 -0500
Source: e2fsprogs
Binary: e2fslibs-dev libblkid1-udeb libblkid1 comerr-dev libuuid1 ss-dev uuid-dev e2fslibs e2fsck-static e2fsprogs-udeb libuuid1-udeb e2fsprogs libblkid-dev libcomerr2 libss2
Architecture: source i386
Version: 1.35-1
Distribution: unstable
Urgency: low
Maintainer: Theodore Y. Ts'o <tytso@mit.edu>
Changed-By: Theodore Y. Ts'o <tytso@mit.edu>
Description: 
 comerr-dev - The Common Error Description library - headers and static librari
 e2fsck-static - A statically-linked version of the ext2 filesystem checker
 e2fslibs   - The EXT2 filesystem libraries
 e2fslibs-dev - The EXT2 filesystem libraries - headers and static libraries
 e2fsprogs  - The EXT2 file system utilities and libraries
 e2fsprogs-udeb - A stripped-down versions of e2fsprogs, for debian-installer (udeb)
 libblkid-dev - Block device id library - headers and static libraries
 libblkid1  - Block device id library
 libblkid1-udeb - Block device id library (udeb)
 libcomerr2 - The Common Error Description library
 libss2     - Command-line interface parsing library
 libuuid1   - Universally unique id library
 libuuid1-udeb - Universally unique id library (udeb)
 ss-dev     - Command-line interface parsing library - headers and static libra
 uuid-dev   - Universally unique id library - headers and static libraries
Closes: 232240 234828 234993 235280
Changes: 
 e2fsprogs (1.35-1) unstable; urgency=low
 .
   * New upstream version.
   * Fix "badblocks -t random". (Closes: #234828)
   * Fix "e2fsck -k".  (Closes: #234993)
   * Change badblock's default number of blocks tested at once from
     16 to 64.  (Closes: #232240)
   * ss-dev and comerr-dev now use a versioned dependency for libss2 and
     libcomerr2, respectively.  (Closes: #235280)
Files: 
 cb9bcabda52c282f7d67deffc4f0f978 764 base required e2fsprogs_1.35-1.dsc
 8d25ffd60d405ef32d341704a2323807 3152299 base required e2fsprogs_1.35.orig.tar.gz
 f12807e3984739f9c369f42363ffe151 20 base required e2fsprogs_1.35-1.diff.gz
 5a7b6ee7c2a8510db0238cf4d4aef6c5 281540 admin optional e2fsck-static_1.35-1_i386.deb
 69ed83c9f3ca732dc76d9e81f46a94f4 22374 libs required libcomerr2_1.35-1_i386.deb
 5686646c3ebb458809bd533509cf3e1d 27996 libs required libss2_1.35-1_i386.deb
 c037272bd8e35f4b16516effcdd42b0d 26408 libs required libuuid1_1.35-1_i386.deb
 9b439fbf789631019f59ee2953a59095 35222 libs required libblkid1_1.35-1_i386.deb
 197c58b49b74296edeb61f69b4d680a9 15690 libdevel extra libblkid-dev_1.35-1_i386.deb
 747e965e5c4f995db4320db6fe3a18e3 68094 libs required e2fslibs_1.35-1_i386.deb
 15c937f6030f7eec10bf1c43600053d1 115996 libdevel extra e2fslibs-dev_1.35-1_i386.deb
 bd7937b7eb2e7c6f6d4fb3efa247d83d 425156 base required e2fsprogs_1.35-1_i386.deb
 eabc02c1803a7e4b4ae25295a37e2576 38492 libdevel extra comerr-dev_2.1-1.35-1_i386.deb
 eec67043e6999bd8a468667a826c52a6 15818 libdevel extra ss-dev_2.0-1.35-1_i386.deb
 b66b7ce2166eb5395780d1c178ac3a8b 30674 libdevel extra uuid-dev_1.2-1.35-1_i386.deb
 e5da38a4ae517803b50cb17d400ab800 116946 debian-installer standard e2fsprogs-udeb_1.35-1_i386.udeb
 a1a6499fdbe06ecc6f685ff76f30374c 11688 debian-installer required libblkid1-udeb_1.35-1_i386.udeb
 3d990cc9c543b6e51613520cdd628a35 5182 debian-installer required libuuid1-udeb_1.35-1_i386.udeb

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)

iD8DBQFAQL1n7To545NnTEARAv4JAKD+jZw/jTd3EKPXZduCnAZid3sdigCfecaG
JBFFqIT4totvmLWamoaCwjQ=
=wnhY
-----END PGP SIGNATURE-----




Send a report that this bug log contains spam.


Debian bug tracking system administrator <owner@bugs.debian.org>. Last modified: Fri Apr 18 06:13:23 2014; Machine Name: beach.debian.org

Debian Bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.