First Journaling FS for Linux 281
wendyW writes "LinuxPR has the press release from Namesys, announcing the stable release of the journaling version of ReiserFS. According to the press release, journaling wound up making it even faster than it already was. "
Re:Compression and Encryption too? (Score:1)
Re:Another item gone from the MS FUD page (Score:1)
XFS, reiserfs, ext3fs (Score:3)
XFS
Originally made by SGI for their IRIX OS, XFS is one awesome filesystem. Read this white paper (http://www.sgi.com/Technology/xfs -whitepaper.html [sgi.com]). This white paper describes all of its cool features. The main features of XFS make it a super scalable, very reliable, ultra fast journalling filesystem utilizing many cool FS technologies like B-trees and other cool stuff.
Unfortunately, it seems that currently there are many problems with the Linux implementation of XFS. I don't know any details of this, but I guess it is safe to say that XFS will some day become available for Linux. This would be great.
ext3fs
I've only read about this in the linux mailing lists. ext3 appears to be a standard ext2fs implementation with journalling data, allowing backward compatibility with ext2, although one of the authors hinted that they may not make it backwards compatible in some later version. It is currently in super early alpha testing and definately not anywhere close to usable, stable and reliable.
In my opinion this project is very new, and holds much promise. From their README, they appear to be done basic journalling code, and what remains to be done is error handling contingencies, metadata only journalling, performance tuning and lots of other coding. As a result, it may take some time but this could hold much promise and give another viable option for a journalling FS for Linux. Choices are always good.
Ext3 Site - ftp://ftp.linux.org.uk/pub/linux/sct/f s/jfs/ [linux.org.uk]
Reiserfs - http://devlinux.com/namesys/ [devlinux.com]
I've been following reiserfs for a few months now. Its actually been available for quite some time now as a very stable, reliable and quick filesystem for Linux, but it was only recently when journalling was added to the code. Apparently this new addition is supposed to make it faster.
In "releasing" reiserfs, SuSE doesn't mean that it is the first journalling filesystem for Linux. It is the first journalling FS for Linux to be dubbed reliable and suitable for normal use. This is great as journalling has long been a stumbling block for enterprise adoption of Linux. Alan Cox hinted that he may include reiserfs in the standard kernels soon. Excellent =)
Warren Togami
warren@togami.com [mailto]
browsers (Score:1)
--
Man is most nearly himself when he achieves the seriousness of a child at play.
Re:ext3 seems fine (Score:1)
#define X(x,y) x##y
Re:Hmmm... What about the *BSDs? (Score:1)
The only annoyance is that in case of a crash in FreeBSD, I have to boot into Linux to fsck the ext2fs filesystem. There is no fsck for ext2fs in FreeBSD yet.
SuSE does it again! (Score:1)
This seems to have changed dramatically during this year: after embracing ALSA (i.e. hireing the top-ALSA developer and making ALSA part of their distribution) and publishing their next version also on DVD, SuSE now also seems to be the first distib to include a working journaling FS and is actively funding its development. Considering their recent expansion efforts (esp. in the US and Eastern Europe) and their actually positive balance (instead of RedHat, they do make some money now), I can't wait for their IPO!
How to migrate filesystems (Score:2)
Another item gone from the MS FUD page (Score:1)
http://www.microsoft.com/ntserver/nts/news/msnw
They'll have to edit it again, now it appears Linux has 2 or 3 to choose from. At the current rate of progress MS will have to edit it almost daily
Filesystem Being DBMS (Score:2)
One goal of ReiserFS is to make this practical even for small records by providing ways of efficiently storing hordes of tiny files.
But that's a separate issue; that requires that someone create something like a ReiserSQL, a database server that maps SQL queries onto file requests on a filesystem.
The journalling issue discussed in the top level posting implicitly regards journalling as being important for conventional RDBMSes like Oracle, Sybase, DB/2, PostgreSQL, where the model you are suggesting (and which probably is not too unlike what I outline above) does not apply.
Daaaaamn! I sure hope this works well. (Score:1)
I can't wait to try this one out
Re:Ok, has anyone had problems with the patch (Score:1)
--
Re:Linux advocacy (Score:1)
They're just OSes. If one offers a feature you need, use it. If not, stay with what you're using.
Re:Daaaaamn! I sure hope this works well. (Score:2)
sgi's xfs? (Score:2)
Re:Hmmm... What about the *BSDs? (Score:1)
>>redistribute the source for any changes they
>>made, there would be no problem.
Wrong. Since this FS is linked against the kernel, they would also have to make their kernel source code available under the GPL (unless they obtain the source under different licensing - see above).
Again, the BSD folks are happy to redistribute the source for even their entire kernel, but because of the GPL restrictions (or features, as RMS would say), they cannot use this source in their product.
Actually, no. All they need to do are put stubs in the kernel that will call an exteral filesystem module. Then rewrite the filesystem code as an external module. It'd be slower, but that's the price they pay for their anti-GPL decision.
The are controlling who can use the currently-available source code. In particular, BSD folks cannot use it,
As the other respondant said, BSD *can* use the code. The only thing stopping them is themselves.
The GPL ensures that the Linux kernel will always be open source if the BSD guys want to look at a new FS to see how it was done. The BSD license does not ensure that BSD and its derivatives will always be open source.
Re:Can someone explain this (Score:1)
Re:Can someone explain this (Score:1)
Only one question? (Score:2)
and re-format of existing partitions to use now
source... *ouch*
Any ideas on how many more times this may happen before the beta-testing is done??
(Hmm... got first post earlier and didn't even try.
Wow. (Score:2)
I wonder, though, how GPL purists are going to react, since their business model is to be GPL but sell GPL-exceptions to some companies.
I suspect that the project will quickly fork into Reiser-FS-commercial and Reiser-FS-pureGPL as soon as a contributor refuses to license a GPL-exception.
I wonder if anyone here has heard of this before? Beta-tested it? Maybe I'll try it tomorrow. (I want to keep my machine running tonight, so I can't very well replace the fs.
--Parity
FYI: NameSys FTP archive (Score:2)
http://devlinux.com/pub/namesys [devlinux.com]
If you grab the sources from the site, the README.FIRST file says to:
Re:How to migrate filesystems (Score:1)
Re:sgi's xfs? (Score:1)
- Michael T. Babcock <homepage [linuxsupportline.com]>
Re:*Can* be mounted before being checked (Score:1)
The above is incorrect. When mounting the filesystem, the journal is replayed. When the filesystem is unmounted cleanly, there is nothing to replay. If the filesystem was not unmounted cleanly, then there is *something* in there to replay. So you do *not* need to boot off of an alternate root to repair it. Just mount it and let it do the journal replay, and you are ready to go. It seems the FAQ must be out of date.
Endianness, the killer feature (Score:1)
I spoke with the SGI guys at Linux Kongress. Currently XFS works on Linux/ia32, but the disks cannot be moved to a big endian (IRIX/MIPS) box because the version of XFS for Linux is little endian. Since we (the m68k and PPC guys) have quite some experience with bi-endianness in ext2 (originally ext2 was big endian on m68k and PPC), we were able to convince them that XFS has to be big endian on all platforms, just like ext2 is little endian on all platforms.
Best wishes, SGI!
Re:Use the a patch to use files >2GB on x86 (Score:1)
"Fault Recovery
The Windows NT Filesystem (NTFS) is a journaling, or transactional file system. This means that any I/O that alters the file system data or meta-data (directory structure, etc.) is completed atomically so that either all of the changes are completed, or none of the changes is completed. This design means the transaction log can be used to restore the file system to a known good state after a system crash. In addition, NTFS keeps copies of vital file system information in multiple sectors for extra redundancy."
Re:Beware the Jabberwock! (Score:1)
If you built the journalling version, you should not even have gotten a reiserfsck. In fact, the README in the utils directory specifically says you should *NOT* fsck a jRFS filesystem. It sounds like you built plain reiserfs, and not the journalling version.
As far as fsck'ing an ext2 partition. I have to disagree. We have a machine at work with 4 17GB SCSI disks in it. When that machine resets, it takes between 10 and 20 minutes to fsck all of the disks, and mount the filesystems. Reiserfs with journalling would cut that down to a minute at most I would think...
JFS is not just a buzzword IMHO. Other OS's have had this for quite some time (XFS on SGI, VxFS on HP-UX etc..), and Linux has been quite lacking in this area. Just my
Re:journaling fs isn't news (Score:1)
Re:Question about journaling (Score:1)
Re:journaling fs isn't news (Score:1)
Re:journaling fs isn't news (Score:1)
Re:Hmmm... What about the *BSDs? (Score:1)
The are controlling who can use the currently-available source code. In particular, BSD folks cannot use it, and neither can commercial entities whose kernels are not GPL'd and who do not wish to buy a license.
Worse, since they are also making it available under alternative licensing schemes, they themselves are taking away other's rights to use and modify the code streams that are released in commercial systems. Now, I suppose it could be licensed to commercial entities in a way that requires all changes made to the code be assigned to the ReiserFS developers under their copyright, but I don't think they would be adamant about such a clause if the commercial entity didn't want it, and the ReiserFS folks stand to make a good bit of money from a deal.
Wrong. Since this FS is linked against the kernel, they would also have to make their kernel source code available under the GPL (unless they obtain the source under different licensing - see above).Again, the BSD folks are happy to redistribute the source for even their entire kernel, but because of the GPL restrictions (or features, as RMS would say), they cannot use this source in their product.
99 little bugs in the code, 99 bugs in the code,
fix one bug, compile it again...
Production? (Score:1)
I think you've missed the point. (Score:1)
I'm sorry to disagree, but you're very very wrong here. The fact that Reiserfs is fast (if the article is true) as a filesystem for manipulating ordinary files is not what's important (though it's a big plus in many configurations). Nor is how a database manipulates its data relevant. It's how quickly the filesystem is recovered after a failure that's the primary benefit. I've delt with many hundreds of customers over the last 4-5 years that have brought systems for the sole purpose of running databases on Journalling filesystems.
On multi system High Availability configurations of the type that run database application services designed to failover from one system to the next, a journaling filesystem is essential. Unless it's controlled by an administrator, when a service moves from one system to another it's because of some kind of system failure and in this situation the filesystem is not unmounted cleanly. With a journaling FS, recovery is quick, measured in seconds. For a non journaling filesystem recovery could take hours. I've even seen one (very stupidly configured) customer system (100+ GB's) where this took days. If it takes more than a few seconds to recover, then it's not High Availability.
It doesn't matter if the metadata is static or not. If the database sits on filesystem that isn't journalled it will have to be fsck'd regardless and will take almost as long to fsck as a filesystem that isn't as static.As you rightly pointed out, the only other option is not to have a filesystem at all and drop the database into a RAW partition. In this case all bets are off as the stability and recovery time of a database after a system failure is up to the implementation specific design of the database vendor.
Macka
Re:welcome to modern times, Linux. (Score:1)
-lx
ACL (Access Control Lists) (Score:1)
Re:welcome to modern times, Linux. (Score:1)
What I asked for was a comparison between the different journaling filesystems, without saying that any of them was a cure-all.
-lx
Circular buffers (Score:1)
Thats why the log is recycled in a circular buffer fashion.
Cheers
Re:BSD SU is NOT free, violators will be prosecute (Score:1)
Re:Beware the Jabberwock! (Score:1)
Re:Journaling, Linux going lowlatency ! (Score:1)
Re:Hmmm... What about the *BSDs? (Score:2)
There is an old, deprecated "Log-Structured FS" in the FreeBSD source tree. Nobody's interested -- log structured FS'es generally have atrocious read performance, because they cannot lay out files for faster read performance like FFS (and I assume ext2fs) can. McKusick has nothing to do with this, and is not very interested in this approach either.
The related journalling filesystems add an extra disk write for every single update operation, making them somewhat slower than the normal filesystem that the journal augments. The journalling technique is, however, conceptually quite simple. Since the extra data structure (the journal) is only used during FS recovery, at least it only wastes disk bandwith during normal operation.
OTOH, soft updates makes a different trade-off: it saves the disk bandwidth, but takes up CPU time and memory. Since CPU's and memory systems are always going to be much faster than magnetic disks (for the forseeable future, anyway), I think this is a better tradeoff.
And SU *does* leave the filesystem safe to mount after a crash. The *only* inconsistencies that can occur are:
1) unused data blocks not marked free.
2) inodes with too high of a link count.
These can only result in wasted space, nothing more serious. McKusick is working on a background fsck (using NetApp-style FS snapshots) for FFS, so that fsck can basically be run at anytime during system operation (i.e. the FS doesn't have to be unmounted or r/o mounted).
Oh, well, not that it matters -- this is slashdot, and I fully expect any reply to be "Linux rulez!"
The bias I see running through this thread is that "Linux has it, so it must be great" and "BSD doesn't, therefore it must be necessary," so "let's bash BSD on technical grounds -- we can almost never do that
In reality, SU and journalling are radically different approaches to solving the same problem. They both add *extra* complexity to async writes -- that is, they are not performance tweaks! They are techniquest that try to retain *part* of the performance of async, while adding crash-resistance.
Re:Journaling (Score:1)
Re:Good things come in threes? (Score:1)
:)
Re:FYI: NameSys FTP archive (Score:1)
Re:Endianness, the killer feature (Score:1)
Call me stupid, but what exactly is endian-ness? What are endians? I mean I see the endian check anytime (it seems) i compile a prog in linux and just kinda ignored it since everything usually works
thanks
Re:Hmmm... What about the *BSDs? (Score:1)
Some System V advocates had created a "benchmark" that proved that FFS (with 4k blocks and 1k fragments) was faster than their 1k-blocksize filesystem. They would create a file, and grow it by 1k blocks. This cause FFS to grow the file's last fragment (which often involves a copy) on every update. Of course, it was the optimal case for their filesystem. It was this crooked benchmark that lead to the tunefs -o (space|time) option. '-o time' will upgrade a fragment to a full 4k block, wasting a bit of space, but saving time -- it is quite useful for constantly-growing smallish files, e.g. logfiles. (and, of course, for running crooked benchmarks
Also, logging filesystems and journalling filesystems are *very* different. Loggin filesystems pretty much have to leave file blocks scattered throughout the disk, or waste disk bandwidth relocating them (to the head of the log, of course). Journalling filesystems, however, can choose whatever file layout they please, so they can optimise this layout for good read performance. The FreeBSD LFS is not even alpha -- it's past that stage, nobody is working on it, and I think it might even be in the CVS attic... yep, no code there anymore. I think the LFS approach is pretty much dead -- journalling and soft updates give the same sort of reliability and write performance as LFS promised.
Also, having just read two papers on the soft updates technique, I feel the need to improve on your description of it: the behavior you describe is present on FFS/async, as well.
What soft updates does is mantain a list of updates for each in-memory metadata block. Before the block is written to disk, this list of updates is scanned, and any unsafe updates (i.e. ones that depend on other uncommitted updates) are rolled back. After the write completes, they are then rolled forward, to bring the block to its current state. In other words, the latest safe version of the metadata block is written to disk.
Re:This whole "Linux" thing... (Score:1)
Re:These stats ARE FISHY (Score:2)
Having said that, I can think of a couple of reasons why, given the stated design goals of rfs, it would not perform well on those tests. Basically, the performance ( O(n) = "big O" ) of an algorithm can be measured as it varies on the size of data points.
Now, let's suppose that ext2 uses sequential scans to get directory entries (I'm fairly sure it does). The O() of a sequential scan is O(n)=n. That is, the time required to perform the scan for n elements increases linearly.
The time for a B-tree based filesystem would increase according to O(log2(n)). The curve on this one is
In other words, you may not have had enough items in a single directory to experience the benefits of RFS. I would be interested in results with say 10,000 items in a single directory, or better yet 10,000 directories in a single directory with 10,000 one byte files.
That (as I understand it) is really the kind of grueling stuff that reiserfs is designed for. Nor is this without application. On one of the boxes where I work, we have > 70,000 elm email folders, each stored under "customer_name/email". A simple "ls" takes an hour! Granted this is a boneheaded design (that I didn't do), but the point remains.
Re:Journaling, Linux going lowlatency ! (Score:1)
Re:Endianness, the killer feature (Score:1)
http://www.tuxedo.org/~esr/jargon/jargon.html#b
"big-endian adj.
1. Describes a computer architecture in which, within a given multi-byte numeric
representation, the most significant byte has the lowest address (the word is stored `big-end-first'). Most processors, including the
IBM 370 family, the PDP-10, the Motorola microprocessor families, and most of the various RISC designs are big-endian."
UCBerkeley dropped the advertising clause (Score:1)
Now people could still develop BSD under the Berkeley license, provide Reiser FS as an add-on, so that commercial types could rip off the BSD code, only without ReiserFS.
Re:Important, but likely not for DBMSes (Score:1)
Something like every row in the db is a file and you can use the unix io primitives to access them.
Re: (Score:1)
Oops! Just a little to the left... (Score:1)
The difference is a journalling filesystem can maintain decent read performance, because journalling does not confine the layout of data on the disk, while log-structuring does. Log-structured filesystems cannot get past the file fragmentation problem, without wasting tons of disk bandwidth.
Use bigger block size! (Score:1)
% ls -l bigfile
-rw-rw-r-- 1 root root 1843200000 Nov 7 17:04 bigfile
% time rm bigfile
0.00s usr, 0.28s sys, 4.94s real, 5% CPU
Re:Can someone explain this (Score:2)
Re:Another item gone from the MS FUD page (Score:1)
Hmmm... What about the *BSDs? (Score:3)
There is a clause in the license that states that if you contact them, they will let you use it under a different license. But I can't imagine them putting it under the BSD license. It sounds like they want to control who can use it, and they've decided that GNU projects and commercial entities who pay are their target market. If they ever release it under a BSD license, then commercial entities could just grab the BSD-released copy and work from there.
Will the BSD's simply miss out on this nice new filesystem?
99 little bugs in the code, 99 bugs in the code,
fix one bug, compile it again...
Re:How to migrate filesystems (Score:1)
Re:UCBerkeley dropped the advertising clause (Score:1)
Journaling File System (Score:4)
This would be a huge boon to those of us trying to truly break free of the commercial unices. I've had to put together quotes for enterprise quality database solutions before and there have always been a couple of hurdles to get past when considering an Intel/linux based system.
PostgreSQL works wonderfully with large data sets, but lacks the ability to do hot restores. I'm eagerly awaiting that one... Now that it does a much better job with concurrant locks, that's my only real hesitation at this point.
SMP has come a long way in a short time with linux, but is still a bit lacking. This makes it difficult to settle on Intel hardware - sometimes, you just need Raw Horsepower. I'd like to get there without having to buckle down and buy a Sun or HP box. I'm not worried about this one - things are coming along quite nicely...
Now, my last concern was journaling filesystems - and it looks like it's coming at long last! I was excited when the initial announcement was made, but now that the code is out (and Alan is even considering merging into the stable branch!), I'm all gushy inside! Let's hear it for our team!
I've watched this whole linux thing start out as a 'hobby OS' and develop through adolescence into what is becoming a damned serious contender with the big boys. Sure, they're baby steps at the moment, but at this pace, they add up right quick. God, I love this industry - never know what's gunna happen next. Who knows - maybe the government will sue Microsoft for anti-trust violations next. Oh... right...
Re:welcome to modern times, Linux. (Score:1)
I'm not the moderator responsible, but I do agree it's flamebait. Let's have a look, shall we?
Ooh, look! Flamebait! And now, apply Instant Flamebait-Away(tm):
It's saying the same thing (that BFS isn't appropriate for servers), but it's not so inflammatory any more.
"Flamebait" is about tone, not content.
Re: (Score:1)
Selling GPL Exceptions (Score:4)
[The idea of RT Linux is to put a small real time kernel underneath Linux. This kernel handles the real time tasks, and schedules Linux when a real time task doesn't require it. It also provides a communication mechanism between Linux processes and real time tasks.]
So the RT linux kernel could, in theory, be used without Linux (perhaps with another OS instead) to provide real time services. The author has carefully retained the copyright to his code, so he can sell it under a non-GPL license if someone wishes to incorporate it into a commercial project.
I'm not aware of any non-GPL licenses for RT Linux, but the model is there.
The main thing that helps make this model work is that the copyright holder controls the distribution. That means that in order to get your changes into the official releases, you have to resolve any copyright issues. It only breaks down if there is a significant dispute and someone is willing to go to the effort to start a separate distribution. Of course, if they get the file system into the main Linux distribution, that action will trigger a fork in development.
Needed Badly (Score:1)
Journeling is something Linux badly needs. This can only be good news.
I've been dieing to get a journeled filesystem for my three servers. I design my servers so they will never have to be touched again. But I've always worried that we might get a power outage and the automatic-fsck Linux does might fail. Journeling would be a big help.
I'm still waiting for Sun's XFS though...
Re:Oops! Just a little to the left... (Score:1)
"Intelligent" FS wishes (Score:1)
automatic version control of files that I work with.
back-up copies of important system files
compress seldomly used files
reorder files on the disk by access patterns to save seek times
even delete unwanted files if running low on space (core dumps and editor backups more that a week old...)
This could be configured with special tools, and/or with a hidden file in each directory to tell what are the important things here. Most of this should happen automatically in the background, out of sight.
Has this been done already? where? Anyone working on this sort of things? Anyone willing to steal these ideas? Technically feasible?
Re:This whole "Linux" thing... (Score:1)
Deletion times (Score:2)
heroine:/home/mov% l *.mov
-rw-r--r-- 1 root root 1958135327 Nov 6 17:49 xena1.mov
heroine:/home/mov% time rm xena1.mov
real 0m56.536s
user 0m0.000s
sys 0m0.920s
Even a 30 second deletion time would be great.
Ok... so I read the rest and it gets ONE ha... (Score:1)
Re:ACL (Access Control Lists) (Score:2)
Some benchmarks (Score:2)
Here's the linkage:
http://devlinux.org/namesys/bens.html [devlinux.org]
--
Re:Journaling, Linux going lowlatency ! (Score:1)
Re:It is amazing... (Score:1)
LinuxOne (Score:1)
Wasn't ext3 first? (Score:3)
Re:sgi's xfs? (Score:3)
I do not know if ReiserFS is a true 64 bit one, handling the files as big as the XFS does, but a quick and dirty look at the two FS's homepages should yield a lot more info on this.
XFS and ReiserFS is not going to replace ext2. Actually, ext3 is, which will, when released, also be a journaling FS (from what I heard).
Maybe someone could provide the right urls or more info on this than I can. I believe in time, they will all be included into the kernel, and you can choose your preference based on your needs. In the meantime, make a small partition, insmod the module and mount the drive and play with it I guess
Re:Beware the Jabberwock! (Score:2)
I don't agree that journaling FS's are a buzzword, or a fad, though. When they work, they work extremely well -- and invisibly. A good example of a solid, robust journalled filesystem operating system is IBM's AIX. AIX uses the journalled filesystem for everything, including the root partition, and based on my many years experience with these machines, system crashes simply don't break the filesystem.
However, journaling filesystems aren't the end-all. There's still a significant feature set missing from unix filesystems
It works like this
If you had a filesystem with work units, you would start by making a system call to open a work unit, then make your changes. When you are finished, you either make a commit system call, or a rollback call. If the commit ends with a success return code, then all of the changes are guaranteed to be made. If an error occurs in the commit, or you make a rollback call, all of the changes in that work unit are backed off. If the system crashes before you make a commit/rollback, all of your changes are backed off when the system reboots. This gives you fine-grain control over how data changes are made to files in your filesystem. Once you've tried it, you'll never want to go back.
This is a standard database programming technique, but moving the functionality into the operating system gives you a huge programming capability. It lets you write programs with database-grade data integrity as a matter of course, without requiring that you program against a database API.
I was skeptical as to the value of commit/rollback for ordinary filesystem programming, until IBM included them in it's then-new SFS filesystem on VM. Now I consider it one of those great things that will probably take years for the rest of the world to discover and implement.
- John
Re:Deletion times (Score:4)
Chris has the office next to mine and has been showing me these benchmarks just about every day - they improve just about every day.
-Jeff
Selling GPL exceptions (Score:2)
With Ghostscript the GPL was not restrictive enough. Proprietary software would simply call the gs executable in a separate process. That is why Alladin eventually switched to a more restrictive license. Namesys should have no such problems, you can't run a filesystem stand-alone.
Re:What IS a journaling file system? (Score:2)
Journalling file system keeps track of all the changes as they occur. So, even if it's not unmounted before shutdown, it can easily determine what was modified and deal with it as appropriate. So, for example, if you kick a power cord by accident, you no longer need to wait for 5 minutes while fsck scans the file system.
High-end data warehouses have file systems measured in terabytes. You *definitely* don't want to wait for fsck there...
Paranoid, aren't we? (Score:2)
Re:Wasn't ext3 first? (Score:2)
They mean ReiserFS is the first "stable" journaling FS for Linux. You are quite correct in saying that ext3 was "first", in that it had journaling before ReiserFS (at least, ext3 was publically available with journaling before ReiserFS was, that I'm aware of), but it's a fair way from being considered stable just yet.
Having just looked at ReiserFS's site, it seems either they haven't updated the site yet, or they consider beta == stable, since I could only find the beta release of the code which has journaling.
Re:Hmmm... What about the *BSDs? (Score:2)
And Suse is funding this.. cool (Score:3)
So Redhat pays for Alan (and Gnome?), Corel supports WINE, and Suse pays for file systems.
Open Source has always been good at producing excellent, relatively small and self-contained components. We haven't been so great (with a few very notable exceptions, the kernel being one) at producing large projects. If it's a lot of effort with no quick return, the coders get tired of it.
Now the commercial companies are funding the big stuff in an attempt to gain mindshare ("we must know what we're doing, we've got Alan"). This really complements the existing strengths of Open Source.
Two clarifications (Score:2)
2. Running linux binaries has nothing to do with this either, unless someone wants to make a user space version of RFS, and BSD can support it.
--
These stats ARE FISHY (Score:2)
Divide by 3:07 -- call it three
Both roundings favor resiserfs, yet the ratio is said to be 1.56. I don't think so.
Look at the rm -rf * stats -- ration is claimed to be 10.1, yet it's a lot closer to 7.
What hope is there for the numbers themselves?
--
Re:Hmmm... What about the *BSDs? (Score:2)
It can't. It specifically says in the readme that you can't use it with a kernel that's not GPL'd without the authors' permission. That would generally be the case with GPL'd code anway, though (you don't link gcc with the FreeBSD kernel, so it's ok; but you can't take video4linux, which is GPL'd and in the kernel, and include it in the FreeBSD kernel).
Re:What IS a journaling file system? (Score:3)
http://collective.cpoint.net/lfs/ what_lfs_is.html [cpoint.net]
Re:FYI: NameSys FTP archive (Score:2)
linux-2.2.11-reiserfs-3.5.5-journaling-beta.gz
This is the most recent code, even though it is not in beta any longer. The journaling portion of the ReiserFS site has links and more information:
http://www.devlinux.com/projects/reiserfs/jrnl [devlinux.com]
-chris
initrd anyone? Module-ness doesn't prevent XFS / (Score:2)
You could boot from an initrd RAM Disk, load the XFS module, and then remount your root partition from an XFS partition on your hard-drive. After all, this is how RedHat kernels allow you to have your root partition on a SCSI drive, yet still have all of the SCSI devices built as modules.
Indeed, just this sort of technique can also be used to handle a ReiserFS root partition that needs to be fsck'd, by having the boot routines in the RAM disk image do the fsck if necessary. Strikes me as a bit more fragile than what I'd care to deploy in a mission critical setting, but....
--Joe--
Re:Aladdin Ghostscript vs ReiserFS (Score:2)
That some printer manufacturers didn't want to obey the GPL was not a problem for Alladin, it was a feature. It meant these manufactures would want to buy an exception from Alladin. When they buy an exception, the GPL become irrelevant to the customer. The problem was developers of "postscript enabled proprietary applications" who _hadn't_ any problem with the GPL, because they didn't link with gs, they just used it as a standalone program. They would not pay Alladin, instead they would distribute the source to gs. The new Alladin license was designed to prevent this.
Namesys will not need to change their license, because their potential customers will not be able to use a similar loophole.
Re:These stats ARE FISHY (Score:2)
I copied
/dev/hdb1 7823372 442980 7380392 6%
/dev/hdb2 5283091 410343 4599242 8%
Newdrive is the reiserfs one. They contain the same data, but the reiserfs one is 30MB bigger.
Now for some stuff.
Running find . -exec wc {} \; on an installation of StarOffice on the Reiserfs one gives:
9.94user 21.02system 0:53.46elapsed 57%CPU (0avgtext+0avgdata 0maxresident)k
0inputs+0outputs (177778major+32241minor)pagefaults 0swaps
On ext2:
9.78user 17.41system 0:50.85elapsed 53%CPU (0avgtext+0avgdata 0maxresident)k
0inputs+0outputs (205151major+32581minor)pagefaults 0swaps
Reiserfs loses. Just one data point, however. And I may have it set up wrong. For reference, the reiserfs has lower cylinder numbers.
Aladdin Ghostscript vs ReiserFS (Score:3)
Actually, I hear that he's not thrilled with it. Indeed, one of the biggest problems that I can see is that there is very little incentive for people to improve the existing GPL version of Ghostscript when they know that Aladdin has (a) already improved Ghostscript in the current commercial version, and (b) will be releasing their changes 'soon' (after one year). This interview with Ghostscript's author Peter Deutsch [linuxcare.com] sheds more light on the situation, including Stallman's thoughts.
One result is that the GPL community is almost guaranteed to always be one year behind the latest in Ghostscript technology, unless someone gets up enough nerve to fork Ghostscript development and try to get ahead of Aladdin.
Part of the problem here is that the Aladdin folks try to license their code to printer manufacturers, etc. The printer folks aren't too keen on having to ship Ghostscript on demand to anyone who buys a printer. Also, if the printer folks make any platform specific changes (which undoubtedly they will, such as specific driver technology for running the print engine), they'd have to distribute those changes, and most aren't willing to do so.
Also, more importantly, Peter Deutsch doesn't seem too keen on having people ship Postscript-enabled printers by using his work for free (as in gratis).
The upshot: Aladdin offers their latest and greatest Ghostscript with a commercial license.
With ReiserFS, I'm sure a similar but not identical set of considerations exist. People building embedded or mission critical systems on an otherwise proprietary base might license ReiserFS for their application without introducing any questions as to the effects of GPL. At the same time, a GPL version is available for everyone.
The difference here is a bit subtle but important. Namesys appears to be releasing the latest and greatest ReiserFS under GPL, rather than imposing an artificial delay. (Whether or not this changes in the future is unclear, but for now it is an important distinction.) In this case, the commercial license seems to be a means for companies to buy an "unencumbered" version of ReiserFS for their own purposes. (By "unencumbered", I mean free of the implications of GPL.) I see this potentially as a way to keep both camps happy. Maybe. (Except, of course, RMS.)
--Joe--
Important, but likely not for DBMSes (Score:5)
The main effect of journalling, the thing that is really important about it, is that it guarantees that metadata updates are kept consistent. That is, journalling is primarily supportive of making sure that filenames, directory structures, permissions, and such are kept consistent even when moderately catastrophic things happen.
This is a really good thing when supporting file serving activities, as that indeed tends to involve lots of manipulations of files as users shift them around.
I've been on the ReiserFS mailing list since '97; have been running a personal news spool on a small ReiserFS partition for probably 6 months. I can't tell for sure if the journalling now available is metadata-only, or if it also journals normal data updates. It looks rather more like metadata-only, which is useful for file-server work, but not so much for RDBMSes.
Databases behave in quite different ways from file servers in terms of the way they do file access.
If you look at most RDBMSes, they create a few files, and do lots of manipulations on top of them. Informix SE is a counterexample, basically using Informix C-ISAM underneath, but is unusual in that regard. If you look at the database partitions, you get one of two things:
Note that for these, the metadata is very static which means that journalling of metadata is of relatively little importance.
Don't just believe me; I am not the ultimate authority on this. Transaction Processing : Concepts and Techniques [amazon.com] is a rather definitive reference; it discusses methods of managing transactions in the context of database management systems, and goes into considerable detail discussing transaction logging, which bears striking (and not merely coincidental) resemblance to journalling.
The critical point here is that it is the database manager that wants to manage the logging/journalling; Oracle and Sybase and IBM and Informix will be loathe to pass on responsibility for this to Hans Reiser, wonderful guy though he is.
Conclusions
What will be of fundamental importance will be when Stephen Tweedy's Raw Device Support [lwn.net] gets integrated into the "production" kernels. That is what Oracle is looking for (consider: Oracle has pumped some funds into RHAT, and RHAT is paying Stephen Tweedie... Could there be some connection?)
Even if this isn't such a boon to those doing serious RDBMS work, it can still be a boon to lots of other folks...
Not Even Close (Score:3)
"Who was first" isn't all that important; it should be noted that there is considerable communication between the development groups, and there are conscious efforts ongoing to make sure they build facilities that will be useful across the board:
It'll be available when it's complete (Score:2)
You haven't seen a release; based on the discussions at ALS involving the developers, it would be surprising to see a "beta" before the end of 1999.
A "beta" is not production code, and doesn't include integration into the "regular" kernel. I would be entirely unsurprised to hear that this hasn't yet occurred by the middle of next year.
Not likely any time soon...Yes, It Works. (Score:2)
As for the possibility of forking, that was intended as a way of raising funding to support the free version. Now that SuSE is funding ReiserFS, it is rather less likely that Hans Reiser will be feeling the need to bang on Sun's door looking for money.
The hype may have been about XFS, but note that no code for XFS has been publicly released. And note that ReiserFS has been under active development since at least July 1997, which means that while silly people that watch fads may have been off hyping XFS, ReiserFS is hardly new and hardly surprising.
Note, all of these developments in filesystems move us towards having a choice of filesystems, and the ability to tune systems for one kind of behaviour or another. None are likely to supplant ext2 for our root partitions any time soon, in much the same way that commercial UNIXes' "advanced" filesystems have not largely supplanted "traditional UFS" for root partitions.
Plus ca change, plus ca reste meme.
No, no effect. (Score:2)
That bottleneck is not resolved by changes to filesystem functionality.
This means that ReiserFS does not fix the problem; this means that XFS does not fix the problem.
At present, your choices for resolving the 2GB file size limit are two: