Kernel Traffic #125 For 9 Jul 2001

The Linux Test Project is an open source project originated by SGI and recently joined by IBM and OSDL to provide a collection of tools for testing the Linux kernel, and Linux in general. The project consists of well over 100 individual testcases and a test driver to automate execution of the tests. This release includes many new tests and updates.

• Over 20 reliability network tests for remote procedure calls, network file systems, multicast, and various network commands.
• An assortment of robustness tests that cover pthreads, memory, filesystems, and disk I/O
• Several tests for commands commonly used in an application development environment.

You can download the Linux Test Project on SourceForge at http://sourceforge.net/projects/ltp. For more information about the Linux Test Project, visit our web site at http://ltp.sf.net.

IBM is pleased to announce the v 1.0.0 release of the open source Journaled File System (JFS), a high-performance, and scalable file system for Linux.

http://oss.software.ibm.com/jfs

JFS is widely recognized as an industry-leading high-performance file system, providing rapid recovery from a system power outage or crash and the ability to support extremely large disk configurations. The open source JFS is based on proven journaled file system technology that is available in a variety of operating systems such as AIX and OS/2.

JFS was open sourced under the GNU General Public License with release v 0.0.1 on February 2. 2000 and has matured with help and support of the open source community and its "Enterprise ready" release today is due to joint work between the JFS team and the community. Following the development style of "Release Early, Release Often" the JFS open source project has seen 37 interim releases as part of the process.

The open source JFS for Linux v 1.0.0 is released for the Linux 2.4.x kernel and offers the following advanced features:

• Fast recovery after a system crash or power outage
• Journaling for file system integrity
• Journaling of meta-data only
• Extent-based allocation
• Excellent overall performance
• 64 bit file system
• Built to scale. In memory and on-disk data structures are designed to scale beyond practical limit
• Designed to operate on SMP hardware and also a great file system for your workstation
• Completely free of prerequisite kernel changes (easy integration path into the kernel source tree)
• Detailed Howto for creating a system with JFS as the /boot and /root file system using lilo
• Complete set of file system utilities
• On-disk compatibility with OS/2 JFS file systems

The JFS Team (Barry Arndt, Steve Best, Dave Kleikamp)

From what I understand from Linus's mail to lkml, there is a difference between JFS and XFS:

JFS doesn't require any modifications to existing code, its only an addition.

XFS on the contrary is far more intrusive.

So it seems that even if JFS is less complete than XFS (no ACL, quotas for instance), and even if it is less robust (I don't know if it is, I only used so far XFS and ext3 -with success), its inclusion in current kernel is a lot easier and I don't see any (technical) reason for not including it.

I don't think ext3 will have difficulties to be included in the kernel because a) the guys working on it are lk veterans and b) Redhat (VA also) is already including it in its kernels (rawhide AND 7.1 update).

So I only hope that the smart guys at SGI find a way to prepare the patches the way Linus loves because now the file "patch-2.4.5-xfs-1.0.1-core" (which contains the modifs to the kernel and not the new files) is about 174090 bytes which is a lot.

You wish.

Except it wasn't so.

Follow the list, and read the emails that were cc'd to you.

pre2 was fine, pre3 was not.

ac12 was fine, ac13 was not. pre3 with the pre2 page_launder was fine.

There is no question about it. The patch that caused problems was the one that was reversed. Please stop confusing the issue.

I said -ac13 was bad, but ac13 was actually ok. It was ac14 that was the problem spot.

Also note how Alan happened to merge the MM patches in the reverse order from the preX series: in the -ac series, Rik's page_launder() patch is in -ac14, while my VM changes are merged in -ac15. In my series, it was the other way around: mine went in in -pre2, while Rik went into -pre3. In both cases, it's the page_launder() thing that triggers it.

And in the -ac tree, there wasn't any interaction with other patches at all, and ac14 has the "pure" page_launder() patch that was reversed in -pre7.

And to make doubly sure, Tim <tcm@nac.net> also tested out various pre-kernels and unofficial combinations. Thanks.

I would like for you to take over NWFS if you are willing. I have dissolved TRG as a Utah Corporation and I am now focused on a variety of projects for various clients related to Linux development. Novell has recently threatened to try to take my house and assets if I post any more NWFS releases or MANOS.

I am doing very well with my consulting projects, but to be honest, my family has sufferred horribly in the past four years fighting with Novell every other week, and there's a very strong chance I will be moving shop to either New Mexico or Arizona, since they own the local courts here in Utah (all the judges are mormons in Utah Valley and pro-Novell).

There are several areas that need restructuring and work, and I am available to answer questions, and assist with technical consulting, but I can no longer post releases of NWFS on Linux. My children need a house over their heads, and I believe what Novell says about taking it and putting us out on the street. They are wounded in the market, and very dangerous at present, so I am trying very hard to stay out of their way. If you choose to decline, it's up for grabs with whomever else wants to take it over, but you have first dibs.

If you elect take it over, I will have my attorneys prepare an agreement transferring legal ownership to you. I will retain M2FS and the clustered versions, since I have a clients abroad who want this technology, and it does not utilitze any NetWare specific technologies. I would also retain IP rights to NWFS to use future incarnations in products should I set up in another state.

I do not want to see NWFS fall by the wayside and not get supported, so I would really like it if you would be willing to take it over and get it 2.4 clean.

Currently under Linux when a constext is recycled because a new context is needed but all are in use, we basically toss all of the MMU segments that context owned.

This is bogus because if the contexts are the limitedresource ot the MMU segments themselves, we take a lot of false MMU isses on each context switch for no reason.

The solution is to link the MMU segment software state structures into the mm_struct. When an 'mm' reacquires a hw context, if any MMU segments remain on the mm's list, just pluck them back into the MMU.

It looked like you were again reporting config symbols which the user can't be asked about - because they're only there as dependencies or as ifdefs in the code, rather than as selectable options.

Upon further investigation, it seems I was mistaken. I apologise for my tone.

In fact, it seems that a lot of MIPS code has been merged into -pre9, and those options _are_ now selectable, rather than just being there as dependencies for some of my code.