Slashdot Mirror
IBM's JFS & PTh-NG Reaches 1.0
jd writes "IBM's Journaled Filing System becomes the second commercial filing system for Linux to reach the exalted 1.0 status! It also follows close on the heels of another of IBM offering, the PThreads Next Generation project, which also hit 1.0 today." Check out this LWN story on it as well. It's worth noting that this is a free as in open source version - GPLed. There will be another commericial version as well.
Ahhh, I've noticed this
But, it's not as bad as you think
I use 2.4.5-acsomethingorother
It has threaded coredumps - which is nice, until of course you get one (well "one" - it dumps every single core seperately for each cloned process)
So you have to manually go through them and bt them - but it does work, it's simply fiddly, and you can't easily check other threads without seperately reading in the cores.
In terms of threaded processes however, gdb is a lot better - indeed, the worst thing we've been bitten by is some of the bugs that it has with C++ and static members in superclasses.
gdb CVS seems competant with threads - I've had it weird out on me occasionally, but generally it's capable of doing the job.
gdb 5.0 isn't capable (at least, not the one debian ship), but the CVS version is a damn site better.
HTH
The way I see it, this IBM project is just reinventing LinuxThreads with a few differences, the biggest being M:N threading. If you look at their list of known issues listed in the release notes, it's about the same as for LinuxThreads: no process shared mutexes, no process identity for threads (except when only one underlying system task is used). These two are the biggest sources of complaints from some LinuxThreads users.
The rest of my comments have to do with M:N, specifically the false claim that M:N provides a performance enhancement for all multithreaded applications.
I don't believe that M:N threading is a good idea It creates issues and complications in the library implementation. The responsibility of scheduling and dispatching is divided between user space and the kernel instead of being done in one place. What M:N threading does is speed up voluntary context switches---context switches that take place within a threading function that is directly or indirectly invoked by the application, such as a synchronization function (pthread_cond_wait, pthread_mutex_lock, etc). Such a function can just call the user space scheduler, which can dispatch a thread without cooperation from the kernel. This is how M:N reduces overhead.
M:N does nothing for involuntary context switches, which have to somehow go through the kernel (for example, a signal is delivered to the process, which swaps context so that returning from the handler will cause a new thread to run). Actually, this kind of context switch can be worse than the ordinary Linux kernel context switch, depending on how it is done. The current task is interrupted to run kernel code (transition 1). Then a handler in user space is dispatched (transition 2). Then the handler returns to the kernel (transition 3) then the kernel passes control back to user space with a new context (transition 4). On the other hand, a native context switch is just two transitions: interrupt the current task, and dispatch the new one. In any case, the kernel is involved in the involuntary context switches of the so-called ``user space'' scheduler, which puts their expense in about the same ballpark as a kernel task switch (within the same address space).
So what about the faster voluntary context switches that M:N provides? Unfortunately, most of the *useful* voluntary context switch points are in the kernel: such as blocking calls that wait for I/O or real-time events. So M:N does nothing for I/O or response to real-time inputs. Dispatching a response to the completion of I/O or a real time input always requires a switch from the kernel to the user process.
M:N also does nothing for compute-intensive multithreading that is done *sanely*. Sure, M:N may speed up a program that performs, say, some operation on a large matrix using 50 threads on two processors, because when these threads synchronize, it can be done using those fast voluntary context switches. But M:N will do nothing for a program that uses two threads over two processors to do the same thing, which is the more sane design.
As a rule, the number of threads in an application should be not much more than the minimum that is required to utilize the various functional units of the hardware (processors and peripherals). Using too many threads just causes wasteful context switches that accomplish nothing, increases the memory access footprint of the application (since each thread has its own private data areas, such as the stack), and causes the scheduler to have to choose from among more threads.
It's not worth trying to speed up brain-damaged applications that make poor use of threads, yet this is exactly what M:N is for.
Process creation under Linux (>= 2) is cheaper than on many other systems, however. It's (usually) still a net win.
OTOH, for _kernel level_ threads, you need more than just a register context and stack -- the scheduler ends up needing a fair amount of bookkeeping data anyway.
Linus just decided that there's not much point in making threads a special case ("thread-like" behavior depends on which of several things are shared, specified by flags).
Things get a lot simpler that way, and is probably one reason why thread and process creation are so cheap on Linux.
Even the recently added CLONE_THREAD stuff is a pretty generalist approach -- it just controls whether or not threads (including those considered "processes") share a "thread group" (the id reported by getppid(2) in 2.4).
DNA just wants to be free...
[punch /tmp]$ diff -u xfs_announce jfs_announce
... It is a
--- xfs_announce Tue May 01 08:19:51 2001
+++ jfs_announce Thu Jun 28 14:30:02 2001
@@ -1,10 +1,12 @@
-SGI is pleased to announce the 1.0 release of XFS, high-performance
-journaled file system for Linux.
+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.sgi.com/projects/xfs/
+http://oss.software.ibm.com/jfs
-XFS, widely recognized as the industry-leading high-performance
-filesystem, provides rapid recovery from system crashes and the
-ability to support extremely large disk farms.
-mature technology that has been proven on thousands of IRIX
-systems as the default filesystem for all SGI customers.
+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.
;-)
XFS and JFS are both sold as part of a commercial (as opposed to "open" or "free") operating system. Reiserfs is not.
The Math Maestro Tutoring Services in Seattle
I'm not sure why anyone (other than Micro-Soft) would think this would be a sign of forking. Presumably, all will wind up in the kernel, and all will be either compiled in or available as modules for all the major distros. "mount -t auto yadda yadda yadda" should take care of this.
This actually makes Linux stronger, as it provides choice. Got an old system: use ext3. Want speed: use ReiserFS. Want (I don't know. Sorry): use JFS, XFS, fooFS.
This isn't the either/or situation of FAT, FAT-32, and NTFS (not sure if XP will add another FS standard). All versions of the GNU/Linux OS should have the ability to read all of the filesystems.
You do, however, have a point that there is some overlap. I am not a part of any of the devel teams (or any devel teams for that matter) so it would seem, at least from a lay perspective, that having (just for example) Hans, the ext3 group, etc working on and submitting patches for JFS would result in the strongest solution. But there is nothing to preclude this from happening (except, perhaps, for Hans' ego and financial plans. And I don't know how open IBM is. And...)
Anyway, this is fairly early in the development, and the choice of filesystems is hardly as major a concern as the Gnome/KDE schism WRT forking possibilities.
Jesus was all right but his disciples were thick and ordinary. -John Lennon
Speaking as an ex-AIX worshipper (I have now been converted to the One True OS and it's apt-get luvin' incarnation), IBM JFS has one MAJOR attraction for me: ease of filesystem modification.
I haven't tried JFS/Linux yet, but after years of expanding filesystems on production systems without outage ("chfs -a size=+blocks /fs/mount/point"), porting this to Linux is all it'll take me to switch. Performance? Pah! nice to have, but if you're reliant on FS performance you need to splurge a few beans on more memory. Ease of administration is the major win with JFS here folks....
--
I'd rather have a bottle in front of me than a frontal lobotomy
What about ReiserFS and XFS? Or is there some weird meaning to "commercial filing system" that I don't get?
A post with Score: 6 has appeared on slashdot before (anyone remember it?). This suggests that there was a race in slashcode; and since slashdot still uses a non-transactional data store, I bet the it's still there. I think everyone gets where I'm going with this.
So, here's the plan: First, someone moderates this back down to 4. Second, everyone with mod points synchronizes their clocks to UTC (apt-get install ntp). Third, everyone picks an appropriate (positive, smartass) moderation for this article and moves their pointer over the "Moderate" button. Fourth, at exactly midnight (00:00:00 UTC, June 29), everyone clicks "Moderate".
Everyone without mod points places bets on how high we can get this sucker.
The evaluation of an action as 'practical' . . . depends on what it is that one wishes to practice.
I don't care if you call your filesystem fooFS; please don't call it BarFS.
Got friends?
GPLGP
LGPLGPL
GPLGPLGPL
GPLGPLG
PLGPLIBM
GPLGPLG
PLGPLGPLG
PLGPLGP
LGPLG