Last week I installed Ubuntu Linux 8.04 in my machine, in the place of the old Debian Etch.
Since Ubuntu gave me the option, I formated Linux partitions as JFS.
When I restarted OS/2 (Warp 4.52, release 2) I launched Logical Volume Manager and
found out that the Linux formated partitions are presented just as "Linux" and filesystem
unknown. I was able to select a drive letter for them, but OS/2 cannot read those drives.
It is the other way around, i.e., you create the JFS partitions (or volumes) with OS/2's LVM and and mount them under your GNU/Linux operating system (for data backup/recovery, for example).
I noticed that every Linux partition is maked as "Type 83". Should I modify it's number to
type 35? Or should I reformat those partitions with OS/2 and tell Linux to not touch their
partition structure?
You could modify the partition's file system type to (unknown) 35 and still OS/2 will likely not be able to read its data --even if it can assign a drive letter to the partition. Further, attempting a (JFS) file system check on the partition with the OS/2 appropriate JFS utility inside an OS/2 command prompt window:
[WSeB]:/: jfschk32 n: /f
(where n is the drive letter assigned by OS/2 to your GNU/Linux JFS formatted partition)
will spit out the following complaint:
JFS0068: CHKDSK Superblock is corrupt and cannot be repaired because both
primary and secondary copies are corrupt. CHKDSK CANNOT CONTINUE.
On the other hand, under Ubuntu (based on Debian) all you have to do is specify the partition's* file system type (if at all) when you mount it on a given Ubuntu directory. For instance, assuming that you are the root user under Ubuntu (type
sudo passwd root and provide an new root or super user password; subsequently type
su root and provide your newly created root password) and assuming that you have an directory mount point under /mnt/sdax
...when we specify the type (-t) as jfs:
Huitzilopochtli:/home/jose# mount -t jfs /dev/sdax /mnt/sdax
Huitzilopochtli:/home/jose#
...and the partition is mounted and can be accessed at /mnt/sdax
(see
relevant past thread link)
Note that once you (re)format the partition under OS/2 with JFS, you can write and copy data (to and from, respectively) from within your GNU/Linux environment.
Also, anyone has any experience on mounting OS/2 JFS partitions on Linux? I was
not able to mount them on Linux either.
The information is provided
AS-IS. I am using GNU/Linux Debian unstable on a daily basis and mount and umount OS/2-Linux JFS formatted partitions regularly. And, of course, I copy and put data into those volumes as the need arises. Two idiosyncracies that you may want to be aware of are:
- Files that you copy from OS/2 JFS formatted volumes onto you GNU/Linux file system will have all attributes null. Accordingly, in order for those to be readable the root user should modify those attributes accordingly. For instance, use chmod a+r <file from OS/2's LVM> to have the regular user accounts be able to read the file copied from the OS/2's LVM JFS volume. IF you copy a whole directory structure over onto your Ubuntu file system, then use the -R switch for recursive setting of read property to all the directory and files under it as: chmod -R a+r <directory from OS/2's LVM>. etc., etc.
- As the super user or root in your Ubuntu, you can access all files in OS/2 LVM JFS formatted volumes. Notwithstanding, an regular user will possibly be denied access to those partitions.
After all, Linux JFS and OS/2 JFS are compatible or not?

