• Welcome to OS2World OLD-STATIC-BACKUP Forum.
 

News:

This is an old OS2World backup forum for reference only. IT IS READ ONLY!!!

If you need help with OS/2 - eComStation visit http://www.os2world.com/forum

Main Menu

hpfs vs. jfs for minimalist user

Started by steve b, 2010.06.22, 04:36:04

Previous topic - Next topic

steve b

I've done several testing installs of eCS 2.0GA and was getting ready to do a 'backup' install on a 30Gb HDD, and then my 'everyday workhorse' install on my 8Gb SSD (SLC). When I started testing rc4, I used JFS, and found that it took a very long time to  boot. Couldn't tell any difference in performance for normal usage. Subsequently went back to hpfs. On paper for users that spend a good portion of their day on a computer, jfs appears the best choice, and I just learned that hpfs is 16 bit, so I'm torn. When I'm not trying to migrate an OS and break in a new computer, I usually use a  computer less than 2 hours a day, usually in 3 or more sessions (3 or more shutdowns). I doubt I ever will fill my 8Gb SSD. I'm using a T43. Any thoughts or observations from personal experience?

Oh, yes, I think 2.0GA is fabulous. The easiest install I've ever had.

Saijin_Naib

I'll say this for JFS on mobile devices:
Its error check/recovery process is both faster than HPFS and more robust.

I used to use HPFS on my laptop but when I would run out of battery and have a dirty shutdown, it would eventually end up killing the filesystem. No such problem with JFS yet. For this reason, I also use JFS on my Linux Netbook as ext4 and XFS are highly prone to corruption.

Radek

IMO, it depends on the partition size. HPFS is a very good choice on small partitions (8 GB is a small partition) but it is terribly slow on bigger ones. Yes, it's a 16-bit code but it isn't essential from the user's point of view. There also exist HPFS386, which is 32-bit assembler optimized code but it is (was) also paid and licensed. Well, you can try google ... well, search a zip which is about 500 kB big. Sorry, I cannot tell more :D

HPFS has a limit 64 GB. Also, HPFS does not seem to be a good choice for VirtualBox. For not so small partitions, for partitions bigger than 64 GB and in VirtualBox use JFS.

rwklein

Quote from: Radek on 2010.06.22, 11:35:28
IMO, it depends on the partition size. HPFS is a very good choice on small partitions (8 GB is a small partition) but it is terribly slow on bigger ones. Yes, it's a 16-bit code but it isn't essential from the user's point of view. There also exist HPFS386, which is 32-bit assembler optimized code but it is (was) also paid and licensed. Well, you can try google ... well, search a zip which is about 500 kB big. Sorry, I cannot tell more :D

HPFS has a limit 64 GB. Also, HPFS does not seem to be a good choice for VirtualBox. For not so small partitions, for partitions bigger than 64 GB and in VirtualBox use JFS.

Also be aware that pushing HPFS volumes up to 60 GB for example is sometimes asking for trouble. ecomstation.com (about 6 years ago) would run on HFPS volumes. One was about 20 GB and it would run into CHKDSK troubles because the volume contained so much data. JFS is much better for bigger volumes.

Also just as an additional warning :-)

Roderick Klein
Mensys

steve b

So, is the only downside for JFS on a small volume is that it takes a lot longer to boot? Would you use JFS on a 8Gb SSD? I understand its superiority on larger volumes, and necessity over 64Gb. Since I do frequent shutdowns on small volumes it seemed more trouble than it was worth. Thanks for your input.

Radek

I would not most likely. Try and you will see. I always have a system partition where I have only the operating system and "system wide" utilities, the partition has 2 GB (more than enough) and it is always HPFS. Along with the system partition, I have data partitions which are much bigger and they are JFS.

HPFS seems to be more stable to me. I have seen faults with JFS but none with HPFS since my first Warp 3. Because I always boot from HPFS, I cannot compare booting speed of HPFS and JFS. Also, I haven't seen any difference in speed between my HPFS and JFS partititons after booting.

Pete

Hi steve b

I use BootableJFS on a 2Gb volume (hard disk) and it seems to be quicker to boot than HPFS. I must admit that I have not timed this - and it could be system dependant.

No idea what the boot speed would be on an SSD but I would expect it to be quicker than hard disk.

Regards

Pete

DougB

QuoteSo, is the only downside for JFS on a small volume is that it takes a lot longer to boot?

I don't know why you would see that. Every system I have boots MUCH faster when I use JFS. I have completely abandoned HPFS for many reasons, and one of them is the boot time. I use boot volumes from about 1 GiB to 2 GiB (no point in going any larger for a boot volume), but I have settled on using about 1.5 GiB.

The other main reason why I have abandoned HPFS is that there is almost always some data loss (usually log files, but sometimes more serious things) when the system finds it necessary to run CHKDSK at boot time. With JFS I haven't had that happen yet. CHKDSK, when it is necessary, takes less time with JFS than with HPFS (assuming same size volumes), unless it does find something that needs to be fixed (very rare), then it may take a little longer.

Overall, my experience has been that the bootable JFS that is included with eCS 2.0, is far better than HPFS, or the JFS that IBM produced. If you are seeing something different, there is probably a reason that should be investigated.

ivan

The only thing I have to add to this debate is, make sure you have a good backup of any JFS drive, because if anything goes wrong there is no way, that I can find, of reliably recovering anything.

