Difference between revisions of "Talk:JFS"

From ArchWiki
Jump to: navigation, search
(use https for links to archlinux.org)
m (add heading. These discussions are really old, are any of them still relevant?)
 
(11 intermediate revisions by 4 users not shown)
Line 1: Line 1:
 +
== Initial draft ==
 +
 
I have left out two points from the JFS wiki article:
 
I have left out two points from the JFS wiki article:
  
Line 29: Line 31:
  
 
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.
 
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.
 +
 +
{{Unsigned|Revision as of 18:52, 21 May 2009|Wyxj69vm}}
  
 
== nodiratime ==
 
== nodiratime ==
  
 
Grndrush: enabling noatime also enables nodiratime.
 
Grndrush: enabling noatime also enables nodiratime.
 +
 +
{{Unsigned|18:56, 21 May 2009|Wyxj69vm}}
  
 
== JFS losing files. ==
 
== JFS losing files. ==
Line 40: Line 46:
 
Read the section on JFS from page 14 to 15.
 
Read the section on JFS from page 14 to 15.
  
== JFS losing files. ==
+
{{Unsigned|11:53, 22 May 2009|Wyxj69vm}}
  
I've reproduced the incident of JFS losing files as described in that pdf, and have edited the wiki accordingly.
+
:I've reproduced the incident of JFS losing files as described in that pdf, and have edited the wiki accordingly.
 +
:{{Unsigned|14:54, 1 June 2009|1pwl1z8h}}
  
 
== CPU Usage ==
 
== CPU Usage ==
Line 49: Line 56:
  
 
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 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.
 +
 +
{{Unsigned|01:28, 14 April 2011|Lupusarcanus}}
 +
 +
: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.
 +
 +
:[[User:Triplc|Triplc]] ([[User talk:Triplc|talk]]) 04:33, 18 October 2017 (UTC)
 +
 +
== 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.
 +
 +
{{Unsigned|Revision as of 07:19, 29 April 2018|CarterCox}}

Latest revision as of 08:57, 29 April 2018

Initial draft

I have left out two points from the JFS wiki article:

  1. Changing of virtual memory parameters to optimize file system access.
  2. 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.

--PDExperiment626

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

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 :).

--PDExperiment626

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)

Link 7

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.

—This unsigned comment is by Wyxj69vm (talk) Revision as of 18:52, 21 May 2009. Please sign your posts with ~~~~!

nodiratime

Grndrush: enabling noatime also enables nodiratime.

—This unsigned comment is by Wyxj69vm (talk) 18:56, 21 May 2009. Please sign your posts with ~~~~!

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.

—This unsigned comment is by Wyxj69vm (talk) 11:53, 22 May 2009. Please sign your posts with ~~~~!

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 ~~~~!

CPU Usage

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.

—This unsigned comment is by Lupusarcanus (talk) 01:28, 14 April 2011. Please sign your posts with ~~~~!

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.
Triplc (talk) 04:33, 18 October 2017 (UTC)

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.

—This unsigned comment is by CarterCox (talk) Revision as of 07:19, 29 April 2018. Please sign your posts with ~~~~!