WebSite Information > Article Discussions

Large Floppy Support Discussion - USBMSD.ADD

<< < (2/3) > >>

Dave Yeo:

--- Quote from: Doug Bissett on November 27, 2017, 05:44:28 am ---[There has been some discussion about porting the EXT file system to OS/2. I don't know much about that, so I won't comment, but word is that it is much like JFS. I also don't know much about HPFS386, but I suspect that JFS is more than a suitable replacement.

--- End quote ---

Ext2 has already been ported to OS/2. Problems include no LVM support and I understand people looked into adding it and failed. No EAs (xttrs), at least back then. Case sensitive file system, seems OS/2 actually upper cases most stuff when writing to a file system. The porter added a switch to make it case insensitive to allow running OS/2 on it, and yes, he wrote the mini and micro filesystems to make it bootable. And it was old, kernel 1.3 IIRC and Linux likes to change things.
I used to format my Linux partitions on OS/2 to have access to the Linux disks.
It would be nice if our JFS was once again compatible with the Linux JFS. Would be nice to port the Linux JFS to OS/2 as it has had more love over the years and supports links, both hard and soft as well as *nix permissions.
According to wiki, JFS is perhaps the best general purpose all around file system for Linux.

Valery Sedletski:

--- Quote from: Doug Bissett on November 27, 2017, 05:44:28 am ---
--- Quote ---Actually the most important problem WAS and IS solved.
--- End quote ---

The problem exists because the FAT32 support is not properly written (probably not designed properly, in the first place). Some improvements have been made recently, but it is still not a proper file system, therefore it needs some special handling to make it work. No other (supported) file system needs help to make it work with USB.

--- End quote ---

What do you mean? Not designed properly? Is still not a proper file system? What special handling does it need?

Large floppy support does nothing with FAT32 specifically. As Lars correctly said, the problem is with OS2DASD.DMD, which thinks that Large floppies are FAT, but not IFS case. So, without Lars' workaround in USBMSD.ADD, the OS2DASD.DMD assigns a drive letter to it, and then the kernel calls MOUNT routine of in-kernel FAT driver, not any IFS-es. So, the proper Large Floppy support requires OS2DASD.DMD (and maybe, kernel too) rewrite. It is significantly harder. FAT32.IFS does not require anything special, compared to JFS or HPFS.


--- Quote ---
--- Quote ---And I can not recommend to use JFS in conjunction with non-removable USB MSD under OS/2 for production level at the current state.
--- End quote ---

That is flat out ridiculous. The current JFS is, IMO, the most reliable OS/2 file system to use with any device (removable, or not), that can use it. I find it far more reliable than HPFS ever was, and the performance is a whole level higher (especially with removable media). Personally, I would never use anything else, if there was no need to be compatible with other operating systems.

Having said that, I do use HPFS with the ARcaOS, or QSINIT, RAMDISK.  The reason is that the RAMDISK can be created with HPFS format, and I can turn the cache size down to minimum (64 KB), which helps performance (it would be better if it was zero, but that is not allowed by HPFS).

--- End quote ---

You can also use the "/1" switch for hd4disk.add, to improve performance. It disables the strat2 routine, which simplifies things in ramdisk case, so it improves performance about 5 times.


--- Quote --- I also use FAT32, to be able to interface with windows, which is still a necessary evil. I do turn off EA support to avoid problems caused because the FAT32 file system, in windows, does not know about them, and it causes nothing but problems, for very little gain.

--- End quote ---

I don't aware of any problems which are caused by EA support, except for EA files laying around everywhere. But this can be fixed in the future, as I plan to implement the "classic" EA support with "ea data. sf" file. Also, it should be noted that, with EA support, it is possible to store files, bigger than 4 GB, on the FAT32 volume, to transfer them between OS/2 systems. Indeed, support of big files up to 32 GB is possible without EA's, but bigger files require the EA support. The 64-bit file size is stored in three extra bits (previously, the reserved ones) of a directory entry. If it does not fit into 32+3 == 35 bits, the full 64-bit size is stored in the FAT_PLUS_FSZ EA. This feature could be enabled with  "/plus" switch. This feature is called FAT+ and it is suggested by DR-DOS developers. Also, copying files with EA's, including the desktop from the OS/2 boot partition, works fine. I saw no problems with it.


--- Quote --- FAT (12 and 16) still has some limited use, but I try to avoid them, except for special things. The new addition of ExFAT support to the FAT32 driver, is interesting, but I don't know how useful that will be in the long run. I do know that there are serious questions about the legality of doing that, which is the reason why Arca Noae.removes that feature from the FAT32 driver that they distribute.

--- End quote ---

FAT12/FAT16 have very frequent use -- floppies, flash sticks < 2 GB, some old mp3 players, which could not support FAT32, SADUMP partitions (I also discovered that 4 GB FAT16 partitions, with 64 KB clusters, are supported by FAT os2dump, and it could be read with FAT32.IFS, so, such partitions could be used instead of DUMPFS. Read more in fat32.inf documentation on this topic). Regarding the legality of exFAT support, it is legal. In some countries, like USA, there are software patents. So companies like Arca Noae, should pay licensee fees to M$. Arca does not like this, so they don't want to include exFAT support in their distributions. I made a version without exFAT (#ifdef-ed from sources, but they want sources completely without exFAT. (and without FAT12/FAT16 too, but this is ridiculous, because it hurts nothing, and it is nonsense.) Also, they don't want to sponsor my developments, but want to include new version with FORMAT/autocheck/other features, without paying me, so I'll suspend implementing their wishes, for the time being.). Software patents are not valid in my country (Russia), and also it is implemented in many free opensource programs, like FUSE exFAT plugin in Linux, FatFS (which is the library QSINIT FAT support is based on). So far, there was no M$ claims about these projects. As I understand, they only sue commercial projects. Free projects have nothing to get from. You can freely use exFAT support for your own needs. It is Arca has problems with using it, not you or me. (But I made a version without exFAT, they are not satisfied with it, and not even thanked me for making it).


--- Quote --- There has been some discussion about porting the EXT file system to OS/2. I don't know much about that, so I won't comment, but word is that it is much like JFS. I also don't know much about HPFS386, but I suspect that JFS is more than a suitable replacement.

--- End quote ---

JFS was developed earlier than IBM/Exigen USB stack, so they did not recommend to use it on removable media. I successfully use JFS with my USB hard drive for a long time. I've seen no problems with it. The only thing you need is to explicitly eject the volume before removal. But thic is the case with any file system. Also, JFS is journalled file system, so it is not recommended to be used on flash sticks, because of quick wearing-out of log area. So, it is better to use FAT32 or HPFS with flash sticks (or any other non-journalled FS)

Valery Sedletski:

--- Quote from: Dave Yeo on November 27, 2017, 08:44:12 am ---
--- Quote from: Doug Bissett on November 27, 2017, 05:44:28 am ---[There has been some discussion about porting the EXT file system to OS/2. I don't know much about that, so I won't comment, but word is that it is much like JFS. I also don't know much about HPFS386, but I suspect that JFS is more than a suitable replacement.

--- End quote ---


--- Quote ---Ext2 has already been ported to OS/2. Problems include no LVM support and I understand people looked into adding it and failed.

--- End quote ---

--- End quote ---

it supports only very old ex2fs version, and does not mount newer ones. Yes, there are some problems with LVM. It works fine with danidasd.dmd. I don't know, where are incompatibilities with LVM. Probably, it is not ext2-os2.ifs itself is incompatible with LVM, but it is mwdd32.sys driver, which it is based on. Need to look at it better. Possibly, we'll just need to update mwdd32.sys.


--- Quote ---No EAs (xttrs), at least back then. Case sensitive file system, seems OS/2 actually upper cases most stuff when writing to a file system. The porter added a switch to make it case insensitive to allow running OS/2 on it, and yes, he wrote the mini and micro filesystems to make it bootable. And it was old, kernel 1.3 IIRC and Linux likes to change things.
I used to format my Linux partitions on OS/2 to have access to the Linux disks.

--- End quote ---

You need to reformat the filesystem with special switch, changing its revision.


--- Quote ---It would be nice if our JFS was once again compatible with the Linux JFS. Would be nice to port the Linux JFS to OS/2 as it has had more love over the years and supports links, both hard and soft as well as *nix permissions.
According to wiki, JFS is perhaps the best general purpose all around file system for Linux.

--- End quote ---

Our JFS is compatible with Linux. Linux sees OS/2 JFS partitions fine. And OS/2 can mount Linux JFS partitions, if you format them with -O (case insensitivity) option. OS/2 supports only FS'es, formatted as case-insensitive. Also, it requires BPB to be present in the boot sector. Linux JFS is case sensitive by default, and it has no BPB. But you can format it with the -O option and create the BPB with DFSee. There is Linux JFS ported to OS/2 already. It is OpenJFS project which is available from Netlabs. But Netlabs sources are a bit outdated. There are two versions at Netlabs svn, from 2003 and 2007. The IFS mostly works. The missing part is UJFS.DLL. But it could be created from fcsk/mkfs, which are present. Hard links should work in OS/2, like they do in ext2-os2.ifs. You only need a user mode utility to create them. For soft links, the kernel support is required, which is missing in OS/2. UNIX permissions require kernel support too. But I fear that permissions overlap with some OS/2-specific data in inode structure.

Valery Sedletski:
2Lars:


--- Quote ---b) In the year 2017 it only makes sense to support systems with LVM. It's too late to make USBMSD.ADD compatible to an OS of the year 1996. There would be too many limitations.

--- End quote ---

Danidasd.dmd is still quite usable. I use it in my Universal Boot Disk (a Live OS/2 system, capable of booting from ATA or USB CD's/USB flash sticks/USB hard drives/ATA hard drives/etc), to boot from USB sticks or hard drives. LVM is not usable in this case. Also, there are cases where the use of LVM is impossible. For example, I used to update Warp 3 to a newer fixpack at one plant, to allow them to use flash sticks, instead of floppies. The plant has a Warp 3 PC, which controls a glass-cutting bench. The people from that plant contacted me at a freelance site. They were not ready to update software to latest eCS system. So, if USB stack can work on such system, why not? So, it is desirable to support such systems, if we can. In fat32.ifs, I support Warp 3/Merlin systems, because 16-bit IFS should support them. No need to artificially limit it to the latest systems only. Nothing prevents the USB stack to work on such systems, too. And, some people use older systems in VM's. So it is better to support such systems too.

Also, regarding FAT/FAT32 only on big floppies. I think, that nothing prevents USBMSD.ADD to support Big floppies with any file system. Indeed, there can be Big Floppies, created by Linux, with ext2fs, or any other file systems. Nothing prevents me to create the Big Floppy with HPFS/JFS too. Indeed, creating partition table is not hard, but if you have flash sticks from other people, then reformatting/repartitioning is undesirable. The stick could be created by Linux, and not Windows.

As I understand, you check for the FS name field after the BPB, and if it is FAT, then you emulate a zero track with MBR and DLAT. But you can check for three first bytes instead, to be EB XX 90 (a two-byte JMP SHORT instruction, followed by the NOP instruction), and also the valid Partition table at 0x1BE offset, and the valid BPB otherwise. If JMP/NOP and a valid BPB exist, then it is a Large floppy, otherwise it is a PRM. As far as I can see, the valid partition type field is not mandatory. You can use 0x7 in any case. FAT32.IFS will mount the partitions with type 0x7 fine.

> This is also a dead end because with EXFAT Microsoft decided they are going to drop the BPB for good and describe the media layout at another place on the media. Another nail in the coffin of OS/2.

In exFAT, M$ has the BPB being zeroed-out, and it is followed by a new structure, which I call BPB2, which is equivalent to BPB, but has the 64-bit replacements for HiddenSectors and LargeTotalSectors fields. This is to support volumes of sizes larger than 2 TB. Also, for support of big clusters (which could be up to 32 MB), the Byte-sized shift values are used instead of BytesPerSector and SectorsPerCluster fields. Indeed, this does not prevent to mount exFAT partitions under OS/2. FS_MOUNT routine just parses the BPB2 structure, instead of the BPB. The problems could be with HiddenSectors, when booting OS/2 for such partitions. But indeed, this is not a big problem too. QSINIT can emulate the BPB in memory, and pass it to os2ldr, if Booting from exFAT, if you use QSINIT as a boot manager.

Andreas Kohl:

--- Quote from: Lars on November 27, 2017, 07:45:10 am ---a) USBMSD.ADD deals with removable media as much as with permanently attached USB hard disk, USB CD-ROM drives and USB floppy drives. I am not focussing on anything, neither does USBMSD.ADD.
--- End quote ---
In my opinion it should not deal with removable media at all. I know it becomes complicated in real world to draw a line between removable device and removable medium. To the user it's uncertain which parts of the Mass Storage Class Specification are implemented. The drivers can make some trouble with permanently attached devices that support removable media. At least the user interface should distinguish between the logical and physical view of devices and media.


--- Quote ---b) In the year 2017 it only makes sense to support systems with LVM. It's too late to make USBMSD.ADD compatible to an OS of the year 1996. There would be too many limitations.
--- End quote ---
I can see no difference between LVM and non-LVM enabled systems in kernel or device drivers. A Warp 4 or WSOD client can run the same bunch of applications. There's no need to use LVM for network stations at all. How many OS/2 user's operate with volumes that span across 50 partitions on different DASD?


--- Quote ---c) it is true that even IBM writes in their JFS release note that JFS should not be used with removable media. Nonetheless it is the only filesystem that is usable on large partitions, with large files. It seems to work ok (at least for me) but of course you need to take care when removing a USB device formatted with JFS. You better do a proper eject or you are asking for trouble.
--- End quote ---
I'm aware of the limitations. Fortunately Валерий wrote elaborately about it, so I have nothing to add. Большое спасибо! Oчень эрудированнo.

Navigation

[0] Message Index

[#] Next page

[*] Previous page

Go to full version