RobertM

#9
Here's some of the technical and non-technical information you may wish to consider in making your choice:

(1) HPFS is limited to a 2MB cache (or less) - while ok for caching certain OS related things (the INI files and such), it's not very useful or helpful for the apps that could sorely use the speed improvement from having code cached (Firefox, OOo, etc - which are recommended to be run from a JFS volume and not HPFS).

(2) HPFS and HPFS386 are limited to 64GB partitions (with HPFS (NOT HPFS386) getting less stable on partitions over 55-60GB, especially with lots of files on them. With HPFS386, it will allocate what memory is needed to perform a checkdisk, even on large partitions with MILLIONS of files (may take 30 minutes or more), and then reboot the machine when done. HPFS does not do that, and may run out of memory during checkdisks of large volumes that contain lots of files, seriously damaging your file system.

(3) HPFS386 can have a cache size only limited by "available memory" - this statement is outdated, but the claim for HPFS386. I would not exceed 200MB caches with HPFS386 - it will eat away a big chunk of your system memory arena and cause out of resource errors.

(4) HPFS and HPFS386 are more efficient at cluster usage (512 bytes - not the 4096 JFS uses), which will save space on systems with lots of files (up to almost 4K worst case scenario - per file).

(5) HPFS386 is Ring 0 code (HPFS is not) and is much faster than HPFS, both due to larger cache values and the optimized 32bit assembly code and it running in Ring 0 with "links" to various things that utilize the file system

(6) HPFS and HPFS386 barely fragment. By barely, I mean fragmentation is usually so little that it isnt worth defragging an HPFS/HPFS386 partition.

(7) JFS can have larger cache values configured than HPFS or even HPFS386 as it can use the upper memory block - this though also has it's limitations, as it is dependent on the VIRTUALADDRESSLIMIT statement, and can affect memory availability in the UMB.

(8 ) JFS is a little faster than HPFS386 as it does not have the added overhead of trying to ensure no fragmentation. This can especially come in handy when writing files of unknown size to a disk with lots of other files on there (for instance, transcoding a video where the app thus doesnt know what the final video size is, or writing a server log file, where once again the app cannot report what size the file is it is writing). This is due to the fact that JFS will just keep finding places to write things, with little care about fragmentation, while HPFS will not, and tries to find the best place to write things.

(9) JFS is a LOT faster than plain HPFS - for virtually anything.

(10) Though HPFS386 is very fast, it is slower to boot from. Loading the HPFS386 driver also runs a few consistency checks on the drives and sets up the various heap and cache spaces. That adds a boot delay - one that increases per each HPFS386 partition/volume that needs to be "enabled"

(11) (This is one of the most important ones to me - along with 7) HPFS and HPFS386 have a 2GB file size limit. They will stop writing any file at the 2GB marker or return an error on an attempt to write a file greater than 2GB (depends on whether the file system knows the filesize before it starts writing). That means full (or greater than roughly half full) DVD ISOs, large video files, and so on, cannot be written to any HPFS variant on OS/2.

(12) ChkDsk times are best on JFS (by a long shot) except in the case of catastrophic problems, in which case HPFS386 isnt too far behind (this may vary depending on the speed of the machine and the available memory - but has been my experience on my machines).

(13) I have yet to find anyone who can recommend a defrag utility for JFS (at least, not one that wont potentially hose the JFS volume). HPFS386 remains relatively consistent in speed as long as it has some free space to figure out where things should go on the disk (ie: trying not to fragment things), while JFS will slow down over time like any other FS that fragments.

(14) In my personal experience, I have found HPFS386 to be a little less crash prone than the latest JFS. Make sure you are running the latest JFS - some of the older versions of JFS could fail quite spectacularly.

Anyway, those are the things I have noticed or learned over the years.


|
|
Kirk's 5 Year Mission Continues at:
Star Trek New Voyages
|
|


steve b

Well, I have spent a good part of the day repeatedly reloading eCS after trying to delete mainly the Templates folder with Unimaint and Black Hole on a jfs volume, as well as some registry experimenting. Unimaint worked better on the hpfs volumes. For some reason it fails to be able to do OS2*.ini repair on a jfs volume.

I must have done something wrong on my 1st install of eCS rc4 on a jfs volume, because 2.0 boots as fast if not faster than on a hpfs volume. It takes barely any longer than XP to boot. It should scream on the SSD. I appreciate your input anyway, because as soon as I could see that jfs was going to be very usable from a booting concern, I remembered that it fragments. That concerns me on a small SSD such as I have. Steve

Saijin_Naib

If you want your SSD to "scream", make sure you have that partition/filesystem aligned to a block size that is compatible with your SSD's controller.

In other words, don't have it overlap blocks because you not only flog the controller, you also double-write and decrease the life expectancy of the SSD greatly.

DFSEE can do this, I talked with Jan about it, you have to use the "geo" command. I've not been able to do it successfully however (no problem with the tool, just not familiar enough with the commands and syntax to accomplish what I want). Jan said he is looking into making a "Gui" front-end for DFSEE in the coming time to facilitate tasks like this.

The eCS Installer should do this by default. I'm rather miffed that at this point in time, with the benefits of aligned partitions being known [most especially for SSDs], it does not yet do it. At least it isn't alone, I think OSX still doesn't do it by default though WinNT 6.0 and above and Linux both do now.