linux-stable.git/include/linux/genhd.h, branch linux-2.6.17.y

[PATCH] BLOCK: delay all uevents until partition table is scanned

2006-04-14T18:41:24+00:00

[BLOCK] delay all uevents until partition table is scanned

Here we delay the annoucement of all block device events until the
disk's partition table is scanned and all partition devices are already
created and sysfs is populated.

We have a bunch of old bugs for removable storage handling where we
probe successfully for a filesystem on the raw disk, but at the
same time the kernel recognizes a partition table and creates partition
devices.
Currently there is no sane way to tell if partitions will show up or not
at the time the disk device is announced to userspace. With the delayed
events we can simply skip any probe for a filesystem on the raw disk when
we find already present partitions.

Signed-off-by: Kay Sievers 
Signed-off-by: Greg Kroah-Hartman

[PATCH] for_each_possible_cpu: fixes for generic part

2006-03-28T17:16:05+00:00

replaces for_each_cpu with for_each_possible_cpu().

Signed-off-by: KAMEZAWA Hiroyuki 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds

Merge branch 'for-linus' of git://brick.kernel.dk/data/git/linux-2.6-block

2006-03-27T16:46:49+00:00

* 'for-linus' of git://brick.kernel.dk/data/git/linux-2.6-block:
  [PATCH] Don't make debugfs depend on DEBUG_KERNEL
  [PATCH] Fix blktrace compile with sysfs not defined
  [PATCH] unused label in drivers/block/cciss.
  [BLOCK] increase size of disk stat counters
  [PATCH] blk_execute_rq_nowait-speedup
  [PATCH] ide-cd: quiet down GPCMD_READ_CDVD_CAPACITY failure
  [BLOCK] ll_rw_blk: kmalloc -> kzalloc conversion
  [PATCH] kzalloc() conversion in drivers/block
  [PATCH] update max_sectors documentation

[PATCH] dm-md-dependency-tree-in-sysfs-holders-slaves-subdirectory-tidy

2006-03-27T16:44:59+00:00

Remove all the CONFIG_SYSFS stuff.  That's supposed to all be implemented up
in header files.

Yes, the CONFIG_SYSFS=n data structures will be a little larger than
necessary, but that's a tradeoff we can decide to make.

Cc: Jun'ichi Nomura 
Cc: Alasdair G Kergon 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds

[PATCH] dm/md dependency tree in sysfs: holders/slaves subdirectory

2006-03-27T16:44:59+00:00

Creating "slaves" and "holders" directories in /sys/block/ and
creating "holders" directory under /sys/block//

Signed-off-by: Jun'ichi Nomura 
Cc: Alasdair G Kergon 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds

[BLOCK] increase size of disk stat counters

2006-03-27T07:29:02+00:00

The kernel's representation of the disk statistics uses the type unsigned
which is 32b on both 32b and 64b platforms.  Unfortunately, most system
tools that work with these numbers that are exported in /proc/diskstats
including iostat read these numbers into unsigned longs.  This works fine
on 32b platforms and when the number of IO transactions are small on 64b
platforms.  However, when the numbers wrap on 64b platforms & you read the
numbers into unsigned longs, and compare the numbers to previous readings,
then you get an unsigned representation of a negative number.  This looks
like a very large 64b number & gives you bizarre readouts in iostat:

ilc4: Device:    rrqm/s wrqm/s r/s    w/s  rsec/s  wsec/s    rkB/s wkB/s avgrq-sz avgqu-sz   await  svctm  %util
ilc4: sda        5.50   0.00   143.96 0.00 307496983987862656.00 0.00 153748491993931328.00     0.00 2136028725038430.00     7.94   55.12    5.59  80.42

Though fixing iostat in user space is possible, and a quick survey
indicates that several other similar tools also use unsigned longs when
processing /proc/diskstats.  Therefore, it seems like a better approach
would be to extend the length of the disk_stats structure on 64b
architectures to 64b.  The following patch does that.  It should not affect
the operation on 32b platforms.

Signed-off-by: Ben Woodard 
Cc: Rick Lindsley 
Signed-off-by: Andrew Morton 
Signed-off-by: Jens Axboe

[PATCH] more for_each_cpu() conversions

2006-03-23T15:38:17+00:00

When we stop allocating percpu memory for not-possible CPUs we must not touch
the percpu data for not-possible CPUs at all.  The correct way of doing this
is to test cpu_possible() or to use for_each_cpu().

This patch is a kernel-wide sweep of all instances of NR_CPUS.  I found very
few instances of this bug, if any.  But the patch converts lots of open-coded
test to use the preferred helper macros.

Cc: Mikael Starvik 
Cc: David Howells 
Acked-by: Kyle McMartin 
Cc: Anton Blanchard 
Cc: Benjamin Herrenschmidt 
Cc: Paul Mackerras 
Cc: Martin Schwidefsky 
Cc: Heiko Carstens 
Cc: Paul Mundt 
Cc: "David S. Miller" 
Cc: William Lee Irwin III 
Cc: Andi Kleen 
Cc: Christian Zankel 
Cc: Philippe Elie 
Cc: Nathan Scott 
Cc: Jens Axboe 
Cc: Eric Dumazet 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds

[BLOCK] Document the READ/WRITE splitup of the disk stats

2005-11-12T09:55:21+00:00

Use the symbolic name where appropriate and add a comment to the
disk_stats structure.

Signed-off-by: Jens Axboe

[BLOCK] Unify the seperate read/write io stat fields into arrays

2005-11-01T08:26:16+00:00

Instead of having ->read_sectors and ->write_sectors, combine the two
into ->sectors[2] and similar for the other fields. This saves a branch
several places in the io path, since we don't have to care for what the
actual io direction is. On my x86-64 box, that's 200 bytes less text in
just the core (not counting the various drivers).

Signed-off-by: Jens Axboe

Merge ../bleed-2.6

2005-10-28T17:13:16+00:00