# JFS or ext3, suggestions?

## leviathan4444

Hi,

     I've searched through the forums, but haven't really found the ultimate answer to my question. I'm reconfiguring a server for a small business that I work for. We currently have about 1.4TB of data, and will be expanding the server to 3TB. The integrity of data is critical, I can't afford there to be any data corruption. I previously used reiserfs v3.6, and the only problem I've ever had is now that the server is up to 98% or so utilization of space, its gotten a bit slow. Due to stagnating development on reiserfs, I think it would be best to switch to another filesystem. I've read up on all of them. I've read that XFS can have some corruption issues -- I read a forum posting by a guy that said he migrated 9 systems to XFS, and within around 6 months, they all had data corruption. This rules out XFS. ext4 is out, as it simply isn't proven enough yet. This pretty much boils it down to ext3, and JFS. I do have a UPS hooked up to this server that will auto power it down in case of power failure. It should also be noted that I'm planning on using pretty much all the available space in one filesystem, and the 3TB filesystem I will create will probably need to be expanded in the future. Running out of inodes isn't a huge issue, as most of the files we create are 50-100MB or larger. Data integrity is most important followed by performance. I would appreciate any thoughts and/or recommendations on this issue that you guys might have. Thanks so much!  :Smile: 

----------

## gentoo_ram

Huh, I've been using XFS for years.  Haven't had any data corruption issues.  The risk with XFS is that if the machine goes down, then some data might be lost since the data and metadata aren't flushed at the same time.  But this is a possible issue no matter what if the power is lost.  It sounds you have the power issues in hand though.

----------

## leviathan4444

Thanks for replying. Its good to hear the positive review of XFS. If you've been using it successfully for a few years, then I might add XFS to my list of filesystems to consider.

----------

## FizzyWidget

only issue i seem to have with ext3 is the fact it never uses the whole of the lvm i have made and then ontop of that reserves 5% of the space, which i turn off anyway, not really required on a storage drive

----------

## agent_jdh

I used to run JFS exclusively on two boxes here for a few years - switched each drive to ext3 because it gave a big performance increase (on the same hardware), especially syncing the portage tree.  Not had any data corruption/loss issues with either FS, and that includes plenty of hard resets.

----------

## tuber

My gripe with ext3 is that it can't be resized dynamically (while mounted), while JFS can.

----------

## leviathan4444

I really appreciate all the replies to my question so far. Any other thoughts or suggestions would be most welcome.  :Smile: 

I probably should have mentioned before that this setup will be used for a moderate number of smaller files (not many tiny ones though,) and a large number of large files 100MB -> ≈1.2GB.

----------

## FizzyWidget

it all depends on what you are going to do with the drive and fs, as different file systems have difference strengths and weaknesses

http://linuxgazette.net/102/piszcz.html - bit old now, and i suppose there are newer ones about, i just found that in my book marks, but it should give you and idea of what i mean

----------

## jormartr

I have been reading though the internet about jfs and xfs, looking for a better filesystem (compared to ext3).

From what I have readen, on several websites, blogs, benchmarks, forums and so on..., XFS is the best one to choose when you have to deal with big files on big disk systems. It scales very well when you add more disks and cpu's to the system. Sounds really nice, but to be so good it aggresively caches data, so you must rely on stable hardware and battery back up, if not you may end with filesystem corruption.

JFS seems a nice "overall features" good fs. Has a very low cpu usage and in general terms seems faster than ext3.

This is the impression I have after reading some sites, but of course, some of these sometimes does not have good words on these file systems. On some of them read histories about xfs corruption, and histories of JFS being slower than ext3.

As my home hardware is not enterprise quality, I am afraid to go for XFS. My home machine is attached to a UPS, but I sometimes play with it, so I can expect some hungs from time to time., and I have decided to try JFS this weekend.

----------

## rambam

I use JFS for the volume my /home is mounted on and ext3 for the rest.

I have been happy with that combination.

----------

## djinnZ

