I have left out two points from the JFS wiki article:
- Changing of virtual memory parameters to optimize file system access.
- Claims of JFS 'losing' files.
The reason that I have not included ways to optimize VM parameters is due to the fact that the JFS port itself has been optimized for the Linux kernel using default values for parameters like /proc/sys/vm/swappiness. Also, changing these parameters can adversely affect certain programs and machines with certain work loads. If people really want to know how to do this type of thing, I'll consider writing up a separate wiki article on that type of optimization for file systems.
As for claims made about JFS loosing files, I have never experienced in the time I've been using JFS; and I am unable to find sources detailing this problem beyond that of hearsay in forum posts. My personal feeling is that these claims of JFS loosing files are probably the result of a badly written script, backup process or careless command execution. Personally, I have had files 'go missing' on me a few times only to realize that I had done something to erase them. This seems far more likely an explanation than JFS just up-and-remove files at random without the file system itself being damaged in some way. If someone does indeed have this problem, send me an email outlining all the details surrounding the lose and I will see about trying to replicate the problem.
I have also seen a claim of JFS 'ruining' an 'expensive' hard drive with very valuable data. This person went on to say how he got a quote that said it would be 30k to recover the data, but that it was too expensive, etc. etc. I don't believe this story. How come this data wasn't backed up if it was so extremely valuable? I have accidentally deleted a JFS partition and I was still able to recover much of the data from that drive using jfsrec. Anyway, I am hoping these claims don't work their way into this JFS article without some proper citations to actual file systems tests whose results can be replicated.
Regarding point two: JFS users needed for testing Feel free to ask me for anything else that I didn't think of when posting that.
Byte, thanks for bringing that to my attention; I have noted the issue in the JFS article. However, as I noted in JFS users needed for testing this may very well be a problem due to the device mapper subsystem or a faulty package install. I was able to replicate the problem only on a system using the device mapper, and the issue was fixed by reinstalling all the packages that used the man3 directory. Anyway, thanks again for posting the details so that the problem could be replicated :).
Shouldn't nodiratime be included with the noatime tip? Admittedly, it doesn't give as much of a performance increase as noatime, but, depending on what you're doing, it CAN still be a substantial enhancement.
Also, what exactly do you mean by "more testers"? People to purposefully crash systems? I have also been using JFS on everything but /boot (and one oddball partition) for a few months now (3 large standalone partitions, and 4 in an LVM), have had a number of crashes, and, to my knowledge, at least, have never lost anything whatsoever.
- --Grndrush 16:06, 25 March 2008 (EDT)
Are we sure link 7 is relevent? According to: http://en.wikipedia.org/wiki/JFS_(file_system) HP-UX has another, different filesystem named JFS that is actually an OEM version of Veritas Software's VxFS. I think link 7 may be refering to the wrong JFS.
Grndrush: enabling noatime also enables nodiratime.
JFS losing files.
I've found some evidence of JFS losing files: https://www.usenix.org/events/usenix05/tech/general/full_papers/prabhakaran/prabhakaran.pdf
Read the section on JFS from page 14 to 15.
- I've reproduced the incident of JFS losing files as described in that pdf, and have edited the wiki accordingly.
- —This unsigned comment is by 1pwl1z8h (talk) 14:54, 1 June 2009. Please sign your posts with ~~~~!
I have experienced much less CPU usage and faster reads with ext4 and the default I/O scheduler, than with JFS and the deadline I/O scheduler. I feel the claim that JFS uses less CPU may be slightly exaggerated, however I am hesitant to edit the Wiki based on my results alone. I have also had some problems with losing files.
I have edited the Wiki to include it's noted slowdown when working with many files, as this is verified by at least two sources, one of which is in the references section. I added one more reference as well.
- I use JFS for years and strongly believe that JFS use much less CPU, especially after long years usage. For SSD disks, the fragmented files are nolonger issue. I have not experienced file lost.
Definitely slower than ext4
The article is a bit misleading. I've been using JFS for a week with the Deadline scheduler and this is definitely slower than ext4 and btrfs even. A lot slower than ext4.
Optimizing the pacman database takes about 3 times longer, resolving dependencies 5, installing the packages may be the same, have not measured it, but feels slower as well. Maybe we should do some proper research on this? Run some real benchmarks on clean systems and discuss them in the forum or elsewhere?
Also I should add that CPU usage remains exactly the same on most operations.