Questions[jfs](server)

The last real question I've seen on this topic is from about two years ago (is ext4 ready for production usage).

In the intervening time, how has ext4 improved?

XFS, JFS, and ext3 are the standby reliable choices. I've only used ext4 on recent Ubuntu test/dev environments, and haven't seen any issues - but they're also low-use workstations, VMs, and throw-away training environments.

How does ext4 stack up now that it's had [some] time to mature vs XFS and JFS (especially) from a speed and reliability standpoint?

Is ZFS a viable option (seeing as it's a fuse module, probably not for Linux - yet)?

I have an application which is doing a lot of file operations.Its doing a lots of file read and write operations(lot of small files). We have found that some of the files are getting mixed up randomly. Output of file1 is going to file2 and so on. There is no concurrency issue from code that we have verified. Its working in all other platforms expect AIX.

In Solaris we faced this issue, but after enabling directio this issue is resolved.

In AIX we tried to enable dio, still this problem persists.

1. OS : AIX 6.1.6.3
2. Architecture : Power 6;
3. 8 core with SMT on
4. Storage : SAN
5. FileSystem : JFS2

Thanks Nikesh PL

There was a power failure recently that took down one of my servers. On reboot, the main storage filesystem - JFS on a 7TB (9x1TB RAID6) filesystem - needed an fsck before mounting read-write. After I started the fsck, I watched it for awhile in top - memory usage was rising steadily (but not too rapidly), and CPU usage was pegged at or near 100%.

Now, about 12 hours in, the fsck process has consumed almost 94% of the 4GB of memory in the system and CPU usage has dropped to around 2%. The process is still running (and gives no indication as to further running time).

First off: is this indicative of a problem? I'm worried by the fact that the CPU usage has dropped so dramatically - it seems almost as though the process has become memory-bound, and the fsck will take forever to complete because it's spending all its time swapping. (I noticed that kswapd0 is floating uncomfortably close to the top of the list in top, actually beating out the fsck process for CPU usage more than half the time.) If this isn't the case, if fsck just slows down CPU-wise near the end of the process, that's fine - I just need to know that.

If this is a problem, what can I do to improve fsck performance? I'm open to almost anything, up to and including "buy more memory for the system."

The relevant line from top:

  PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND 
 5201 root      20   0 58.1g 3.6g  128 D    2 93.8   1071:27 fsck.jfs

And the result of free -m:

             total       used       free     shared    buffers     cached 
Mem:          3959       3932         26          0          0          6 
-/+ buffers/cache:       3925         33 
Swap:          964        482        482

I have a fresh Lucid Lynx (Ubuntu 10.04) running on a laptop. where I defined the filesystems as:

• mount point / on ext4 (46 Gb)
• mount point /home on jfs (63 GB)
• swap as 3 Gb

I left the machine over night to do some task, without AC power supply. next day in the morning I found it on standby, task completed, but filesystem was not reachable. it gave me I/O error

it seems that there is a problem with jfs and standby.

anyways, to avoid any hassle, I want to move this mount point from jfs format to ext4.

can I do this without losing data and without the need to place the data in a temporary location until transformation is done?

sorry to mention that, but I recall back in the windows days, we would change a FAT16 to FAT32 or a FAT32 to NTFS without having to lose the data. I hope this is available on Linux.

Update The /home filesystem was xfs not jfs, and it seems there is a bug with this filesystem for some reason, I had to re-install the OS twice until I ended up with ext4 for the entire /

However, as a conclusion, it seems that there is no way to make a conversion

After deciding to use LVM2 as volumemanager on our servers there was also the wish for an online resizeable filesystem. After reading a few articles I decided to use JFS in favour of XFS.

Now today I had a power outage on our office server and I discovered that one file on the JFS volume has been completely corrupted. While this might happen the system fooled me into believing everything is alright by not indicating any filesystem problems during the bootup after the power failure. All filesystems were clean after replaying the journal.

This leaves me with a bad taste. I don't want a filesystem which would not recover well after a power outage, but I really don't want a filesystem which doesn't tell me that there might be a problem.

So I thought I give it a shot and ask which filesystem do you prefer? Which one do you favour and why? I'm looking for the following features:

1. robust
2. online growable
3. good performance for usual workloads (normal filesizes - nothing special like millions of small files or such)
4. available in the CentOS 5.4 distribution, but that's optional

I'd also like to know if you have used JFS and have had bad experiences with it - also of course if there're success stories using JFS. And ultimately: would you prefer XFS over JFS or vice versa (as mentioned for everyday use, not for specific workloads)