WebSite Information > Article Discussions

Large Floppy Support Discussion - USBMSD.ADD

(1/3) > >>

Doug Bissett:

--- Quote ---As I said multiple times this issue is already solved with my USBMSD.ADD driver.
--- End quote ---

Actually, it is not totally solved, and I know that that is the reason why AN has not picked up your changes for large floppy support. As I understand the problem (and I could be wrong), you wrap the contents of the drive in a software wrapper, but that doesn't include the MBR that is written on the device.  That works fine, until you decide to wipe the device, and recreate it, or even format it to a different file system. Since the "virtual MBR" is in memory, such changes modify the contents of memory, and not what is on the media. That works fine, until you eject it, and try it in another system. Then, the contents of the stick don't match. In other words, your approach does not allow an OS/2 user to properly manage media on USB sticks, because part of what needs to be on the stick, is only in memory (but only for FAT32 formatted sticks).

I think you have developed a "work around" for the real problem, but a "work around" that requires using some other OS, just to wipe the media, or even reformat it to some other file system, isn't up to the job.

Nothing wrong with what you did, but it is an incomplete solution, and not ready for prime time.

Lars:
Actually the most important problem WAS and IS solved. I agreed with David that if you want to change a large floppy stick to a partitioned stick under OS/2 you have to use DFSee (or its engine) to write all zeros for the first sector. (Think about why it requires a user decision to do that). USBMSD.ADD will detect that and will drop "large floppy" support so that you can subsequently partition and format the stick.

You can try that. It will work:
1) use DFSee to "write zeros to start of media"
2) eject the stick
3) run a lvm /rediscoverprm to have the system redetect the stick.
4) you can now freely partition the stick etc.

Not allowing to change the "large floppy" layout is a deliberate decision. If you think about it: you would not want OS/2 to mess around with your "large floppy" stick because that is a layout that stems from Windows. There are some subtleties in blindly formatting a "large floppy" stick to a different file system. Think about what would happen if someone deciced to format a "large floppy" stick to JFS.


Lars

ak120:

--- Quote from: Lars on November 26, 2017, 05:56:13 pm ---Actually the most important problem WAS and IS solved. I agreed with David that if you want to change a large floppy stick to a partitioned stick under OS/2 you have to use DFSee (or its engine) to write all zeros for the first sector. (Think about why it requires a user decision to do that). USBMSD.ADD will detect that and will drop "large floppy" support so that you can subsequently partition and format the stick.
--- End quote ---
I can follow the point that it handles a subset of special cases. USBMSD.ADD should be an adapter device driver for the whole device class of Mass Storage Devices. I can realise that you're focussing on removable storage devices for several reasons. But how about fixed storage devices? For SCSI (that should not be a huge difference) there is a special filter driver IBMRSCSI.FLT to alter the behaviour.


--- Quote ---You can try that. It will work:
1) use DFSee to "write zeros to start of media"
2) eject the stick
3) run a lvm /rediscoverprm to have the system redetect the stick.
4) you can now freely partition the stick etc.

--- End quote ---
I can confirm that it works for systems starting with Warp Server for e-business and later CP. But for the majority of the installed base it simply doesn't work in common configurations. Warp 4 RIPL requesters or WSOD don't have LVM support by default. So IBM's latest USB drivers work without this procedure as long applying only FAT or supported IFS for removable usage. And they have the advantage to be deployable for unattended installations.


--- Quote ---Not allowing to change the "large floppy" layout is a deliberate decision. If you think about it: you would not want OS/2 to mess around with your "large floppy" stick because that is a layout that stems from Windows. There are some subtleties in blindly formatting a "large floppy" stick to a different file system. Think about what would happen if someone deciced to format a "large floppy" stick to JFS.
--- End quote ---
Originally JFS was neither designed nor supported for removable units. 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. My statements are based on my own surveillance only. For now we can still use device servers via local networking to work-around USBMSD and file systems support shortcomings at one blow. But this solution cannot be used for lone wolf systems without LAN connectivity.

Doug Bissett:

--- Quote ---Actually the most important problem WAS and IS solved.
--- End quote ---

Actually, it is not. An effective work around has been developed, but the problem has not been solved. In fact, the USBMSD driver should be completely transparent to the file system. 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.


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

Lars:
Unfortunately your answer is as wrong as you think my answer is:

1) OS/2 only supports "large floppy" if the file system is formatted with FAT16. Yes, there should be no special dealing in USBMSD.ADD to support "large floppy" (no matter what filesystem is in use). But it's the kernel (or OS2LVM.DMD/OS2DASD.DMD) that has this limitation and this can only be worked around by fixing the kernel (DMD drivers) large scale. By the way: USBMSD.ADD does not care a bit about the filesystem. It only cares about the difference of partitioned vs. "large floppy" media. It does that by reading the very first sector of a media which contains the MBR (master boot record) or the VBR (volume boot record), the latter containing the BPB (bios parameter block). 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.

2) even the "large floppy" support for FAT12/16 media is done half-heartedly. The kernel has a bug in that it wants to write a DLAT sector to this kind of media nonetheless (if LVM is in use) if you tell lvm.exe (or minilvm.exe) to do that. What happens is that this will corrupt your USB stick as the kernel will blindly write that sector as sector 63 which will usually either fall into the FAT or into the data section of a "large floppy" formatted stick. Believe me, I have been testing and experiencing exactly this problem.

From the last comment you can tell why USBMSD.ADD is so paranoid about avoiding to mess with the real contents of a "large floppy" type stick. Changing data: Ok but changing vital disk structures: No.


In short: the kernel has never been written to support a layout without an MBR (that is: "floppy") on anything else than floppy disks (that's why FAT12/16 is supported for this layout). It has nothing to do with FAT32.IFS (or any other filesystem driver) whatsoever.


As to Mr. Kohl's response:

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.

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.

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.

Navigation

[0] Message Index

[#] Next page

Go to full version