Kernel Traffic #271 For 11 Aug 2004

If anyone knows of a company looking for a talented writer with scripting and other abilities, check out my résumé (resume.html) . I've done API documentation with accompanying developer guides, and I'm published monthly as a Contributing Editor in Linux Journal (http://www.linuxjournal.com/) and a Columnist in Linux Magazine (http://www.linux-mag.com/) . I do my own creative writing on the side, and have many strange writing- and communication-related interests such as Labanotation. I also play a mean game of chess. I'm located in San Francisco, and would prefer to work in that area; but for the right offer I'd consider moving to a new location. I am both a US citizen and a French citizen, making me eligible to live and work anywhere within the European Union, as well as in the United States.

There were 415 different contributors. 205 posted more than once. 144 posted last week too.

ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/pat ches/2.6/2.6.7/2.6.7-mm7/ (ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.7/2.6.7-mm7/)

Added three new bk trees to the -mm lineup:

  bk-dma-declare-coherent-memory.patch
    New DMA mapping function.
  bk-jfs.patch
    JFS filesystem development tree
  bk-mpc52xx.patch
    New ppc32 board support

Added a big UML update. Needs work.
Lots of warning fixes, mainly.

Pavel Machek noticed that in ext3, the fsck program ran after approximately 30 clean and nonclean (i.e. flipping the power switch) shutdowns. But it seemed to him that file corruption was more likely to happen after a nonclean shutdown than a clean one; and that therefore it made more sense to run fsck more often in the case of nonclean shutdown. He posted a patch to enable this, but Theodore Ts'o replied, "At least in theory an unclean shutdown is not going to cause any problems, unless the hardware is screwy, in which case even a single hard shutdown is going to cause problems. I'm not sure that it really makes sense to arbitrarily state that a hard shutdown is 5 times more likely to cause problems. We could make it be configurable, I suppose, but I'm not sure it's worth it to add all that extra complexity." Pavel replied that if the shutdown was due to a power loss, Theodore could very well be right; but if, on the other hand, the shutdown was the result of software malfunction, Pavel argued, then the journal data on disk would not be guaranteed to help.

Andreas Dilger also had some objections to Pavel's initial patch. He felt Pavel's code didn't have the proper logic to determine when to perform an fsck. Andreas suggested, "only increment the mount count after a clean unmount 20% of the time (randomly). Since most people bitch about the full fsck anyways this is probably the better choice than increasing the frequency of checks and forcing the users to change the check interval to get the old behaviour." Pavel's initial patch had a bug that simply caused ext3 systems to perform a fsck 5 times as often, regardless of clean or unclean reboots. Pavel agreed with Andreas' suggestion and posted a new patch. Andreas felt the new logic would have a good shot at getting into the main kernel; and the thread ended.

Following a good tradition, dmraid 1.0.0-rc2 is available at http://people.redhat.com:/~heinzm/sw/dmraid/ in source and i386 rpm, before I leave for a 2 weeks vacation trip followed by LWE ;)

Won't read my email before July, 30th.

dmraid (Device-Mapper Raid tool) discovers, [de]activates and displays properties of software RAID sets (ie. ATARAID) and contained DOS partitions using the device-mapper runtime of the 2.6 kernel.

The following ATARAID types are supported on Linux 2.6:

Highpoint HPT37X
Highpoint HPT45X
Intel Software RAID
Promise FastTrack
Silicon Image Medley

This ATARAID type can be discovered only in this version: LSI Logic MegaRAID

Please provide insight to support those metadata formats completely.

Thanks.

See files README and CHANGELOG, which come with the source tarball for prerequisites to run this software, further instructions on installing and using dmraid!

CHANGELOG is contained below for your convenience as well.

Call for testers:

I need testers with the above ATARAID types, to check that the mapping created by this tool is correct (see options "-t -ay") and access to the ATARAID data is proper.

You can activate your ATARAID sets without danger of overwriting your metadata, because dmraid accesses it read-only unless you use option -E with -r in order to erase ATARAID metadata (see 'man dmraid')!

This is a release candidate version so you want to have backups of your valuable data and you want to test accessing your data read-only first in order to make sure that the mapping is correct before you go for read-write access.

The author is reachable at <Mauelshagen@RedHat.com (mailto:Mauelshagen@RedHat.com) >. Later, I told you ;)

For test results, mapping information, discussions, questions, patches, enhancement requests and the like, please subscribe and mail to <ataraid@redhat.com (mailto:ataraid@redhat.com) >.

CHANGELOG

Changelog from dmraid 1.0.0-rc1 to 1.0.0-rc2 2004.07.15