The only real problem with jfs (i never more use it, so my report is sure outdated) is than in case of corruption you can not easy fix the filesystem but in fact, xfs is really slow as delete a large amount of files (a real pain for the tmp or var directory management) but can be easy (rare necessity) defragmented, reiser 3.6 hardly lock itself but I have experienced some data loss (files vanished) and suffer from fragmentation more than ext3, ext3 in front of xfs or reiser is slow etc... every filesystem has good and bad points.

The solution of mine is to have the root, the home and the portage distifiles (the main portage tree is on squash) in xfs and the var, the tmp and some shared for users in reiser (3.6 not 4).

Hard caching, necessity of backups for power and data etc. for xfs are urban legends (referred to solved issues) now.

The only filesystem has really caused troubles (an entire partition loss) in my experience is ext3.

But for a large filesystem as you think (more than 3TB) the only suggestion is to verify if the problem on remove the dirty flag is solved in jfs now, the security is the only question because the performance of xfs and jfs are similar.

----------

## energyman76b

reiserfs is STABLE. Not stagnant, STABLE. Means, no stupid featuritis. Bugfixes, nothing else. 

ext3 was never as stable as reiserfs - so if it works well for you, why switch away?

Especially why switch to fs that don't care about your data? ext3 doesn't care by default and jfs can't even forced to care.

Stay with reiserfs.

----------

## alex.blackbit

i never had data corruption problems with xfs in many years.

on my machines jfs did not behave nicely in the past.

i got corrupted filesystems on power outage that were very difficult to repair.

i'd recommend xfs.

----------

## energyman76b

don't use ext3, except if you love occasional 480sec pauses:

http://marc.info/?l=linux-kernel&m=123789077610123&w=2

(and the 10 before that)

----------

## mathfeel

 *Carps wrote:*   

> it all depends on what you are going to do with the drive and fs, as different file systems have difference strengths and weaknesses
> 
> http://linuxgazette.net/102/piszcz.html - bit old now, and i suppose there are newer ones about, i just found that in my book marks, but it should give you and idea of what i mean

 

Indeed, here's new update I found today if you are interested in updating your bookmark:

http://linuxgazette.net/122/piszcz.html

----------

## leviathan4444

First off thanks again for all the posts. I really appreciate all the input. 

energyman76b - I like your thoughts on reiserfs3.6. I do indeed aggre that its stable. However, I am concerned for the future. From my understanding, there are apparently only two guys left who do bugfixes on reiserfs3.6, and these two guys have other priorities. I read this in a posting somewhere, while researching the development status on reiser. Hans is, of course in jail, and namesys is apparently dead. I have encounted the slowdown with reiser that I have read about, but I think that's to be expected when you have 15GB out of 1.4TB available. We sometimes get pauses that can last up to a minute, but they always work themselves out. These pauses have only cropped up now that the system is approaching 100% utilization of space. This has been my only problem with reiserfs so far. I'm concerned that a future change in the kernel, or some other issue might cause a problem with reiser in the future that might not get fixed. I'm also concerned that it may eventually be deprecated from the kernel anyway. I have used it in the past on other systems, as well as on our current system, and its predecessor, without any trouble. If the whole jail thing hadn't happened, I wouldn't even be considering a switch. I might decide to stick with it, but I'm leaning away from it. Also, thanks for the post on ext3 delays. 

Carps - Thanks for the filesystem benchmark link. 

djinnZ - thanks for all the info. I'll look up jfs and the dirty flag issue. Interesting that you had an entire partition fail with ext3. 

alex.blackbit - thanks for the vote for XFS. I am reconsidering using this filesystem. 

All in all, I still haven't made up my mind yet. If Hans wasn't in jail, or Namesys wasn't defunct, I would most likely just continue with resier3.6. However, since this is not the case, and even though reiser3.6 is quite stable, I'm worried about how its future, which forces me to consider alternatives. Currently I'm warming up to XFS, cooling on ext3, and still considering jfs with reiserfs as a fallback. Currently I'm running some tests on our old system, and I might just benchmark all the filesystems with bonnie++ and see where that leaves me. Any other thoughts you guys have would be most welcome. Thanks!  :Smile: 

----------