...not exactly. As you can see when attempting an file system check on an GNU/Linux JFS formatted partition.
[...]
* GNU/Linux apparently does not have the volume concept of OS/2's LVM, hence OS/2 volumes are seen as partitions on the hard disk. Evidently, it follows logically that OS/2's LVM volumes spanned across multiple physical hard disks and/or partitions will not be able to be accessed by
enabled GNU/Linux JFS utilities.
Addendum: Note what happens on an OS/2 LVM JFS formatted volume/partition when its file system is checked with the Debian GNU/Linux utility
jfs_fsck operating on an
unmounted partition/volume in read or reporting only mode (as specified by the switch -n):
Huitzilopochtli:/home/jose# jfs_fsck -n /dev/hdax
jfs_fsck version 1.1.12, 24-Aug-2007
processing started: 9/2/2008 0.55.58
The current device is: /dev/hdax
Block size in bytes: 4096
Filesystem size in blocks: 769104
**Phase 1 - Check Blocks, Files/Directories, and Directory Entries
**Phase 2 - Count links
**Phase 3 - Duplicate Block Rescan and Directory Connectedness
**Phase 4 - Report Problems
**Phase 5 - Check Connectivity
**Phase 6 - Perform Approved Corrections
**Phase 7 - Verify File/Directory Allocation Maps
**Phase 8 - Verify Disk Allocation Maps
3076416 kilobytes total disk space.
731 kilobytes in 550 directories.
1932542 kilobytes in 2757 user files.
0 kilobytes in extended attributes
15337 kilobytes reserved for system use.
1129268 kilobytes are available for use.
File system checked READ ONLY.
Filesystem is clean.
That is, it checks and reports on an OS/2 LVM JFS formatted partition/volume --something that the OS/2 equivalent utility could not do (as illustrated priorly) on an Debian JFS formatted partition. Keep in mind that this partition is relatively small (around 3GB) and that your "mileage" may vary on larger partitions.
Keep in mind, also, that whereas the above was a passive operation, to actually fix the OS/2 LVM JFS formatted partition under GNU/Linux, you must make sure that,
- The partition is unmounted --very important!
- (adapted from the man jfs_fsck: Check the xrd partition on the 1st hard disk, print extended information to stdout, replay the transaction log, force complete jfs_fsck checking, and give permission to repair all errors:
jfs_fsck -v -f /dev/hdax
Huitzilopochtli:/home/jose# jfs_fsck -v -f /dev/hdax
jfs_fsck version 1.1.12, 24-Aug-2007
processing started: 9/2/2008 1.17.33
The current device is: /dev/hdax
Open(...READ/WRITE EXCLUSIVE...) returned rc = 0
Primary superblock is valid.
The type of file system for the device is JFS.
Block size in bytes: 4096
Filesystem size in blocks: 769104
**Phase 0 - Replay Journal Log
LOGREDO: Log already redone!
logredo returned rc = 0
**Phase 1 - Check Blocks, Files/Directories, and Directory Entries
**Phase 2 - Count links
**Phase 3 - Duplicate Block Rescan and Directory Connectedness
**Phase 4 - Report Problems
**Phase 5 - Check Connectivity
**Phase 6 - Perform Approved Corrections
**Phase 7 - Rebuild File/Directory Allocation Maps
**Phase 8 - Rebuild Disk Allocation Maps
Filesystem Summary:
Blocks in use for inodes: 588
Inode count: 4704
File count: 2757
Directory count: 550
Block count: 769104
Free block count: 282317
3076416 kilobytes total disk space.
731 kilobytes in 550 directories.
1932542 kilobytes in 2757 user files.
0 kilobytes in extended attributes
0 kilobytes in access control lists
15337 kilobytes reserved for system use.
1129268 kilobytes are available for use.
Filesystem is clean.
All observed inconsistencies have been repaired.
Filesystem has been marked clean.
**** Filesystem was modified. ****
processing terminated: 9/2/2008 1:17:35 with return code: 0 exit code: 0.
Huitzilopochtli:/home/jose#
Accordingly, quite likely you will be able to recover your data on an unclean OS/2 LVM JFS partition. The example above was performed on an
clean OS/2 LVM JFS formated partition/volume; hence, my use of the option
-f to force the check and corrections on the file system. Sorry, I have not had the opportunity to actually have an dirty JFS partition as of late.
Well, assume that (after the correction operations by the GNU/Linux
jfs_fsck utilitiy) your OS/2 can not read the volume/partition; all you have to do is to either bring over the data to your GNU/Linux side with
tar (for instance) into an archive, reformat your partition/volume with OS/2 LVM JFS utility and subsequently put the archived data back into the OS/2 LVM JFS formatted partition.
Or you could create with your OS/2 another LVM JFS partition, format it, and subsequently reboot to your GNU/Linux and rewrite your data.
Notwithstanding, your OS/2 LVM JFS formatted partition,
jfs_fscked under GNU/Linux JFS utility will be accessible from within your OS/2 environment --as I have verified in my limited testing. In summary checking (and fixing) an OS/2 LVM JFS formatted partition with appropriately
enabled GNU/Linux JFS utilities retains compatibility with OS/2 later accessing those partitions --as initially hinted during the OS/2 boot procedure when the OS/2 LVM check is done and printed to the screen. The opposite is not true, i.e., OS/2 can not access GNU/Linux JFS formatted partitions --much less operate on them with
jfschk32 to attempt to repair an damaged file system.
WARNING:
Again, the information is provided
AS-IS --based on my limited testing. Should anyone desire to use it, s/he, it (if Fido uses OS/2

), or them, do so at her, his, its, or their, own risk.
Regarding the
The use of the term
enabled is because not all GNU/Linux distributions,
out of the box, are capable of reading/writing JFS partitions --much less mounting them. Those that I know that have the desired feature out-of-the-box are GNU/Linux Debian and some (all?) derivatives like Ubuntu, and Novell's SuSE up to at least 10.3 both --OpenSuSE and SLES/SLED.
The OS/2 that DC is referring to does not appear to be bootable JFS. As mentioned in another (possibly quite old) thread, and if I recall correctly the name of the OS/2 file being
OS2BOOT, I will venture forward the following:
The common denominator file that actually changes(its internal structure) when formatting an bootable OS/2 file system, such as FAT versus HPFS (have not tried 386hpfs) is the OS2BOOT. That is, all other files in an pristine OS/2 installations remain the same --except the OS2BOOT. Although those two file systems structure might be different, the only file that needs to be changed to accommodate those differences is the OS2BOOT file.
The change can be effectuated by the formally indicated way of typing:
SYSINSTX Y:
to modify the OS2BOOT. Or it could be done by overwriting the OS2BOOT file with an equivalent in the desired file system.
If we use the above analogy and apply it to the so called bootable JFS, OS2BOOT would be the only file that I would expect to be added and/or different. Again, I would expect the rest of the file system structure to remain the same. And I would see no reason to not be able to mount an OS/2 bootable JFS volume under an GNU/Linux JFS enabled system. But of course, the experiment will have to delayed (likely indefinitely) and done when --and if-- the OS/2 strategy changes course, at least from my perspective.