I'd like to draw your attention to the new search feature, visible in the upper left corner of all KT pages. Just type some text and press enter. Many thanks go to Seth David Schoen for implementing this, and to our friend Michelle, who likes to be mentioned.
Paul Larson announced:
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.
There was no reply.
Steve Best announced:
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)
Daniel Phillips replied, thanks for being so
clued in about how to run your project. Example: the way you provide the
source - direct links to cvs, tgz and patches, no annoying cgi. You guys
get it.
Several other folks were happy about the release as well,
and Kervin Pierre asked if there were plans to inlclude JFS (and XFS) in
the official tree. Yaacov Akiba Slama replied with his assessment:
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.
Alan Cox agreed with Yaacov's assessment of XFS, saying, XFS I think is 2.5 material - for cleanup time, for the core changes
it wants to provide. Maybe as a 2.4 backport later.
He also added
in terms of JFS' nonintrusiveness, It depends how
clean the interface is. It is possible to avoid changing core code by
writing your own clone of it - that isnt good and doesnt make people happy
sometimes.
Marcelo Tosatti asked for a more verbose explanation about why Linus
Torvalds backed out some code in 2.4.6-pre7, that had involved LRU (Least
Recently Used) expiration in the page_launder() function. Linus replied,
See the thread about 2.4.5-ac13+ (and my pre3+)
basically becoming unusable for longish times (temporarily locking up) on
linux-kernel. It was due to these changes.
Rik van Riel also replied
to Marcelo, saying that Linus had actually backed out the wrong code, and
the fix had come from a different direction. Linus replied:
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.
Rik replied that he'd look around for the emails, but was on a slow connection. Linus replied with a correction against his own post:
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.
End of thread.
Jeff V. Merkey said:
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.
Alan Cox replied, I'm not a file sustem hacker,
nor since I work for one vendor the appropriate owner for larg chunks of
code in some people's eyes. I suspect the FSF is a much much better asignee
for the code itself.
Aaron Lehmann posted a piece of the NetBSD/SparcFAQ:
Why is NetBSD so much faster than SparcLinux on sun4c (top)
The memory management hardware on sun4c machines (SPARCStation 1, 1+, 2, IPC, IPX, SLC, ELC and clones) is not handled particularly well by Linux. Until Linux reworks their MMU code NetBSD will be very much faster on this hardware.
Aaron asked if this was true, and what the technical details were
surrounding the issue. David S. Miller replied that yes it was true, and
recommended using BSD on sun4c machines for performance-critical systems. He
added, I know how to fix it but frankly I have
no desire to work on that platform any more.
Aaron pressed for more information, specifically what the fix might look like; and David presented his take on the situation:
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.
There was no reply.
Eric S. Raymond, in his continuing preparation of CML2, said According to my cross-reference generator, the
following symbols have missing help in 2.4.6-pre9
and posted a list
of thirty-three symbols, asking Would responsible
maintainers please supply help entries for the above?
David Woodhouse replied that Eric's cross-reference generator was broken,
but Eric claimed that he had already put the
symbols wed iscussed previously on my ignore list. What's your beef this
time?
David took a closer look, and said:
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.
He posted a help item, which Eric incorporated. To David's apology, Eric
added, Accepted. I wish more people had the
grace you do, to apologize when you know you've been mistaken or unfair;
it would make this list a better place.
Several other people offered to send Eric help entries, and the thread ended.