Intel Software RAID discovery and activation support
allow more than one format handler name with --format
display "raid10" sets properly rather than just "mirror"
enhanced activate.c to handle partial activation of sets (eg, degraded RAID0)
enhanced command line option checks
implemented a library context for variables such as debug etc.
fixed memory leak in discover_partitions
fixed recursion in _find_set()
continued writing subsets in case we fail on one because of RAID1
format handler template update
fixed dietlibc build
fixed shared library configure
use default_list_set() instead of &raid_sets where possible
name change of list_head members to the more commonly used 'list'
renamed msdos partition format handler to dos
lots of inline comments corrected/updated
streamlined tools/*.[ch]
moved get.*level() and get_status to metadata.[ch] and changed level name to type

Martin Waitz wanted to snarf the CVS kernel repository (as gatewayed by BitKeeper, but found that "the hostname cvs.kernel.org exists but nobody listens on port 2401. Is it deactivated on purpose or just broken?" After a couple of posts, H. Peter Anvin replied:

Just rsync the CVS repository from:

rsync://rsync.kernel.org/pub/scm/linux/kernel/bkcvs/

The direct access to the repository was removed due to disuse and security problems. The rsync is a lot nicer anyway.

Linus Torvalds announced Linux 2.6.8-rc2, saying, "MTD updates, i2c updates and some USB updates, and a lot of small stuff (sparse cleanups and fixes from Al etc)." Jurgen Kramer reported, "My EHCI controller is still failing (Asus P4C800-E i875p) as in the 2.6.7-mm series." But Will Beers said, "This was previously discussed as the subject "proper bios handoff in ehci-hcd (http://groups.google.com/groups?hl=en&lr=lang_en&ie=UTF-8&safe=off&edition=us&selm=2pSYC-5B4-11%40gated-at.bofh.it) ". Basically it's a broken bios, and David Brownell has a fix for it that hasn't made it into the kernel yet. Changing the "return 1" at line 308 in drivers/usb/host/ehci-hcd.c" to a "return 0" works for me until the patch makes it into the tree."

Elsewhere, Ralf Hildebrandt confirmed that compilation using GCC 3.4 worked for him; and that vesafb worked on his HP Pavilion laptop for the first time ever.

Elsewhere, Thomas Zehetbauer reported that "ACPI support is still broken for the Intel D865PERL board. Booting hangs when compiled for SMP/HT and succeeds only with acpi=off or acpi=ht boot parameter." Pozsar Balazs added, "It is still broken for Intel D865GRH too, as I reported first using 2.6.7-rc3." And Kevin P. Fleming said, "There is a new patch in the RedHat Bugzilla that fixes this problem (it restricts one of the ACPI setup events to only run on CPU 0). Hopefully it will get merged into the kernel tree soon, although all the developers are at OLS this week :-("

I would like to announce that Generic SCSI Target Middle Level for Linux (SCST) version 0.9.2 released.

SCST is a new subsystem of the Linux kernel that provides a standard framework for SCSI target drivers development. SCST is designed to provide unified, consistent interface between SCSI target drivers and Linux kernel and simplify target drivers development as much as possible. A system with a SCSI target device is able to share its local or virtual devices with other systems on the network with SCSI protocol support, e.g. SCSI bus, Fibre Channel, TCP/IP with iSCSI. A system with a SCSI target device is able to share its local or virtual devices with other systems on a network with SCSI protocol support, e.g. SCSI bus, Fibre Channel, TCP/IP with iSCSI. This is commonly used for data storage virtualization. Full list of SCST's features, the source code and detailed documentation could be found on its Internet page http://scst.sourceforge.net.

The major changes from version 0.9.1 are

2.6 kernels support
FILEIO/BLKDEV device handler that works over files on file system and makes from them virtual remotely available SCSI disks. In addition, it allows to work directly over a block device, e.g. local IDE or SCSI disk or ever disk partition, where there is no file systems overhead. Using block devices comparing to sending SCSI commands directly to SCSI mid-level via scsi_do_req() has advantage that data are get or put via system cache, so it can fully benefit from caching and read ahead, performed by Linux's VM subsystem.

The Qlogic target driver is coming soon.

The next coming features are complete BLKDEV device handler, which will not copy data from the page cache, but instead use the pages directly, and device access control.

Release 1.1.7 of jfsutils was made available today.

This release include the following changes to the utilities:

--replay_journal_only should not clear FM_DIRTY
Ensure changes to disk occur in the proper order
Message corrections
Directory Index Table corrections for big-endian systems.

The last of these is the most critical. Anyone using version 1.1.6 on a big-endian system (i.e. ppc64) should update to version 1.1.7.

For more details about JFS, please see our website: http://oss.software.ibm.com/jfs

1.	8 Jul 2004 - 17 Jul 2004	(46 posts)	Linux 2.6.7-mm7 Released
2.	14 Jul 2004 - 16 Jul 2004	(7 posts)	Increasing ext3 Disk Checks In The Event Of Improper Shutdown
3.	15 Jul 2004	(3 posts)	dmraid 1.0.0-rc2 Released
4.	17 Jul 2004 - 22 Jul 2004	(4 posts)	Accessing The Kernel Sources Via CVS
5.	17 Jul 2004 - 20 Jul 2004	(18 posts)	Linux 2.6.8-rc2 Released
6.	21 Jul 2004	(1 post)	New SCSI Target (SCST) Subsystem Framework For SCSI Driver Development
7.	22 Jul 2004	(1 post)	jfsutils Version 1.1.7 Released

Kernel Traffic #271 For 11 Aug 2004

By Zack Brown

Call for testers:

CHANGELOG