USBHDFSD - potential cache coherency bug when adding/renaming files

[sp193]

USBHDFSD has a sector cache, which covers the whole disk in units of 4096-byte blocks. This is aligned with the start of the disk and has no relationship with any filesystem on the disk.

As such, if the code allocates a block before writing without reading the old content, it is perhaps possible for the remainder of the block to become lost.

For example: | CLUSTER 1 | CLUSTER 2|... ..| BLK1 | BLK2 | BLK3 |....

Where CLUSTER 1 and CLUSTER 2 are logical clusters in a filesystem, while BLK1, BLK2 and BLK3 are the blocks within the cache. The clusters are larger (for example, 32KB each) than the blocks (4KB each). The blocks are not aligned with the clusters (perhaps because there is 1KB alignment).

The software decides to allocate cluster 2, whose corresponding cache block contains some sectors that belongs to cluster 1. As the block is allocated and the old data being totally discarded, some of the sectors that belong to cluster 1 are lost.

The affected lines within fat_write.c concern direntry manipulation, so the user may observe corruption of FAT when:

• The cluster size is not a multiple of the block size. Or the clusters are not aligned with the blocks.
• Files or directories are added or renamed.
• The cluster that the direntry being updated exists in the middle of a cache block, which is shared with the adjacent cluster.

Line 1274: https://github.com/ps2dev/ps2sdk/blob/master/iop/usb/usbhdfsd/src/fat_write.c#L1274 Line 1308: https://github.com/ps2dev/ps2sdk/blob/master/iop/usb/usbhdfsd/src/fat_write.c#L1308

Personally, I have made a similar mistake before in 2014, which occasionally resulted in corruption when data is written: https://github.com/ps2dev/ps2sdk/commit/a9494c2dc8efa9430b17f05f9891b56194229c53#diff-ba7f9373100b558565bd2d05edac0ee8 So I do think it is a plausible design flaw within the FAT driver.

I shall make a branch and offer a prototype, for more individuals to test with.

EDIT: Custom USBHDFSD module that does not use scache_allocSector in fat_write.c: https://www.sendspace.com/file/blz5os Branch: https://github.com/sp193/ps2sdk/tree/usbhdfsd-scache-noalloc

One can test whether it is an improvement, by copying usbhdfsd-noscachealloc.irx as USBHDFSD.IRX, and to get LaunchELF to use it.

[Badore90]

yes of course

I'll ask you the question again: "The program must start even when I'm not connected to the Ps2 right??" Mybe the program doesn't work when i'm not connected to the Ps2?? excuse the ignorance...

[sp193]

No, it does not matter. Can you use the command prompt (cmd) instead? I don't know if using the Powershell makes a difference.

[Badore90]

I thought Windows 10 just changes the command prompt's name in PowerShell. Contrariwise after your tip I see that there's also the command prompt (it's in a different place). I'll try with it

[Badore90]

Ok it works, thank you. I'll test it with the ps2 as soon as I can

P.S. sorry but I'm quite ignorant in Ps2 SMB. Therefore if there's something else I must know to make it work (like to activate some sharing permissions in the test folder, etc…), let me know. So that I can go without fail on the next try :)

[sp193]

We're not using SMB, so no worries. I'm more concerned if this can actually allow us to capture such a bug, which doesn't usually occur. Or if it doesn't even work as intended, since I never tested it.

[Badore90]

Here the file results.log I copied BOOT.ELF (that is OPL_DB_1330) from MC1 to mass (Toshiba usbHDD 500gb), the copy process seems to end without problems as always. Then I launch the just copied file and got a black screen.

I after repeated the exactly same process with Ule 4.42d and the copied elf works flawlessy.

[Badore90]

the log's lenght depends from the file's size?? 'Cause if it's a problem I can repeat the process copying a smaller file (like Ule)

[sp193]

Yes, the more data copied, the longer it will be. I thought we were going to try and see why we sometimes get "paste failed" though. If you want to try to fix this other "unsolvable" problem of USBHDFSD writing files incorrectly, you need to dump your HDD and to give me a file comparison. Otherwise, I cannot tell why and where it's going wrong.

Anyway, thanks.

[sp193]

Tell you what. I think there is one thing I didn't consider, which is sectorSkip. I'll spend some time thinking about it, before making further updates if/when necessary. And in the meantime, other people can help with scrutinizing the code.

I haven't figured out why it seems to read files fine if not considering sectorSkip while computing the number of consecutive sectors is wrong, but it might be wrong because it could be considering the wrong indexes for sectors between clusters.

[Badore90]

I can repeat the test with an empty pen-drive, ok??

It would be possible to add the communication with planetty to Ule 4.42d?? In order to make a comparison

About the "paste failed" I can't remembrer if it never happened to me. The paste failed, but the program isn't aware of it, no error messages.

[sp193]

I think it may be easier for you (and other people) to try using this build of LaunchELF instead: https://www.sendspace.com/file/ojtkg6 EDIT: you just need to use it. Don't use PLANETTY because no logs will be generated.

If it is a problem with USBHDFSD, then it is not really a LaunchELF problem. Also because too much time has passed between 2011 and 2018, there has been a number of other changes made to USBHDFSD. So with the changes in behaviour to USBHDFSD and the likelihood of USBHDFSD selecting the same clusters on the disk to copy files to, it will be very difficult to do a simple comparison of logs...

I am pretty convinced that without considering sectorSkip (the number of leading sectors to skip within the first cluster before reading/writing) is a problem. With this new build of LaunchELF, I attempted to view JPEG and PNG images and there was problem with doing that. I tried to duplicate JPEG and PNG on the disk to another directory, and they were transferred with no issues. I also copied RDB from my memory card to USB disk, and it seems fine. chkdsk reported no corruption, but my USB disk now has very few files on it.

