OS/2, eCS & ArcaOS - Technical > Storage

HPFS and JFS internal definition specifications

<< < (3/7) > >>

Dave Yeo:

--- Quote from: Rick C. Hodgin on June 02, 2017, 12:43:53 am ---
--- Quote from: Martin Iturbide on June 02, 2017, 12:24:08 am ---1) HPFS. Even that we have an HPFS file system driver, there is no open source implementation of it. You may get some information of HPFS also at the EDM/2.

--- End quote ---

In initially looking at HPFS it is intriguing. :-)  Documentation shows it is limited to 64 GB as implemented, but 2 TiB is theoretically possible.

It would be exciting. :-)

Thank you,
Rick C. Hodgin

--- End quote ---

Draw backs of HPFS, long chkdsk time, hate to think how long a chdsk /f:3 on a 2TiB partition would take :) Lack of large file support, the 2GiB file size limit is a problem. It is possible to work around this with the DEADBEEF flag, which changes seeking from per byte to per sector with caller having to manage things.
I don't know much else about the structures.

RickCHodgin:

--- Quote from: Dave Yeo on June 02, 2017, 02:31:08 am ---Draw backs of HPFS, long chkdsk time, hate to think how long a chdsk /f:3 on a 2TiB partition would take :) Lack of large file support, the 2GiB file size limit is a problem. It is possible to work around this with the DEADBEEF flag, which changes seeking from per byte to per sector with caller having to manage things.
I don't know much else about the structures.

--- End quote ---

I've been reading about this tonight.  It looks like large file support could be overcome, as the theoretical maximum is over 7+GB as is.  That 7+GB limitation could be defeated with a tweak it could be extended out as far as is needed.

It seems the only true limit right now to very large files in HPFS is in the legacy API, which only receives 32-bit value for file-related offsets.  That could also be defeated with our own open source kernel and new API which supports 64-bit file operations.

-----
If I had money, I would devote a team of developers to creating our own open source OS/2 clone from the ground up, kind of like what Mark Shuttleworth did with Ubuntu Linux, although he still built atop the community base, and ours would be a full ground-up replacement effort, but I would be supporting the full legacy OS/2 API so all of our code could be compiled on existing OS/2 code bases for testing, and would also compile on the new OS/2.

Ah to dream...

Thank you,
Rick C. Hodgin

Martin Iturbide:
Hi

I restored the original fig5 and fig6 from the original source on the HPFS article. I don't what if the optimized images got list or maybe never was finished. I will check on that.

Regards

RickCHodgin:

--- Quote from: Martin Iturbide on June 02, 2017, 02:03:06 pm ---I restored the original fig5 and fig6 from the original source on the HPFS article. I don't what if the optimized images got list or maybe never was finished. I will check on that.

--- End quote ---

Excellent.  Now that I see what they are, I'll go ahead and create some new optimized images and you can update them when completed.

Do you have an original source document for fig6?  It may be hard for me to decipher.

Thank you,
Rick C. Hodgin

Lars:
There already exists a "large file" API and there also exists additional entry points and extensions for existing entry points for file system drivers to support these new APIs.
These APIs will use 64-bit signed values to deal with file size and seek offsets.

The only problem is that the current HPFS.IFS was written at a point in time where these additional entry points where not yet defined.
If these additional entry Points were added to the existing HPFS.IFS then it would not be necessary to use the "DEADBEEF hack" and read in units of sectors instead of bytes.

As an example, there is an effort currently going on to add these additional "large file" entry points to the existing FAT32.IFS.
That will finally allow to deal with files up to 2^63 Bytes and likewise will allow byte granular accesses/seeks across disks up to a size of 2^63 bytes.


Lars



--- Quote from: Rick C. Hodgin on June 02, 2017, 02:37:12 am ---
--- Quote from: Dave Yeo on June 02, 2017, 02:31:08 am ---Draw backs of HPFS, long chkdsk time, hate to think how long a chdsk /f:3 on a 2TiB partition would take :) Lack of large file support, the 2GiB file size limit is a problem. It is possible to work around this with the DEADBEEF flag, which changes seeking from per byte to per sector with caller having to manage things.
I don't know much else about the structures.

--- End quote ---

I've been reading about this tonight.  It looks like large file support could be overcome, as the theoretical maximum is over 7+GB as is.  That 7+GB limitation could be defeated with a tweak it could be extended out as far as is needed.

It seems the only true limit right now to very large files in HPFS is in the legacy API, which only receives 32-bit value for file-related offsets.  That could also be defeated with our own open source kernel and new API which supports 64-bit file operations.

-----
If I had money, I would devote a team of developers to creating our own open source OS/2 clone from the ground up, kind of like what Mark Shuttleworth did with Ubuntu Linux, although he still built atop the community base, and ours would be a full ground-up replacement effort, but I would be supporting the full legacy OS/2 API so all of our code could be compiled on existing OS/2 code bases for testing, and would also compile on the new OS/2.

Ah to dream...

Thank you,
Rick C. Hodgin

--- End quote ---

Navigation

[0] Message Index

[#] Next page

[*] Previous page

Go to full version