## rrbrussell

I would suggest:

ext4: stable for me, resizeable, data journalling, in my experience about 25% to 50% faster than ext3 with data=journal on both

ext3: stable, resizeable, data journalling

xfs: worksUp until a few months ago I was using XFS regularly on my data server/router but it just got to slow and I upgraded to ext3. My main system uses ext3 for / and ext4 for just about everything else. I have had a few software crashes and power failures with no troubles from any of these file systems.

Mod edit: Fixed the list BBcode for you. --timeBandit

----------

## energyman76b

have you even read the thread I posted? even Linus has nothing good to say about ext4. Ext4 is braindead. An fs that does not care about data is an fs that should not exist. 

ext3 does not care. ext4 does not care. xfs does only care partially.

----------

## energyman76b

emm.. jfs is in so deep maintanence mode that there is only a patch or two in years - and you are worried about reiserfs' future?

----------

## timeBandit

 *energyman76b wrote:*   

> emm.. jfs is in so deep maintanence mode that there is only a patch or two in years - and you are worried about reiserfs' future?

  *and also wrote:*   

> reiserfs is STABLE. Not stagnant, STABLE. Means, no stupid featuritis. Bugfixes, nothing else. 

 Which is exactly the case with JFS. There has been near zero maintenance because there are near zero problems....

----------

## energyman76b

 *timeBandit wrote:*   

>  *energyman76b wrote:*   emm.. jfs is in so deep maintanence mode that there is only a patch or two in years - and you are worried about reiserfs' future?  *and also wrote:*   reiserfs is STABLE. Not stagnant, STABLE. Means, no stupid featuritis. Bugfixes, nothing else.  Which is exactly the case with JFS. There has been near zero maintenance because there are near zero problems....

 

except it does not do barriers or data journaling. Oh, and most bugs don't end in the kernel bugzilla  :Wink: 

----------

## djinnZ

 *energyman76b wrote:*   

> reiserfs is STABLE. Not stagnant, STABLE.

 reiserfs 3.6 not 4, better to be clear about this.  :Wink: 

On the PCs of mine the only reason to use ext2/3 actually is than I am obbliged to use windows and it remain the only fs with a decent rw support ([url=rfsdfsd.sf.net]reiser[/url] is a real pain to configure and not fully stable and the porting seems stagnant and hfs+ proprietary driver is poor).

Sure if you will have the ability to read from another system the volume must think at this. Reiser is useful only on linux and bsd also.

@energyman76b: jfs has really only one problem as I know, repair a filesyetm locked for corruption is painful, so i have discharged it.

Actually I see it better for the main fs as for data storage and the performance are similar to xfs.

The risk of backup and format to recover a volume larger than 1 TB is simply unacceptable for me. If this has ben solved is a serious alternative to xfs.

@leviathan4444: I have used many filesystems (i have began to use computers in 1980) and the only two than have losed data are fat32 (this is the price for using an OS borned obsolete  :Evil or Very Mad: ) and ext3. Sure i am not a fan of ext3, in fact has no real benefits in front of ext2 in my experience.

I doubt as you for the future of reiser but because linux&C has no announced anything about a possible remotion from thge kernel tree and the 3.6 is really full stable I not see any reason to fear for the future, but sure will remain supported as legacy filesystem as ext2.

----------

## ccp

Hi leviathan4444,

This is my understanding of your question, you have 1.4 TB data on a reiserfs file system. it is at 98% full. you will migrate this data to a new 3TB storage(file system TBD) the this new storage expect to expend very soon. filesize >=50MB~100MB.

And you said "Data integrity is most important" then it follow by "performance".

My question,

what do you mean by "Data integrity"? do you mean it is same as when they were saved on to the disk or you are actually thinking "data availability"?. if you mean former then how do you know your existing data have not corrupt yet? do you have some kind of check sum database for each file? or you application can verify "data integrity" on the fly?(thinking DB)

if you are sure you have the "data integrity" state now then just make sure you have a good backup of the data and have formal procedure to practice restore periodocally to ensure you have good backup then you are done.