Please let me know if the new commit helps, so I can quickly push it to ps2dev/ps2sdk, so as to limit the spread of the defective USBHDFSD module.

[gingerbeardman]

I'll try soon, promise.

Aside: were there ever any attempts to utilise existing OSS projects to provide FAT support? FatFs, Petit FS

[sp193]

I need to attend to other things, so I have committed the change and made new releases for all the software that I have jurisdiction over. I'm going to hope that I actually fixed the problem. If not, I will be sad. But that will be in a few days. haha

Either way, thank you all for helping me with solving the issues that were introduced since June 8th, as well as the handful of 11-year old bugs.

No, I don't know if anybody did port homebrew FAT libraries for this purpose. It is possible that it was just not done because the module in question, USBHDFSD, was created a really long time ago (2007?) under a different name (usbmass). We're also constrained by the resources that the PS2 has. So it is also a good idea to keep the modules as simple as possible. Sometimes, writing a new module is the best way, despite all the obstacles and effort needed. Needlessly to say, developing software for this console is just challenging.

However, I know that the ps2netbox guy did port a library for exFAT support. I don't know the details though. He was interested in keeping things closed-source because he wanted to sell a complete product. But, I am not sure whether it's even legal because Microsoft says "A license is required in order to implement exFAT and use it in a product or device."

[Badore90]

Tried BOOT-181027.ELF ...I don't know, what modifications have you made?? It perfectly copied the files (I tried also OPL_DB_1330 that gave me black screen the other day), all ELFs starts correctly. ...But, then I tried with your builds from your previous links (and with ule 4.43 from fmcb 1964 too) and they all perfectly copied the files now.

I wonder if therefore it's a random thing or maybe it's a modules question?? In the last case it's possible that after booting your last build the others too start to paste correctly??

I don't have any idea how these things work, I'm saying that from my experience playing games from internal HDD. There are some games that required to load the HDD modules once from Ule (or FMCB configurator) and then they work with OPL (at least until you made some modifications, etc...). It can be a similar thing for USB-HDD too??

[Badore90]

Tried with another Ps2 and the pasted ELF always works, I can copy/paste it with any of your builds. So unless your last build made some modifications to my USB-HDD modules (or the way the Ps2 recognize it, I don't know…) it's a random thing.

Btw it's a little weird, 'cause though I didn't made many, all my pasted files was bad until I tried your last build, it would be a crazy coincidence.

[Badore90]

I'll try with another Ps2 and another USB device tomorrow

[sp193]

This commit is the relevant commit. Yes, I changed only the USBHDFSD module, which provides access to USB Mass Storage Devices.

It is precisely because the bug depends on what is on your disk (and hence what the bug can destroy) and the cluster size, that we all get varying results.

Please destroy all old versions of software made between June 8th and September 26th, when you can. Since they contain bugged versions of USBHDFSD, then they are only good for destroying data.

All standard PlayStation 2 software have full control over the PS2, and are hence responsible for loading the modules that they require. Only some devices, like the CD/DVD drive and ROM will have the necessary modules loaded by default. Other devices like the memory card and HDD unit, require additional modules to be loaded. USB mass storage devices and the USB OHCI controller are also included.

If you're thinking of that case where booting "supported" software before booting any newer software would allow those "GameStar" adaptors to somehow become compatible, it is working around the hardware bug in those adaptors by initializing the bad adaptor first, hence avoiding the incompatible initialization code of the newer modules.

The PS2 model should not matter. If it matters, then it should be a USBD problem. Or even some hardware incompatibility, which I am not going to touch since I have no skills for that.

Either way, thank you. And all other participants.

[Badore90]

If you're thinking of that case where booting "supported" software before booting any newer software would allow those "GameStar" adaptors to somehow become compatible, it is working around the hardware bug in those adaptors by initializing the bad adaptor first, hence avoiding the incompatible initialization code of the newer modules.

Well I done this too. When formatting my 2tb HDD with the gamestar NA: loaded modules with Ule 4.42d, then Ule 4.43a 2tb edition could see it.

However I I wanted to say something else. i.e. the game Ferrari challenge trofeo pirelli. You can see here: http://www.psx-place.com/threads/open-ps2-loader-game-bug-reports.19401/ the tenth game in the list or here: http://psx-scene.com/forums/f150/open-ps2-loader-game-compatibility-62463/index53.html at the post #529

This game is given to not work (it freeze at the second loading screen)

But actually there are 2 ways to make this game work (with any HDL/OPL version)

1. You can just launch HDL/OPL from a usb device
2. (this is the werid one to which I referred) you can make this game work even booting HDL/OPL (any version) from your MC. You must first load the HDD with a FMCB program (Ule or FMCB installer), doesn't matter wich version or wich NA you're using and doesn't matter even if the modules are loaded or not, just to try is enough (like with Ule 4.43a with a Gamestar NA, it try to load the modules a couple of time, then leave the HDD turned-off, but is is enough to make the game not freezing).

This way the game won't freeze even using HDL/OPL(any version) from the MC. You can reset you Ps2 all times you want, the game now will ever work… until you leave your Ps2 turned off from the main power for a long time, or if you make certain modifications to your HDD (like installing(deleting a game) or in your MC. I can't be more precise about what modifications affect it. Anyway if at some point the game return to freeze, you can just repeat the FMCB load (or try to load) modules process.

One of the latest OPL daily builds, seems to solved this though. I think from DB_1330. With it there's no more need to do this process, the game never freeze.

[sp193]

I see. Anyway, thank you and the others for helping out. I shall be closing this issue. It was long derailed from the original problem, although the other issues were somewhat still related.

You may all feel free to bring it up again, if you have substantial facts to revisit the issues that USBHDFSD may still have.