Merits Of The Different Journaling Filesystems? 192
a2800276 asks: "The story that XFS has gone beta raised some questions in my mind. There are now four journaling filesystems available under various OSS licenses and being actively developed for Linux, there being (in estimated order of maturity): SuSE/Namesys's reiserfs, SGI's XFS, IBM's JFS and Tweedie/Redhat's ext3fs. Avoiding the obvious question of why can't the effort going into four different projects be channeled into one, I think a discussion of the particular merits of the different fs's would be interesting."
Re:Journalling is dead. Long live phase trees! (Score:1)
Microsoft would already be doing that.
Re:ext3 more real than JFS (Score:1)
Is this a good thing.
I mean one should always assume the worst case scenario and deal with it in the code. If you can't deal with it, you should not allow the user to use the feature at all. That is, you should not allow mounting ext3 as ext2 if you can't guarantee that it will be unmounted cleanly.
People say... (Score:1)
Actually... (Score:1)
Soft updates, by no means a JFS substitute (Score:1)
This may be a corrupt sector containing metadata (maybe even for the "/" directory or "/kernel", if you were writing a new kernel at the time of the crash), or it may be other corrupt data which became corrupted in a cascade failure that resulted in the crash after one or more corrupted blocks were written to disk.
Soft updates simply can't recover from this.
If, on the other hand, it were a kernel panic that didn't result in corrupt data being written to disk, then there's no danger of a corrupt sector from a DC failure, and there is no danger of other corrupt data needing fsck'ing, so you would be in the situation where the only thing that would be out of date is the cylinder group bitmaps; you could clean this in the background by "locking" access on a cylinder group by cylinder group basis for a short period of time, to clear bits in the bitmap that said an unallocated sector was allocated. This might be seen as brief stalls by an especially observant user or program (say someone is doing profiling of code at the time), but could be accomplished in the background.
The problem is that you can not know the reason for the crash, until after the recovery.
If there were available CMOS, you could write a "power failure" value into it at boot time, and then write a "safe panic" or an "unsafe panic" code into it at crash time (a power failure would leave the "power failure" code there).
The only valid background case would be for a "safe panic", if you could really guarantee such a thing.
The worst possible failure resulting in a reboot is a hardware failure of the disk; I would really be loathe to try cleaning in the background after a track failure or even a sector failure (sector failures are identical to sector format corruption after a DC failure during a write, FWIW).
Look, soft updates are a good thing, but they aren't a panacea for all problems. Let's laud them for what they do right, but not misrepresent them as doing something they can't.
Re:ReiserFS (Score:1)
I downloaded the kernel patch for 2.2.17 (v3.5.26), patched compiled, and built the utilities. I have a 8gb hard disk that I use for
The next day I built a new kernel without ipmasq support (I no longer needed it) and also removed ppp. Upon reboot (a proper reboot, shutdown -r now), I noticed my ftpd had freaked out, and that only / was mounted. Uh oh. I tried to mount
I fired up fdisk. There was no partition found on that disk. Gone. I have no idea what happened, my kernel obviously still had reiserfs support (in
I realize that ReiserFS is still BETA but DAMN ! So I fdisk'd, and mke2fs and now it works again, I can reboot without losing my partitions.
I'll come back when Linus and Alan allow it into the standard kernel tree, until then, I'll be fscking with ext2.
Re:More flawed logic from our friend be-fan (Score:1)
The average linux desktop requires X11 _by definition_. You can't strip it from it. In addition to that, if you need to have a nice blended environment where everything (including apps) fits into everything else, your choices basically reduce to GNOME or KDE. Sure, you can run twm only, and run a "light" system, but you need all the other stuff. Toolbars, Pagers, Drag and drop, ...
From what I've seen of the BeOS, it's WAY more efficient at doing this. And the reason is "architecture". BeOS is a complete re-engineering of a lot of desktop concepts, whereas linux follows the work started with X11 to the extreme. Personally, I don't hold that much of a grudge against X11, I think it's pretty cool for what it does and when it was written, but it IS bloated. Luckily, they're working right now on reducing X11's size for embedded systems, so we may one day (hopefully soon) see a slim and trim X11. But X11's biggest problem to me will always be backwards compatibility. It carries so much stuff with it that's useless nowadays, and because of it no needed stuff gets added. Like usefull universal drag and drop, anti-aliased text (another two things BeOS and Windows have, and linux doesn't), and so on.
X fits the needs of today pretty well, regarding it's age. But everyone can see X was designed a long time ago.
Re:BeOS has the best Filesystem (64-bit) (Score:1)
Actually, Linux has much potential to become a mainstream OS. I bet if you had a line graph for each of the main OSes out there (MacOS, Windows, Linux, BeOS, etc) you would find that Linux is the OS that is gaining much more support than all the mentioned OSes. And the cool thing about Linux (or the part you hate) is that it is the public's OS, which gives people incentive to make it work. You see, Linux will be a success because it's everyone's baby! You're missing the point about Linux, and free software in general.
Perhaps you used RedHat 4.0 with twm a few years ago and wrote Linux off, but I can assure you it has advanced by leaps and bounds. It has advanced enough for me to put my users on it, and replace servers running Linux/x86.
In the time it took you to write that anti-Linux post, 8 new updates on Freshmeat were annouced, Miguel had another crazy Helix idea, KDE had another bug worked out, and another IBM released the source for one of their commercial products in the name of free software.
Re:ReiserFS is just fine by me (Score:1)
Both systems have an uptime of 180 days now (reboot was done because of systems moving).
I like ReiserFS.
Re:Journalling is dead. Long live phase trees! (Score:1)
ext3 is a journalling filesystem based on ext2, with (almost) the same format on disk and which is backwards-compatible.
tux2 is a phase-tree filesystem based on ext2, which has a different method of keeping the disk as sane as possible, and which isn't trivially backwards compatible.
They share more code between them than either do with the other filesystems, because they're both based on ext2. They're still different, though.
Re:Diversity is good (Score:1)
To be fair, there's a development path here. minix was a base filesystem, from which xiafs and ext appeared. ext2 was developed to address the shortcomings of ext, and was developed after the other two and taking advantage of what they'd discovered. So it was never a straight choice between four filesystems - they didn't start off on an equal footing.
With what we're talking of here - reiserfs, ext3, xfs and jfs - it would seem that only reiserfs is taking advantage of past experience and showing innovation. xfs and jfs are ports, and ext3 is intended as a simple upgrade path using time-tested code. That said, some of the innovation in reiserfs would seem to be directed towards odd and specific things - indexing of files, directories of objects and other strangeness - which most people don't want out of their Unix filesystem, and is as likely to find a niche as become a winner in the fight to be the single general-purpose filesystem.
Re:ReiserFS is just fine by me (Score:1)
Re:Why bother? (Score:2)
BeOS has the best Filesystem (64-bit) (Score:2)
Re:BeOS has the best Filesystem (64-bit) (Score:2)
FAM and iMON! (now open-source) (Score:2)
This is not, properly, a function of the file system.
Instead, you want a file-monitoring daemon, independant of the many fs's you may be accessing. This will include monitoring the changes across NFS, etc., and removable-media.
SGI Irix does this beautifully with its File Alteration Monitor (FAM) and Inode Monitor (IMON).
If you've ever used the 4Dwm filemanager, you'll know what I mean.
Fortunately, SGI has added these projects to its OSS roster, and documented, portable sources are available at: http://oss.sgi.com/projects/fam/ [sgi.com]
Jeremiah Cornelius
Re:ext3 more real than JFS (Score:2)
Isn't security built around this very thing?
Since the context of the conversation revolved around things root does, I replied in the context of someone who is root, so no.
Furthermore, as hardware moves more and more to firmware, there are bugs that can turn a machine into a boat anchor. I would very much like the OS to refuse to perform these operations.
Not me. I want it to require confirmation that I REALLY REALLY mean to turn it into a boat anchor, but if I confirm, it should DO IT. (Possably, I know something it doesn't! Like the hardware is modified or I want the disk dead for some reason).
Consider 'rm -rf /' for example, it WILL do it.
In the context of mounting a cleanly unmounted ext3 filesystem as ext2, that thing that I know and it doesn't is that I did unmount it cleanly, and from the documentation, I know that this is safe.
Re:ext3 more real than JFS (Score:2)
If you can't deal with it, you should not allow the user to use the feature at all.
That's not the Unix way. An OS should NEVER absolutely refuse to do what it's told to do (if it's possable). In this case, it IS possable. This is an especially good thing in a developmental file system. People who can't or won't follow that simple instruction shouldn't be messing with a pre-beta filesystem at all.
Re:Try *BSD Soft Updates (Score:2)
Your experiances and mine are quite different. The only files I've lost in a power fail situation were ones that were new and would have been suspect anyway.
Any filesystem will loose recent data if the power fails simply because there will be uncommitted buffers.
Of course, killing off kflushd and various other 'performance' tweeks can and will greatly increase the odds of loosing data.
If you want journaling, I have tried ReiserFS in production, and found it to be quite nice in versions for 2.2.x. It recovers much more quickly than an fsck.
Re:ReiserFS (Score:2)
Just remember, reiserfs still won't save you from total hardware failure due to power spikes.
smash
nope (Score:2)
However, I believe that this limit only exists on 32-bit architectures -- perhaps there was a bug which prevented 64-bit architectures from using big files too, and that's what was fixed in 2.2.14 (or
--
Re:Some do different things (Score:2)
The key word here is background. A defragmentation process running with a low priority that flushes its changes to disk regularly will not affect applications running at normal priority. Of course, if you're burning a CD or something, you will have the option of turning it off temporarily.
As an aside, the Indexing Service on Windows 2000 isn't bad. The original version was written by one of these people [relisoft.com].
--
"Where, where is the town? Now, it's nothing but flowers!"
Re:Some do different things (Score:2)
ext3 journals both data and metadata. Part of the current effort is being directed into allowing it to journal metadata only. Metadata-only journalling is useful in situations where good write performance is required, since journaled filesystems by definition write everything twice, once to the journal and then finally to the location on disk where the data belongs.
--
"Where, where is the town? Now, it's nothing but flowers!"
Re:Why people think you are a troll (Score:2)
NeXTStep used the Unix file system and thus has no more attributes than any Unix system. They used ".app" directories, which is a good example of storing such information in a way that is easily copied to other systems, and in a way that avoids complicating the file system. Each "attribute" is a standard file and thus can be read/written using the standard file I/O mechanisms. MacOS X does the exact same thing.
I would argue that "directories as files" should be supported, but this can be done entirely at the application library level. This would mean that reading a "directory" and then writing the same bytes to another system would produce an identical directory with identical contents on that system. I would argue that this is an area where Linux should abandon Unix/Posix and really try to make something better. But it is still not an "attribute" in that there is nothing special about the internal data and it is not inserted into a database.
I also think that the Unix owner/group/date stuff is a mistake and should be imbedded in the file data somehow.
The basic problem is we need a simple block of data that 100% describes the file. To most users, the date, creator, comments, document type, etc, are all parts of the file and thus anything that does not replicate it is not user friendly. And I don't for a minute believe that application designers are only going to put "unnecessary" data into the attributes.
Therefore I think *all* attributes (including the Unix date, permissions, group, etc) are a mistake. ALL data should be copyable by reading the file and writing the same bytes to a destination. Anything else, especially a system with low-level knowledge like BeOS, is going to make computers hard to use.
Re:ReiserFS gets the job done (Score:2)
Re:BeOS has the best Filesystem (64-bit) (Score:2)
Kurt Skauen (who designed AtheOS) read loads about BFS (especially the Author's own book on filesystem design) and in the end decided to do his own modified (and incompatible) version of it due to stupid short commings and design flaws.
I don't remember all the details but it all came out during a filesystem discussion on the AtheOS developer mailing list, so check their mail archives for more info. Here is a part by Kurt from the rather long thread that I managed to dig out:
"I did weight for and against this when I started on AFS and came to the conclusion that making AFS 100% compatible with BFS whould be to restrictive to make it worth while. The reason is a few shortcomings in BFS, and the fact that it whould lock the design 100%. First, BFS use linear list's for duplicate keys in B+trees that slows it down dramaticaly when indexing a lot of attributes with the same value, and makes indexing of attributes like file-type to slow to be practical. Seccond, at least when I designed AFS, BFS had problems handling deleted but still opened files when the machine crashed or lost power. The space used by these files was lost (This has AFAIK been fixed by now). Another thing I noticed was an alignment bug that wasted a bit of the very limited "small data" attribute space in the inode. The current journal system in AFS is quite different. from the one in BFS. The first version was much more similar but was very hard to make work in conjunction with dynamic cache size (something BeOS still don't have)."
ReiserFS gets the job done (Score:2)
Re:ReiserFS is just fine by me (Score:2)
Re:ReiserFS (Score:2)
Journaling file systems protect you from a number of problem: system crashes and power failures. They typically protect only the metadata regions of the disk (which is the administrative information used by the filesystem to run the filesystem).
To protect against hard drive failures you want to use one of the RAID setups.
The ideal combination is RAID+Logging+Backups.
Depending on your needs, budget and speed requirements you will choose your proper combination.
Myself, I use ReiserFS in my laptop which has proved to be very helpful on my 21 gig hard drive every time the kernel decides to crash after coming back from a suspend.
Miguel.
Re:ext3 more real than JFS (Score:2)
Isn't security built around this very thing? Furthermore, devices are designed to refuse to perform an operation that would put them in an invalid state. Furthermore, as hardware moves more and more to firmware, there are bugs that can turn a machine into a boat anchor. I would very much like the OS to refuse to perform these operations.
Hey it's kind of a theological question, should the OS that can do everything be able to create a virtual rock it can't lift?
Re:Try *BSD Soft Updates (Score:2)
Doesn't it scan for backup superblocks? It should have created at least a dozen or so of them. At the very least, there should have been some utility runnable off a rescue disk that could copy a backup superblock.
ReiserFS for BSD? (Score:2)
Re:ReiserFS is just fine by me (Score:2)
Heh, journalling filesystems are to handle the case of the system crashing. It doesn't sound like it's really done anything for you. :) But I suppose it's nice knowing that it's there.
mixed case (Score:2)
Case sensitivity in general is very important for Unix systems. I'm quite certain that it is required by Posix and other standards. I've seen a good number of cases where case was all that separated two files (e.g., Makefile vs. makefile) in the same directory. Now you can easily argue that this is a bad idea, but it certainly is part of our heritage, and I, for one, like it.
Incorrect description of XFS (Re:A brief summary) (Score:2)
XFS is optimised for dealing with streaming media, and so deals well with high IO and large files.
This is not entirely true. XFS will stream media if you want using GRIO (guaranteed rate IO) features if you set your file system up that way, though I am not sure the Linux version will have that.
I would refer users to the website [sgi.com] for a more comprehensive view of XFS. Basically XFS has been running for about 6 years on IRIX machines. It is a 64 bit file system, end to end. It is journaled. It is designed for speed, both at the OS level and at the hardware level (you can hit and sustain in excess of 97% of theoretical max drive performance in various cases with SCSI systems, and large block IO). It is designed so you can have millions of files in directories, with files in the petabyte size if needed.
Basically XFS is really one of the best file systems out there.
Saying it does streaming media is like saying Linux can be used via a vt100 emulator to edit files. It can do so much more, and it does it very well.
Combine XFS with a well designed volume manager, and you can have your file system saturate your IO bus. This is nice if you need lots of IO capability. XFS based filesystems (atop XLV) sustained 7 GB/s (thats gigabytes, not gigabits, per second) several years ago in a test, reading and writing to a single file. The limiting factor was the number of spindles one could attach to the machine. We used 864 if I remember the number correctly.
XFS scales provided the LVM scales.
Where is the limit? (Score:2)
The on-disk filesystem structures of ext2 can handle files much bigger then that.
The kernel code can handle relitive seeks anywhere within the file. I'm not sure about glibc.
You run into problems with absolote seeks in programs which cannot handle a 64-bit type for the seek. This includes glibc in some cases.
Huh? (Score:2)
Source?
Think hard about Linux. Who decides if you run GNOME or KDE? Not *YOU* but the programmers who write the programs you need to run.
This is sorely flawed reasoning at best, and absolutely bogus flamebait more likely.
First of all, if we except your rather flawed reasoning, then anyone who runs programs they didn't write are slaves. That includes you and your favorite OS.
But again, your reasoning is flawed. I can run KDE programs and GNOME programs and old Xt programs and even terminal programs, all at the same time. I need to have all the libraries a program requires installed, yes, but go ahead and show me a program that will run without a library it needs.
Better still, since most of this stuff is Open Source, we can take the program and re-write it to use the desktop environment of our choice. We can even change the desktop environment if we need to.
With BeOS, on the other hand, you're locked in, and cannot change it. Sounds like you're the real slave to me.
More flawed logic from our friend be-fan (Score:2)
Lines of code isn't a terribly accurate measurement of code bloat. Perhaps those 1.5 million "extra" lines in Linux go to support things BeOS does not. Drivers. Platforms. Features. Stability. Security. Whatever. Maybe they're documentation. Maybe they're copyright notices. But then, we really don't know, do we? We can't know, because BeOS holds us hostage with its source code.
The nice thing about Linux is that nobody is forcing you to run all that "crap", as you so eloquently put it. If you want a stripped-down, bare-bones system with nothing but X11 and a single app, you can do that. Don't need the GUI? You can toss that, too. If you have the horsepower and the desire, you can also run GNOME with Enlightenment and every silly graphics effect you can think of turned on, plus sixteen different versions of Mozilla at once. Your choice.
That is one of the things that makes Linux so popular: Choice. We like having the ability to make decisions about we use. We like being able to choose the software that best fits our needs. We do not like companies that tell us they know better then we do, and no, we can't make changes and we can't see the source.
Talk about missing the obvious (Score:2)
Windows95 had a minor version of this failing, in that, at the login screen, you could do a ctrl-alt-esc, select "run" and run "explorer", and get in without providing a credential to the OS.
Um, you could also just hit that "Cancel" button on the logon dialog and skip right past it...
Why people think you are a troll (Score:2)
So, you know very little about Linux, yet you have no problem pointing out all the things it does wrong.
Word of advice: Don't complain about things you do not understand. You don't see me complaining about implementation details of BeOS. Why? Cause I've never used the thing.
Can you please explain WHY attributes break portability?
Because they're not portable. They don't work on other systems. Anything that depends on them will not be portable to other systems. Thus, attributes aren't portable.
Is that clear enough, or do I need to draw you a picture?
You complain constantly about all of the "Linux zealots" who ignore problems in their favorite OS, yet you seem to be the biggest perpetrator of that particular vice.
Gee, like how it is already embedded in the MP3 itself? Next you'll be saying attributes can also store the title of an HTML document. What progress!
Innovation should not be held captive to those who cannot innovate.
This is true, but does it apply? Are BeOS attributes really trying to improve things, or are they trying to pull that favorite industry tactic of locking us into a single vendor? (I actually suspect the former, but I have to consider the possibility.)
The case can be made that application-level attributes do not belong in the system, but in application-level libraries. By keeping such information in the files themselves, they are easily transfered to other systems, and do not require system-level support. Meanwhile, you can still provide a standard API to get at the information with an application-library. Thus, you get the best of both worlds.
And I couldn't care less what *YOU* think is an outmoded model. The minute you can get an economist or somebody with knowledge of the industry to tell me propriatory is dead, then I'll listen. (Emphasis mine.)
No you wouldn't. Slashdot has had countless stories about such things, but you continue your tired crusade every chance you get. Meanwhile, you will happily ignore yet another legitimate complaint about your favorite OS: That anyone using it is locked into a single-vendor solution.
More trolling from be-fan (Score:2)
Oh really? To wit:
Obligatory BeOS plug
Not only are you a troll, you're not even a good troll.
Re:A brief summary (Score:2)
Re:Some do different things (Score:2)
Re:ext3 more real than JFS (Score:2)
Soft updates get even better with snapshots. (Score:2)
Once snapshots are ready, waiting for fsck on an FFS filesystem will become unnecessary. If a filesystem is dirty, on bootup the system will create a snapshot, and run fsck on that snapshot in the background.
Re:Why people think you are a troll (Score:2)
>>>>>>>>>>>
Right. Do you know what a media-node in BeOS is? And you feel that you have the right to critisze it? YES YOU DO! If you've used it, and it doesn't work well, then you have every right to critisize it! I speak from a users point of view (and having used Linux for many years, I think I'm entitled to an opinion). If a user needs to know what a super-block is, then the developer is doing something wrong.
Because they're not portable. They don't work on other systems. Anything that depends on them will not be portable to other
systems. Thus, attributes aren't portable.
>>>>>>>>>>>
Huh? You do realize that you have to define the word "portable" without using the word itself!
You complain constantly about all of the "Linux zealots" who ignore problems in their favorite OS, yet you seem to be the biggest
perpetrator of that particular vice.
>>>>>>>>>>>>>
Really? Would you care to show me when? As I remember, I posted reason why BeOS is not as advanced as QNX the other day, and I posted 9 or 10 problems with BeOS on BeNews. Of course I don't pay attention to useless posts like "BeOS is dying!" or "BeOS has no software!" but everytime I have had an intelligent criticism (like that guy who could only play 8 or 9 MP3s at the same time on BeOS. Turned out to be that I was using SoundPlay, and he MediaPlayer) I responed. Even in my post I pointed out (from the bonnie benchmark) that BeOS had problems with the VM. What more do you want?
...ID3 information is injected into attributes...
Gee, like how it is already embedded in the MP3 itself? Next you'll be saying attributes can also store the title of an HTML
document. What progress!
>>>>>>
Yea, but you can't search based on stuff stored inside the MP3. (If stuff isn't in a central database) And you can have your file-viewer autmotically display that info.
This is true, but does it apply? Are BeOS attributes really trying to improve things, or are they trying to pull that favorite industry
tactic of locking us into a single vendor? (I actually suspect the former, but I have to consider the possibility.)
>>>>>>
Really? Let's see. MacOS X, NeXTSTep, and BeOS all use something similar to attributes. Hell, UNIX uses it in the form of attribute bits (owner, group, date, etc.) Take for example, an installer I'm writing. Instead of having an ugly central database, all uninstall info is stored inside a folder's attributes. No more rebuilding the RPM database. That's just plain cool!
The case can be made that application-level attributes do not belong in the system, but in application-level libraries. By keeping such
information in the files themselves, they are easily transfered to other systems, and do not require system-level support. Meanwhile,
you can still provide a standard API to get at the information with an application-library. Thus, you get the best of both worlds.
>>>>>>>
No, because then there would be 3 dozen different APIs to do the thing. And if it is so easy, then why hasn't Linux done it yet? Plus, by putting it as part of the base system, it makes it much more likely that developers will use it. This is a big help because it allows nifty, usefull features to be implemented in all apps and allows a level of *UNITY* you just don't get in Linux. (Similar to BeOS's universal app scripting, sure you can do it in Linux, but by making it part of the OS, many more developers use the feature.)
No you wouldn't. Slashdot has had countless stories about such things, but you continue your tired crusade every chance you get.
Meanwhile, you will happily ignore yet another legitimate complaint about your favorite OS: That anyone using it is locked into a
single-vendor solution.
>>>>>>>
All Slashdot posts are OSS people saying how OSS is great. And to date, I have not heard from anyone important that propriotary software is dead. Even most OSS people say that they can live harmoniously.
Re:A brief summary (Score:2)
Re:Actually... (Score:2)
Re:Why people think you are a troll (Score:2)
Seriously though, if you are designing a program that will be used on both BeOS and UNIX, you can just NOT USE ATTRIBUTES. They are an immensly useful mechanism on the BeOS, and if you ask any BeOS user, they'll tell you how much you love it. If you haven't used BeOS, how can you comment that it is really not worth putting in attributes? Also, your "solution" to this causes more problems that it solves. At least with attributes, the file remains compatible with existing software. They won't be able to use the extra features, but a gif is still a gif. If you embed gamma information into the file itself, you have essentially either
A) Forked the file format, and/or
B) Tied to file to being read with only one app-level library.
Neither solution is a very "portable" one. I think it is a much better idea to handle those special cases where attributes need to be ported (maybe by making two files out of one attributed file) than to leave out the power of attributes all together. Lastly, attributes (and stroing user, date, creator, whatver) data inside files makes a lot of sense. A file is DATA. Attributes are data ABOUT the data. Two files with different metadate are still contain the exact same data. By using an attribute type mechanism, you maintain some sembelence of structure.
Either way, the point is moot. What matters is that attributes work, and they work well. I'll give you a concrete example of the unique power of attributes:
I'm writing an installer program for BeOS. Normally, I'd have to set up a database file and write code to access, search, and change that file. I don't really feel like coding all that, and I don't like the idea of centralized file info. Instead, I use attributes. I store all installation info inside the attributes of an application folder, and I use the built in query system to automatically detect any installation on the system. Saves me a lot of monotonous coding, and gives the system some cool features (built in seaching without any code on my part, automatic finding of packages anywhere in the system, automatic updating of the database when the folder is moved, the ability to automatically detect dependencies even if they aren't in an installed package, etc.) Sure you could do this stuff without attributes, but it makes my life so much more simple!
Re:So bloody off-topic... (Score:2)
As for consantly bitching about Linux, I try to be the devils advocate. Don't get me wrong, I have nothing against Linux. I have used it a lot. The problem is that people are so blinded by their frevor (or their elitism) that they really can't see when Linux has a fault. The mindcraft thing is the perfect example. While Slashdotters spent the whole timing bitching about how mindcraft was evil, Linus and other sane people actually took it seriously, and improved the kernel as a result. Or take the whole NVIDIA debacle. Not once did people mention (in their frevor to say Linux was almost as fast as Windows) that the Linux drivers were had tweeks similar to the Windows Detonator 3 drivers. So the test was essentially Detonator3-Linux vs. Detonator2 Windows. After the Mindcraft thing you would have thought Slashdot would rip it to pieces. But they didn't. Instead, people started preaching about how Linux was going to own the desktop market in a year (I'm not exaggerating) That's the kind of stuff I have problem with. I have no desire to be one of those people who constantly extolls the virtues of something. I will bring up BeOS once in a while, but usually just to illustrate a weakness of Linux (or OSs in general.) I have similarly brought up NT to point out weaknesses in Linux as well, so that's nothing unusual. There are enough
Re:BeOS problems (Score:2)
Re:Obligatory BeOS plug. (Score:2)
Re:Obligatory BeOS plug. (Score:2)
That said, your arguement has some merit. A bunch of important software WAS canceled. However, you're not totally right that BeOS is dying. Software is coming to the OS at quite a good clip. We've already got a good video editor, and other media programs are being made. BeUnited is helping a lot by starting projects to address gaps in the software line. Tracker and deskbar has been OSSed (under something similar to the BSD license) so the GUI wil continue to evolve. The system is modular, so the system itself can be improved by users. BeOS is far from dead.
Your point about the focus shit is totally off base. Be never said that BeOS is dead. They focus shift-ed. Sure, it sounds like a cop-out, but consider this. BeIA and BeOS are more or less the same thing. Be's plan is to be able to pull out a BeIA release out of the BeOS source-tree anytime it wants. Meaning, that any cool stuff integrated into BeIA gets into BeOS too. And this is not bullshitting on the part of Be. OpenGL, Java, networking, and a good browser are all critical for BeIA. And they're important for BeOS too. So guess what, Be is bringing them to BeOS! And before you say, "oh, that's just vaporware" remember, a lot of these things are in late beta. www.betips.net is already running on the new BeOS networking architecture, a lot of people aready have the OpenGL beta, Java-personal has already been ported to BeIA, and Opera is already working on a web-browser for it. (The Opera browser hasn't been released yet, but already works and can pass standards complience tests.) And with Compaq making a BeIA-powered IA, you can bet that these technologies are going to get to the public.
Re:Obligatory BeOS plug. (Score:2)
4) Can you please explain WHY attributes break portability? How exactly does it lock you into the OS? You forget four things:
1) Dealing with attributes is required for anyone writing a BeOS fs driver. Thus, any attribute data can be extracted by the fs driver if they are reading a bfs disk from another system.
2) The system takes care of attributes when sending things outside the OS. If send a picture to a non-BeOS user, the attributes are stripped out. If you copy stuff to a non-bfs disk, then attributes are taken out. If you post something, the appropriate extensions can be added. Its not a big stupid system that automatically makes file prorpiatory. If you're using a GIF file laden with attributes, it will still be a gif file when you send it to a Linux user. They just won't get the benifets of the attributes.
3) Attributes kick ass! No stupid MP3 database programs, ID3 information is injected into attributes (which are stripped out when you send them to Napster!) and the FS serves as your database engine. Email can be indexed by user, sender, date, time, subject, whatever. You can set up custom searches to get all email from your boss written within the last 5 days. Best of all, there is no central database to take care of, since all this info is in attributes. Think of it as UNIX-style file data (creator, data, group-info, etc) taken to the next level.
4) Innovation should not be held captive to those who cannot innovate. Nobody if forcing you to take advantage of attributes. If your cross platform program needs to share the same file-types between OSs then DON'T STORE ANYTHING IN THE ATTRIBUTE DATA! Keep a central database or whatever you want. However, if you couldn't give a flying fuck if other OS can take full advantage of your files (as long as they are a standard type, other OSs will always be able to *READ* them) then by all means, take advantage of the technology.
And I couldn't care less what *YOU* think is an outmoded model. The minute you can get an economist or somebody with knowledge of the industry to tell me propriatory is dead, then I'll listen.
BTW> BFS is documented in a book, and an GPL'ed clone is part of AtheOS. Go have fun with it.
Re:Obligatory BeOS plug. (Score:2)
Re:BeOS has the best Filesystem (64-bit) (Score:2)
- The BeOS VM isn't a work of art (like the rest of the OS) it does have some "issues."
- Replicants are sorely under-powered.
B) You are terribly wrong about the 32MB limit. There is a 32 MB add-on limit. While it is true that add-ons were meant more for plug-ins rather than a component architecture (BeZilla and Mozilla in general uses a system called XPCom which allows major components to be dynamically replaced. Its essentially a cross-platform COM and requires dynamically loadable shared libraries) I think that COM is a pretty cool technology and that the 32MB limit isn't very helpful. HOWEVER, there is a work around, all you have to do is link your add-on to a shared library. The limit for that is around 256MB, so its not a big problem yet.
Re:BeOS has the best Filesystem (64-bit) (Score:2)
Re:BeOS has the best Filesystem (64-bit) (Score:2)
Re:A brief summary (Score:2)
Re:A brief summary (Score:2)
Re:Huh? (Score:2)
>>>>>>>>>>>>>>>>
Yea, I know, all software users are slaves. What's your point? Does Slashdot automatically append a "none of this applies for BeOS which is perfect" message to all my posts?
But again, your reasoning is flawed. I can run KDE programs and GNOME programs and old Xt programs and even terminal programs, all at the same time. I
need to have all the libraries a program requires installed, yes, but go ahead and show me a program that will run without a library it needs.
>>>>>>>>>>>>>>>.
It shouldn't have to be that way! I can plug any electric product into any outlet and be reasonably sure it will work. I don't have to have other types of outlets installed in order for it to work. I can buy nails and use them with any hammer, without buying multiple hammers for nails only compatible with one type of hammer.I can buy a Japaneese car without importing Japaneese roads, so why can't all my programs run on whatever DE I choose? Sure this is idealistic, but the software industry is *FAR* behind the rest of the consumer industries in friendlieness. The problem is, everything else has a standard interface. A hammer works on any type of nail mainly because the hammer->nail interface is constant. A road works with any car, because the road->car interface is constant. I can buy a hair-dryer and have it work with any type of hair because the hair->dryer interface is nostant. Going to an even more practical level, I can buy any pair stereo speakers, and be sure they work with my stereo (mostly.) I don't have to worry about what the speaker->stereo interface is, and I don't have to buy multiple stereos for each type of speaker.
Better still, since most of this stuff is Open Source, we can take the program and re-write it to use the desktop environment of our choice. We can even
change the desktop environment if we need to.
>>>>>>>>>>>>>
Yea, and I can leave Iraq if I want to. Just sneak out without Sadam noticing, and get into the US without Uncle Sam noticing. The "But you've got the source!" arugement is just a cop out. Its not really a practical method for getting user input into the software. Does your car manufacturer ask you to submit
With BeOS, on the other hand, you're locked in, and cannot change it. Sounds like you're the real slave to me
>>>>>>>>>>>>
Excuse me? When does it take an OSS OS to write OSS apps? The BeOS GUI is OpenSource, the architecture is very open (so you can modify the system quit extensivly through add-ons) and there is no clause saying "thou shalt not write OSS apps on BeOS." You can't much with the system, but you can do just about everything else. And all of that is irrelevant. In BeOS, Linux, whatever, its the programmers deciding what you should do, not the users. (Actually, BeOS programs, like other small programming projects, tend to be much more receptive to user demands than larger projects like GNOME.)
Re:Slavery? (Score:2)
Re:BeOS has the best Filesystem (64-bit) (Score:2)
You analogy equates to:
If your favorite program is GNOME, than you have no choice but to run GNOME. If your favorite company is microsoft, you have no choice but to run Windows.
The correct analogy is:
If your fave program is GNOME, you have no choice other than to run GNOME. If your fave car is Porsche (american cars? Bah!) , you can run it on whatever damn road you please.
Re:More flawed logic from our friend be-fan (Score:2)
lines in Linux go to support things BeOS does not. Drivers. Platforms. Features. Stability. Security.
Whatever. Maybe they're documentation. Maybe they're copyright notices. But then, we really don't
know, do we? We can't know, because BeOS holds us hostage with its source code.
>>>>>>>>>>>>>>>>>
I know lines-of code isn't an accurate measurement. Most of the stuff is features that BeOS doesn't, and probably won't ever, have. I was defending the Linux kernel, don't piss me off. I brought up BeOS just to put things in prespective.
The nice thing about Linux is that nobody is forcing you to run all that "crap", as you so eloquently
put it. If you want a stripped-down, bare-bones system with nothing but X11 and a single app, you
can do that. Don't need the GUI? You can toss that, too. If you have the horsepower and the desire,
you can also run GNOME with Enlightenment and every silly graphics effect you can think of
turned on, plus sixteen different versions of Mozilla at once. Your choice.
>>>>>>>>>>>>>
No, it's not my choice. I want to run gnumeric. Do I have any other choice than to run GNOME (or GNOME inside KDE, or inside TWM or whatever, the RAM requirement is still obscene)??? You don't have a choice! You have to run what the developers want you to run, and if you need gnumeric, or KOffice, or KDevelop, or Mozilla, you have to put up with all the addendant baggage they carry. That's why I favor slim, standardized base systems so much. In the real world, (as opposed the the best case world Linux users seem to live in ie: where everyone can hack the kernel, and change apps to different toolkits on whim) they allow a user much more flexibility in what programs they can run without incurring more bloat. That doesn't necessarily mean one DE. There can be a hundred DEs, as long as they are all binary compatible (you know, kind of like the way it was with those dozens of window managers. I could run any Linux app back then, and have only one WM installed.)
Re:Journalling is dead. Long live phase trees! (Score:2)
Embedded devices that need consistant IO rates with little RAM for buffering probably want to look at a journaling FS.
Re:People say... (Score:2)
Bullocks. NTFS is a Journaling File System, albeit a crippled one, due to the fact that NTFS only journals META-DATA, not DATA.
http://oss.sgi.com/projects/xfs/papers/xfs_white/
http://www.executive.com/whats-new/whitepaper.asp [executive.com]
--
"We don't need no stinkin Karma" - 3 Amigos
Re:ReiserFS (Score:2)
You must have some really valuable pr0n to need a journaling FS for it
Mike.
journaling FS (Score:2)
it explains different features and concepts related to the 4 different journaling filesystems. XFS, JFS, Ext3 and ReiserFS.
Diversity is good (Score:2)
Back in the old days (around 1994) one had the choice between minix, xiafs, ext and ext2 as filesystems for ones linux box. ext2 stayed
Today we face another choice and I sure that is darwinian way we'll select the right next generation filesystem.
The big difference is however that the filesystems that existed back then didn't have any money (companies) behind them who could blur the choice and ext2 survived because of its technical superiority over the others.
Something else that may lead to different filesystems suviving is that the Journaling filesystems mentioned all have their own disign and possible uses. On some systems it may be worth the performance penalty for data security on others it may not.
Making journalling available to applications (Score:2)
-
open Open for writing starts a new version of the file, which initially shares all the pages of the old one. Writes are copy-on-write, so you can append to a file at low cost. Until the file is closed or committed, other reading processes see the old file.
-
commit Commits the file; the new version replaces the old one. This can be done without closing the file.
-
revert Reverts the file to the last commit; the old copy becomes the current one.
-
close Commits and closes the file.
-
exit Commits and closes all files.
-
abort Reverts and closes all files.
-
SIGKILL, etc. Works like abort.
This gives database-like transactions at the file level; either the update happens completely or not at all. There's an "unfrozen" file mode, for files that aren't updated as a unit and need to be looked at by other processes during update, but it's not needed much.Transactions are really valuable when accessing a remote file system, where you may lose connectivity during an update. LOCUS was a distributed UNIX in an era when networks weren't very reliable, so that made sense.
Am I the only one seeing this? (Score:2)
Also, there is the issue of IBM openly supporting, lets say XFS. While that might make good business sense, it would mean lots of bad PR and midshare loss.
The "market" will eventually make the winner(s) the defacto standard, but it never hurts to have direct support for other fs's you may need to interact with. I use support for the windows file systems all the time (fat32), but I would never dream of really using it as a main Linux volume....but it is always mounted.
-Pete
Re:Journalling is dead. Long live phase trees! (Score:2)
Sort of like saying: "Forget all that Red Hat and Debian crap... LONG LIVE LINUX! " ?
Thanks for the link, however.
Re:Actually... (Score:2)
Re: (Score:2)
Re:BeOS has the best Filesystem (64-bit) (Score:2)
lines last I heard).
> there is no workaround short of fixing the flaw in the BeOS kernel
Of *course* there are workarounds - such a workaround is being used for the Mozilla port.
C-YA
Jon
I choose ReiserFS (Score:2)
I installed the ReiserFS kernel patch and utilities today, and just finished replacing all my partitions with ReiserFS partitions. Let me tell you why I chose ReiserFS over the other three mentioned.
Biggest concern is stability. Ext3 is version 0.0.2e, which is not a reassuring sign. JFS is 0.0.3 (or somewhere around there), again not very reassuring. I don't know the version number of the XFS port, but it does say on the website something about the FS port being beta, and that it "may damage" data. Furthermore, it is only available for kernel 2.4.0, which doesn't seem to work with my sound card module (I'll never by a product based on Aureal hardware again). ReiserFS is up to version 3.5 on stable kernels, which indicates that it's been around for a while. Plus, the testimonial on their web page says sourceforge uses RFS for half their servers. If it works for them, I figure it works for me.
Another problem with Ext3 is the fact that it's just Ext2 with journaling grafted on. I want a filesystem built around journaling, not journaling built around a filesystem.
XFS and JFS bother me because they are early ports of software for different platforms. I trust Ext3 over either of these, simply because Ext3 was meant specifically for Linux. If SGI or IBM can make their ports stable, they'll be worth looking into.
RFS was built from the ground up as a Linux-native, journaling file system. People have used it and loved it. I love it too, at least as much as I can after knowing it for only a few hours. I've reset it a few times now, beaming as the screen says, "3 transactions replayed in 2 seconds" and mounts my partition, rather than saying "fsck forced... 1%...2%...3%..." and mounting my partition five minutes later. So far, I've not found any lost data. The only thing that bothers me is the lack of extended attributes, but I never use them anyway.
FSCK forcefully wiping out data in order to boot was what sent me crying back to WinNT about a year ago. It was the only grudge I held when I went crying back to Linux from NT two months after that. I treated my power button delicately, and shut my PC down every time a thunderstorm started.
With ReiserFS, this could be the beginning of a beautiful friendship, where I can tempt the fates by continuing to work in a thunderstorm, and I don't have to tremble with fear that I might accidentally pull the wrong cord if I need to unplug something on the same outlet as my PC.
Whether it's XFS, JFS, RFS, or Ext3, at least we can say that NT no longer has ANYTHING over Linux. Choice is good.
I do not belong in the spam.redirect.de domain.
Re:But ReiserFS has another advantage (Score:2)
XFS is a journaling system on it's own and it is SGI's crown jewel achievement - It does not need to be integrated in any way with ext3 as that is not the goal here. Eventually XFS on linux will be used with CFXS which is journaling with clustering which ext3 does not support. XFS on IRIX is one of the fastest journaling file systems on the market and it scales incredibly high. No other Journaling system for linux, not even reiserfs, can match the speed or scalability of sgi's xfs.
On a side note, I use reiser on my box at home and I'm very pleased with it. It is not however, as fast or as scalable on an enterprise scale as XFS. For more info on XFS please see http://oss.sgi.com/projects/xfs/papers/xfs_GPL.pd
The specs are impressive. While the code is beta, they hope to achieve the same level of performance on linux as has already been achieved on IRIX.
Re:ext3 more real than JFS (Score:2)
Do you really mean that JFS doesn't support mixed case filenames, ot did you intend to say that JFS is case insensitive? I know I'm not the only one who thinks that case sensitivity is something that should be reserved for the written word and passwords. Mixed case filenames are fine, just don't force me to use them -- C makes it really easy to shift a byte's value by 64...
--
Re:A brief summary (Score:2)
U forgot GFS - Global File System (Score:2)
A file system for SCSI over fibre that have journaling.
Re:Journalling is dead. Long live phase trees! (Score:2)
I wrote about RAM in another article - Tux2 won't use a lot more, and because of its ability to throttle the dirty cache, could use significantly less than we're used to.
As for CPU - I haven't really noticed a big difference vs Ext2 but I'm not in real-world testing situations yet. The only CPU intensive thing Tux2 does is make extra trips into the block allocation bitmaps. There are roughly zero extra trips the first time you write a file, and 100% extra trips if you rewrite the file without truncating it first - actually, a pretty rare thing to do. A database might do it though, and for that case I'll provide a per-file disable of the copy-on-write - the metadata will still be protected but the database will be responsible for doing its own crash recovery for the file data, which most databases do pretty well. In fact, the phase tree algorithm started life in a database.
--
Combine efforts... why (Score:3)
- Compatition is key to all things being good...
- Each FS has an almost compleatly different techincal design, and each has a chance of being the "best" general purpose FS.
- Each FS might in fact be the "best" at some things
- Each developer is working on their respective project because they think it is the right thing to do. You tell them "No, stop that work on your project and help this one" and they will. They will see that the comunity thinks of their project as meaningless wheel-reinvention and quit.
There are many more reasons that others will point out as well. Look at other industries. Why are there different radio stations? Different cars (even made by the same company)?
Hey, if I stop one more person from telling my friends and my self that we should join this other project or that then this note is worth it.
Got a problem with my view? I'm easy to find.
Jamie B
Re:Do they remove the 2G file size limits? (Score:3)
As far as I can tell, all of these filesystems allow files vastly bigger than 2GB, but the interface between VFS and LIBC still nicely enforces the 2GB limit for most purposes.
This is the wrong thread on which to try to find resolution to that issue; take it up with the folks that defined ISO and ANSI C...
Hmm.. (Score:3)
That's like asking all the *BSDs to work together with Linux. Diversity is a very good thing. Personally I think SGI's XFS is going to kick some serious butt since the SGI folks are all for high performance and huge I/O throughput performance. They've also shown they can do it (on Irix). Not that the other parties will stay behind. I just think SGI has a better chance at dominating the Journalling FS landscape in Linux...
-adnans
Only Ext3 works with new NFS v3 code ... (Score:3)
I have production systems now using Ext3, which is little more than Ext2 with full data journaling (and completely reversable). This is NOT an endorsement of Ext3, but the fact is that it is the only use usable at this point (largely because it is just a slight evolution from Ext2, unlike the others).
I am in the middle of a ~30 page HOWTO on NFS+Journaling. Contact me direclty if you are interested in a copy. Again, I have production servers and workstations running with Ext3 and sharing data out via NFS v2/3.
-- Bryan "TheBS" Smith
Obligatory BeOS plug. (Score:3)
With all this talk of journeling file system, I'm surprised that bfs got ignored. BFS has several things going for it:
1) It's fast. While it is a journaling file system, on Bonnie, it is about 20% faster than my ReiserFS partition (which is closer to the outside of the disk too) on straight reads and writes. It is also a good bit faster on the per-char tests. Best of all, the CPU utilization is 30% lower than Linux in the sequential, and 50% lower in the per char (where Linux pegs the CPU). However, the rewrite tests, it is significantly slower. Something I think has more to do with the BeOS VM and disk cache than the file system.
2) It is ever so solid. I regularly (read: three times a week) shut down my BeOS machine with my power button. Not yet have I gotten a lost file, block, or data corruption. Linux regularly needs reinstalling if I turn it off in the middle of something important, and even NT bugs out on me for not shutting down. (I just hosed the system two days ago.)
3) It has had database capabilities for years, while ReiserFS still has them in planning. That might be a "gee-whiz" features, but nothing beats having your MP3s automatically entered in a database based on ID3 info. (Or emails, or pictures, or whatever.)
4) It has a flexible system of attributes. No more
Re:Do they remove the 2G file size limits? (Score:3)
Linux 2.4 has a set of 64bit file calls which work natively on 64-bit achitectures, and work also on 32-bit architectures by using double word operations. You take a performance hit on 32-bit systems, but it works fine. The glibc 2.x has it, as does the kernel. You just have to ensure that the libc was compiled with support for it.
Remember, this is opensource. We've patched the libc and vfs layer with little trouble because of it. Now it just needs testing
--
Some do different things (Score:3)
Ext3 can be used (once it's stable) on a preexisting Ext2 filesystem. The others cannot directly migrate from anything 'official'.
I like the ideas of all four. It may be that you want to have a combination of all of them in your system, but that would be pushing it.
I've used JFS a lot and it is really bulletproof if you set it up properly. It's heavily tied to the LVM in AIX, so I wouldn't expect much progress without LVM for Linux being a stable API. So, call it post 2.4.0 at least.
ReiserFS is more than just fine, its great! (Score:3)
At work I have five workstations and two servers running ReiserFS. These have performed flawlessly over the past several months, as they have been eased into production.
The ReiserFS folks have been really good about finding and fixing bugs. Recently, a bug was discovered which crashed the system with ReiserFS-3.6 systems if you saved a file from Star Office on top of itself on an NFS server. That bug was eliminated with ReiserFS-3.6.17 in just a few days after being reported.
Since ReiserFS isn't merged into the official kernel tree, when you want to try out the latest kernel, you have to patch ReiserFS into the system yourself, but that is quite easy.
I look forward to the day when ReiserFS and these others are merged into the kernel. By the way, the 2.4 kernel is quite nice. Try copying a file several times your memory size from one disk to another (a 600 mb iso image should do the trick) on both 2.2.x and 2.4.0-test9pre-whatever. And try to do something with your system during the copy. You'll become addicted to 2.4.0, I promise you. Its wonderful.
Re:Journalling is dead. Long live phase trees! (Score:3)
I'm curious...does anyone know how much more RAM/CPU Tux2/ReiserFS/... need over and beyond Ext2? Journaling is an impressive feature, yet some of the machines I monitor aren't cutting edge; Pentium 200/64MB, Celeron 300/96MB. I've already tweaked these systems in other ways (no extra consoles, MTTR settings, ...).
Um, it's deja vu all over again... (Score:4)
Re:ReiserFS (Score:4)
preaching Linux for 3 years - patients pays off!) They gave me an
old P100 with 71MB or usable RAM and two HDs.
I decided to use SuSE 6.4 BECAUSE it had ReiserFS.
The graphic install really impressed the Win techies standing
around watching because it was easy enough that even they
could do it, and is pretty eye candy. KDe really impressed them
too.
Thirty minutes later the second HD, a 4.3 BigFoot, died.
I had
The dead drive was smoothly disconnected from the system.
Since I was needed to power down to replace the HD I decided
to test out the ReiserFS. I reached over and pressed the reset
button. A collective "gasp!" rose from the assembled techies.
Thirty seconds later I had the KDE graphical login prompt.
No corruption, no losses. It's like having an UPS attached.
I didn't notice any increase in speed of file accessing, but it
was fast at rebooting. It's been up 18 days now, which is
also impressing the techies in our M$ shop. They are still
afraid of Linux though. I think it is because they may feel
that they may have to retrain, loosing any employment
advantages they may have accumulated. They are right.
Re:Try *BSD Soft Updates (Score:4)
You can boot a Soft Updates file system without fscking it, the file system will be in a functional state. The only problem is that you might start to loose free blocks that are believed to be busy. So every 100 or 200 crashes you might want to run fsck to free those 100 blocks.
I agree with you regarding the ext2 file system when running in async mode: when there is a lot of activity on the disk, and a lot of changes to the file system, crashing an ext2 file system will loose a considerable ammount of data. ext2 fsck will not be able to recover your file system properly (it has happened to me a couple of times already).
For non-SoftUpdates kernels and non-Journaling kernels, if you are running a system with sensitive information, I suggest turning syncronous access on the file system (add option sync to it).
The sad part here is that the BSDs have traditionally been optimized for the syncronous case, so they run at acceptable speeds. Linux ext2fs has never been optimized for this case so in practice it is very slow.
I am using ReiserFS on my laptop, but on a server, if I had to choose, I would run SoftUpdates for BSD kernels and ReiserFS for Linux kernels.
Miguel.
ext3 more real than JFS (Score:4)
JFS was another story. My take on the talk was that people who atteneded it learned one important thing: JFS is the journaling file system to ignore. The Linux port comes from OS/2, instead of directly from AIX. It lacks such things as support for mixed case filenames. The answers to most of the questions were, "We hadn't thought of that," or, "We'll have to look into that." If JFS didn't have the "me-too" ego of IBM behind it, the developers would have realized that they were better off working on one of the other file systems.
ReiserFS is just fine by me (Score:4)
In my opinion, you just get more. I also found the installation and recompile fairly easy to do. I've been using ReiserFS for the past 3 months with absolutely no problems.
Re:ReiserFS is just fine by me (Score:4)
Encryption is a two-way function requiring a key (3DES, blowfish, IDEA), or a pair of matched one-way functions (RSA, DSA). Don't confuse this with a cryptographic hash which is strictly one way. And don't confuse hashes with any form of encryption.
--
Re:Journalling is dead. Long live phase trees! (Score:4)
I've analyzed that question and I think tux2 will only use a little more cache memory, not a lot more, and it could even be less - see below. Tux2 uses per-block copy-on-write, and when the old version of a block won't be used any more (the normal case) that means you can just change the disk block number in the buffer - no extra memory used at all. The only time extra memory is used is when a file block is written over and over again, every 10th of a second or so - then you will sometimes get two copies of it in memory at the same time. The first copy will disappear as soon as it finishes being transfered to disk. This kind of writing pattern is rare with normal data but is common with metadata. Fortunately metadata is about
In fact, I think Tux2 will take a load off the buffer/page cache because it doesn't let dirty data hang around a long time - it starts writing to disk a fraction of a second after you start writing to a file. My plan is to have Tux2 shorten its phase length under heavy memory pressure, so the space needed for dirty buffers will drop down to just 100-200K, and you'll still get good performance.
Cache memory for reading under Tux2 is the same as Ext2 and most other filesystems.
--
A brief summary (Score:5)
JFS has been around for years under AIX. It's a well proven general purpose journalling filesystem.
ReiserFS is the best established of the Linux journalling filesystems. It has several fairly innovative features and is more efficient than ext2 in terms of space utilisation. People are using it as their primary filesystem now, although it's still in development.
EXT3 is (unsurprisingly) a development of EXT2. It lacks most of the pretty features of the other journalled filesystems, but has the significant advantage that you can turn EXT2 partitions into EXT3 (and vice versa) without any trouble at all.
Try *BSD Soft Updates (Score:5)
As an experiment, I pulled the plug towards the end of 5 FreeBSD kernel compiles (SMP `make -j 4`). In all cases, the fsck upon restart was minor, just freeing inodes. In four of the cases, `make` just picked up where it left off, and finished the kernel compile, losing only ~40 seconds work. In one case, a `make clean` had to be done because something was incomplete.
Don't try this on Linux! The ext2 fsck is horrible after a powerfail, and I've lost superblocks and had to re-install
Journalling is dead. Long live phase trees! (Score:5)
It is also proof that open source software does not just 'chase tail lights' - the work is substantially innovative.
Phillips is also implementing tailmerging (a feature from ReiserFS to efficiently store small files) for ext2/ext3/tux2.
For more details, check his web pages here [innominate.org], and the linux-fsdevel mailinglist.