once you have a good backup/restore practice then file system type choose become less relevant as all you care about would be which file system can give you most flexibility and best performance. you want to have a file system that can give you expandability on the fly and on the fly snapshot and quick back online when it went dirty (crash). be concern of you new storage does it have enough performance to meet you ultimate wost case to restore entire data set in time you business defined requirement.

think about it, how long you have the 1.4TB under your care and how often you have data corruption problem cause by file system and assume you do have corruption problem, are they really file system bug or just system crash cause lost of data?

I think if you take my suggested view you may see a whole new ball game now:)

Ping.

----------

## leviathan4444

djinnZ: Thanks for the info on ext3, I'll definitely avoid using it then. I guess that just leaves me with jfs, xfs, and reiserfs3.6. 

ccp:  *Quote:*   

> what do you mean by "Data integrity"? do you mean it is same as when they were saved on to the disk or you are actually thinking "data availability"?. if you mean former then how do you know your existing data have not corrupt yet? do you have some kind of check sum database for each file? or you application can verify "data integrity" on the fly?

 

I do mean that the file remains the same once saved on disk. Unfortunately, I don't have any checksuming capability. I'm the only IT guy here (small business) and while setting something like that up would be nice, we don't have the time for it. I don't know for sure on most of the files, but since I have a UPS, the system hasn't crashed, and no one's mentioned file corruption, I'm trusting that they're OK. 

