Announcing Journaled File System (JFS) release 1.0.0 available
Hi,
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.
YA
*Kervin Pierre* (/ [email protected]/ <mailto:[email protected]> ) wrote :
Hello,
Question.
Are there plans to include JFS and XFS in the kernel?
Both those projects have been declared stable by their development teams, and I'm guessing they can now be included as experimental, just as reiser has been.
Just curious,
-Kervin
Steve Best wrote:
/> /
/> June 28, 2001:/
/> /
/> 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)/
/> /
/> -/
/> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in/ /> the body of a message to [email protected]/
/> More majordomo info at http://vger.kernel.org/majordomo-info.html / /> Please read the FAQ at http://www.tux.org/lkml/ /
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
------------------------------------------------------------------------
_________________________________________________________
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com
Quoted 2 lines
JFS doesn't require any modifications to existing code, its only an addition.
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.
Quoted 1 line
XFS on the contrary is far more intrusive.
Right - 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
Quoted 9 lines
Hi,
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.
YA
But that is not a patch intended for Linus, it is intended to enable all the XFS features. I have a couple of kernel patches which total 46298 bytes which get you a working XFS filesystem in the kernel, and I could do lots of things to make them smaller. When you hit header files in the correct manner for different platforms the size tends to mushroom. These lines are all in different fcntl.h files for example:
+#define O_INVISIBLE 01000000 /* invisible I/O, for DMAPI/XDSM */ +#define O_INVISIBLE 0x80000 /* invisible I/O, for DMAPI/XDSM */ +#define O_INVISIBLE 02000000 /* invisible I/O, for DMAPI/XDSM */ +#define O_INVISIBLE 01000000 /* invisible I/O, for DMAPI/XDSM */ +#define O_INVISIBLE 01000000 /* invisible I/O, for DMAPI/XDSM */ +#define O_INVISIBLE 0x200000 /* invisible I/O, for DMAPI/XDSM */ +#define O_INVISIBLE 01000000 /* invisible I/O, for DMAPI/XDSM */ +#define O_INVISIBLE 0x200000 /* invisible I/O, for DMAPI/XDSM */ +#define O_INVISIBLE 01000000 /* invisible I/O, for DMAPI/XDSM */ +#define O_INVISIBLE 02000000 /* invisible I/O, for DMAPI/XDSM */ +#define O_INVISIBLE 0x80000 /* invisible I/O, for DMAPI/XDSM */ +#define O_INVISIBLE 02000000 /* invisible I/O, for DMAPI/XDSM */
You make the patches look a lot bigger than they really are. There is a difference between a patch which is placing things in the correct places and one which is designed to be as short as possible.
Steve
Quoted 29 lines · Steve Lord
Quoted 8 lines
Hi,
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.
YA
But that is not a patch intended for Linus, it is intended to enable all the XFS features. I have a couple of kernel patches which total 46298 bytes which get you a working XFS filesystem in the kernel, and I could do lots of things to make them smaller. When you hit header files in the correct manner for different platforms the size tends to mushroom. These lines are all in different
fcntl.hfiles for example:(quoted diff) +12
-0+#define O_INVISIBLE 01000000 /* invisible I/O, for DMAPI/XDSM */ +#define O_INVISIBLE 0x80000 /* invisible I/O, for DMAPI/XDSM */ +#define O_INVISIBLE 02000000 /* invisible I/O, for DMAPI/XDSM */ +#define O_INVISIBLE 01000000 /* invisible I/O, for DMAPI/XDSM */ +#define O_INVISIBLE 01000000 /* invisible I/O, for DMAPI/XDSM */ +#define O_INVISIBLE 0x200000 /* invisible I/O, for DMAPI/XDSM */ +#define O_INVISIBLE 01000000 /* invisible I/O, for DMAPI/XDSM */ +#define O_INVISIBLE 0x200000 /* invisible I/O, for DMAPI/XDSM */ +#define O_INVISIBLE 01000000 /* invisible I/O, for DMAPI/XDSM */ +#define O_INVISIBLE 02000000 /* invisible I/O, for DMAPI/XDSM */ +#define O_INVISIBLE 0x80000 /* invisible I/O, for DMAPI/XDSM */ +#define O_INVISIBLE 02000000 /* invisible I/O, for DMAPI/XDSM */
Quoted 4 lines
You make the patches look a lot bigger than they really are. There is a difference between a patch which is placing things in the correct places and one which is designed to be as short as possible.
Agree.
But IMHO, you need to be more "visible" and to already propose those kernel modifications - even not the final ones - in lkml in order to let everyone see them and change the current think (even by Alan) that XFS is too intrusive for 2.4. There are other people involved in the files you need to change and the more your patches are visibles, the more they are "credibles".
I didn't want to critisize XFS (or JFS and ext3) but to give some points about their integration in 2.4.
YA
Quoted 5 lines
Steve
_________________________________________________________
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com
Quoted 8 lines · Yaacov Akiba Slama
Hi,
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
It is not less complete nor less robust, it's a different technology and a totally different approach.
Remember XFS was designed thinking to a kind of HW totally different from PC, and so was for jfs. But somehow JFS is a better choice if you do not have the last fastest CPU, and the last fastest scsi disk.
Quoted 3 lines
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 hope it will happen as soon.
ReiserFS is a good FS, probably is the best journaled FS you could find out here, but how many memories with
the old dear jfs! And I have some pentium classic for non critical use that would be so happy with it.
Quoted 3 lines
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).
agree.
Quoted 4 lines
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.
mmm.
I doubt it will be easy.
I should check better, but i think it requires eavy changes to VFS.
oh, by the way.
On a 8 processor origin 2000, with a not so eavy I/O, I usually see 1 processor
totally used just for journaling. (different HW, different Unix ....)
Luigi
Quoted 9 lines · Luigi Genoni
Quoted 2 lines · Yaacov Akiba Slama
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
It is not less complete nor less robust, it's a different technology and a totally different approach.
Remember XFS was designed thinking to a kind of HW totally different from PC, and so was for jfs. But somehow JFS is a better choice if you do not have the last fastest CPU, and the last fastest scsi disk.
This is simply not true. I run xfs on three systems - none of which have anything close to the latest cpu. Each system runs faster after installing xfs. Since linux-kernel is not the place for advocacy I suggest a comparison be for your particular setup to determine which is best for you.
James Rich
[email protected]
Quoted 12 lines · james rich
Quoted 9 lines · Luigi Genoni
Quoted 2 lines · Yaacov Akiba Slama
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
It is not less complete nor less robust, it's a different technology and a totally different approach.
Remember XFS was designed thinking to a kind of HW totally different from PC, and so was for jfs. But somehow JFS is a better choice if you do not have the last fastest CPU, and the last fastest scsi disk.
Quoted 5 lines
This is simply not true. I run xfs on three systems - none of which have anything close to the latest cpu. Each system runs faster after installing xfs. Since linux-kernel is not the place for advocacy I suggest a comparison be for your particular setup to determine which is best for you.
Please,
I was not making any advocacy. I was saying that there are two different approach, and incidentally refered my own experience. Then, telling about jfs to be light, I was not
saying XFS is slow! probably my english was not good enought to express my thought.
Luigi