As for backups, currently we do have offsite backups on external HDs, but since its easy to put off backing up, the boss has to bring the drives in, and it takes a fair bit of time (moving gobs of data over USB2 isn't too quick,) it doesn't get done as often as it should. After this big upgrade I will have a separate backup server that the primary server will do weekly backups to over the network, plus an off site backup of the backup server. Even though I will have this aggressive backup system, I have been making my decisions based more on our current model of occasional backups just to be on the safe side. Plus, silent corruption is what really worries me -- an important file gets corrupted, and no one notices. It gets propagated to the backups. We run out of backup space, all the old incremental backups are deleted, and we start with fresh backups. The corrupted file is now lost. Thus, I would like to not have to worry about filesystem corruption issues.

----------

## ccp

leviathan4444,

So you do realize the important of backup, that is good.

Now we analyze the problem, there are multiple possibility cause data corruptions; it can be cause by OS (file system code) or it can be cause by bad application code(bug), or it can be bad application logic(misunderstand OS API). the file system was design to store files under most common access pattern i.e. application open a file, write data, close file. file system manage create inode, link inode to the data segments, delete file by delete inode and from data segments. most file system can handle directory content with 10s of thousands of files. may be 10 to 100 of concurrent creation/modification of file system tree in different area.

So do you have a very unusual access pattern? i.e very very large amount of files store in one directory or very very high rate of modify directory tree? because unless you have these unusual access pattern the chance of file system corruption by itself is very very rare, it happen more often is the underlying storage system have problem which cause file system corruption, and this is really nothing file system can do to prevent it happen.

and trying to find a perfect solution to hope that so bad thing will never happen is just not practical why not spent the effort to find a solution to address when bad thing happen how to best recover it quickly.

I don't think there are kernel file system hacker in here to read this forum/thread. so do you really want to take our word on your business future?

on the other hand we can discuss this in a pure technical fashion.

if you think your access pattern worth to discuss then tell us about it we can see if the chance of corruption is high and may be we can together do some testing to find and possible file system problem or solution.

----------

## musv

I was using Reiserfs (3.6), JFS, XFS and Reiser4 for several years. I've read a lot about to find the "perfect" combination for me. In this time I've had 3 computers and of all I had a lot of hard-resets. Here are my limited experiences:

Reiserfs (3.6): 

I used it for several years for root, home and other stuff.

Advantages: On a new installation it's very fast. It's reliable. I never had any data corruptions or other problems. I used it without problems for media data on root and for the home directories. 

Big disadvantage: If you change data quite often (e.g. daily update of Portage tree) or have a full disc, it's getting incredibly slow after a while (maybe half a year).  There's no defrag-tool.

Reiser4: 

It's very reliable. I had never data corruptions oder data loss. It's my actual root partition filesystem. I'm using it for more than 3 years on my root-drives. 

Advantages: Incredibly fast. Less disc access. Something like a bigger fragmentation I didn't recognize. Until now no problems when the computer crashes. Seldom after a hard reset I wasn't able to mount the Reiser4 partition. But after a fsck.reiser4 everything worked again. Also the transparent compression is a nice feature. 

Disadvantages: 

1. You have to patch the kernel. For 2.6.29 there's still no official patch available.

2. If you want to check the filesystem, you have to use fsck.reiser4 from the reiser4progs. Checking a partition needs a lot of time depending on the number of files on that partition (up to 1 hour for my 30GB root partition). 

3. It's not suitable for a home partition. I tried it for a while. VMWare with WindowsXP as a vmx-image on Reiser4 occures a lot of disc usage. Running VMWare made the whole computer unusable. Same problem with p2p-software. Running Azureus or aMule occures a incredible disc usage too. And also the kde3-apps seem to synchronize every step on disc. For example: When I opened a new tab in Quanta I could hear there was a disc access. And that slows down the usage. I found a solution by moving the ~/.kde directory into a tmpfs when the system starts

XFS: 

Very fast, light weight. I'm using it for my multimedia stuff (MP3 and movies). After the first data loss (see disadvantages) I haven't had any problems. I'm using it for maybe 1-2 years now. 

Big advantage: It comes with a defrag-tool. And for my subjective impression it has the lowest latency of all when you try to access data.

Disadvantage: When I tried xfs for the first time I created a xfs partition, put a lot of movies on it, rebooted the machine and wasn't able to mount the xfs partition. xfs_repair and xfs_dump didn't help. 20 Gb of data loss. It was the only time I lossed data with a file system. In a debian forum they wrote, that xfs comes with some mechanims to check the filesystem integrity but not the data integrity. 

JFS: 

Due to the Reiser4 problems JFS is my actual file system for home. VMWare and P2P is working usable, the kde-stuff too. 

Advantage: It's reliable. Also after a lot of hard resets I never had a data loss. 

Disadvantages: After a hard reset or a not clear unmount it's always replaying the journal which needs up to a minute. But the biggest annoying thing is: It seems to fragment totally. My home partition is filled up to 90% - sometimes up to 99%. Especially files downloaded by p2p occure a disc usage where you could think the computer is moving tons of GB on the disc. Solution here: cp that files from the JFS parition to another disc and back. Then it's working. 

Summary: 

If you make a big usage of backups and UPS, then xfs would be my first choice particularly with regard to the defrag-tool. Also Reiser4 for my experience is very recommendable. Because of the slowdown I'm not very happy with JFS. In many aspects it seems not to be the fastest one. But nevertheless it's reliable. A defrag-tool exists on IBM operating systems but not for Linux. Reiserfs I'm not using any more. I replaced it with Reiser4. Maybe I'll consider to replace JFS with Reiserfs. And about btrfs it's not worth to speak, it's still alpha stadium.

Ext2 I'm using for my boot-partition. Ext3 I haven't never used on my private computers. For some reason I can't explain I don't like the ext-stuff. Maybe I would use ext3 on a production-server where reliability is far more important than speed. About ext4 I read of some problems, but never got in touch with it.

----------

## rrbrussell

Of the file systems that I have used and use regularly I recomend Ext3 for right now usage and then upgrade to Ext4 in 3 to 6 months. If you are sure that the 2.6.28 kernel will not give you fits, I would go ahead and move to Ext4.

I have not had any rememberable data loss on XFS, JFS, or Reiser 3. I do however rember the rapid performance degredation from really nice new to slow after only a few months. I never bothered with trying to defragment any of these file systems. I just moved back to Ext3 which never really seemed to have the sharp performance degradation relative to age. If I remember correctly another reason I have consistently used Ext3 and now Ext4 is their more reliable resizing option.

Ext4 appears to be the fastest file system I have used. It also appears to keep that edge even when dealing with full data journaling, logical volumes fragmented across 2 disks with several resizes and the default allocation policy, full disk AES-256 encryption on both disks, and file fragmentation of around 20% if fsck's output is to be believed.

----------

## leviathan4444

I just wanted to wrap up my post here and say thanks to everyone who posted. I really appreciate your suggestions and thoughts. I also wanted to let everyone know what my decision is.

I have decided to go with JFS. If JFS turns out to be painfully slow, I will switch to XFS. I know that XFS is faster, and I like the defrag and freeze capabilities, but those scattered reports of occasion problems make me nervous. 

Thanks again to everyone who posted!  :Smile: 

----------

## paulbiz

I was going to recommend "anything but JFS" but as you've already made your decision I will simply wish you good luck  :Smile: 

My suggestion for JFS: If you suffer a crash/power outage and the journal replay fails, DO NOT fsck the partition or else it'll rename potentially hundreds of thousands of files and directories to meaningless numbers. Use a JFS recovery tool to find the lost files and copy everything off to another disk. Then format the JFS partition and copy everything back, and try to figure out what's missing.  :Smile:  Failing the presense of full and recent backups, I would at least generate some kind of list of all files in your JFS partition and store it on another disk so that if you suffer a failure, you can figure out what's missing.

I've tried XFS, ext3 and ext4 as well. I don't do anything too intensive and on modern hardware none of them really make any difference as far as I can tell. When using XFS and lost power to the drive (external drive power supply died), it could not be mounted, but I was able to use the xfs tools to recover the files to another disk.

From reliablity ext3 is the one I have the most luck with. I've never had any issue after crashes/power failure and it generally seems to "just work". Plus it is ext2-backwards-compatible so there are more tools for dealing with potential issues.

Now I'm using ext4 on my laptop, converted from ext3, and really don't notice any difference. On my desktop I'm using ext3 mounted as ext4 so I can get the supposed improvements(which I can't notice) while still maintaining backwards-compatibility in case anything goes wrong.

----------

## shazeal

 *Quote:*   

> Now I'm using ext4 on my laptop, converted from ext3, and really don't notice any difference. On my desktop I'm using ext3 mounted as ext4 so I can get the supposed improvements(which I can't notice) while still maintaining backwards-compatibility in case anything goes wrong.

 

You cant do this... convert to ext4 or stick with ext3 you cant just mount ext3 as ext4 and expect something magical to happen.

----------

## paulbiz

 *shazeal wrote:*   

>  *Quote:*   Now I'm using ext4 on my laptop, converted from ext3, and really don't notice any difference. On my desktop I'm using ext3 mounted as ext4 so I can get the supposed improvements(which I can't notice) while still maintaining backwards-compatibility in case anything goes wrong. 
> 
> You cant do this... convert to ext4 or stick with ext3 you cant just mount ext3 as ext4 and expect something magical to happen.

 

That's not what http://ext4.wiki.kernel.org/index.php/Ext4_Howto says:

 *Quote:*   

> It is possible to mount both ext3 (and ext2, in kernels 2.6.28 and later) filesystems directly using the ext4 filesystem driver. This will allow you to use many of the in-core performance enhancements such as delayed allocation (delalloc) and multi-block allocation (mballoc), and large inodes if your ext3 filesystem have been formatted with large inodes as is the default with newer versions of e2fsprogs. Simply mounting an ext3 (or ext2) filesystem with a modern (2.6.27+) version of ext4 will not change the on-disk structures, and it is possible to revert to the ext3 (or ext2) driver should there be any problem with ext4.

 

----------

## pixxt

Use any file-system you want just stay away from Reiser 3. It is a dead filesystem no pun intended, its the slowest file-system upon boot-up it fragments easily and real world use suggests it suffers from bit rot, i.e. the longer you use it the slower it gets. It does not scale up in performance with added cpus or added disks.

----------

## shazeal

 *Quote:*   

> That's not what http://ext4.wiki.kernel.org/index.php/Ext4_Howto says: 

 

True, but you yourself are witness to the fact it makes stuff all difference. Unless you enable the new features its still just ext3.

----------

