Fat32fs and SATA

Sorry, lots of sarcasm, frustration, anger and a little hope…

Once upon a time there was a 1TB SSD as a backup drive. This was formatted via HForm to around 240GB FileCore…

Intermediate question, why does HForm format the same drive in different ways to USB/SCSI and SATA/ADFS (both Titanium). The suggested shape vary greatly. This may not play a role with an SSD, but …

I then set the rest of the SSD to FAT32 with PartiFC and formatted them accordingly with FAT32Formatter.
No problems so far.
The drive worked flawlessly on SATA and SCSI for over a year. As a backup drive, I only plugged it in when needed. Small amounts of data via USB, larger ones via SATA.
USB: fat32fs:mount -fp2:7 { > null: }; SATA fat32fs:mount -fp2:15 { > null: }…

Larger amounts of data had to be moved again on Friday, so SATA. Data was written to both partitions. No problems. I was able to access, write to and read from both partitions throughout the session.
After a restart, the drive was no longer readable. Both partitions were destroyed. DiscKnight and various recovery tools under WIN and Linux no longer produced any usable data.

A quick look at the FAT32FS sources (not mine, I’m too stupid for that, because I’m only user… difference DiscOp SWIs (SATA/ADFS), FN scsiop() (USB/SCSI)) revealed that apparently only USB/ SCSI can handle more than 256GB and several FAT32 partitions are also possible here. FAT32FS on SATA can only use one partition properly, and only as far as it is within the 256GB limitation (no partition offset).
When the difference between 256GB – 240GB (FileCore) is exceeded, i.e. with more than 10GB of data on the FAT32 partition, it is written to the FileCore area and ultimately, if there is enough data, the partition is killed.
In summary, it seems to fill FAT32 from the front, Filecore seems to fill from the middle. FAT32 writes via SATA in the FileCore area because it has no partition offset there. In the worst case, overwrite the Filecore boot block, then everything is broken.
These conclusions may not be 100% correct, but I tried more than one times. This (the crash) only happens on SATA and not on USB!!!

I’ll spare you the faecal thoughts that come to me.

Why isn’t the handling the same on all filesystems?

I hope someone smarter than me can fix FAT32FS accordingly.

Raik if only the RISC OS boot block has been overwritten by FAT32FS, DiscKnight should be able to recover it. By using Advanced Options and specifying the Disc Shape, DiscKnight will search for the Map and its duplicate copy of the boot block, and repair the drive. Use “240G” for the size and 0 for the partition start, assuming you’ve used proper 1024^3 GB (otherwise “223” for 10^9 GB or somewhere in between). DiscKnight will take a long time to search, printing dots and question marks as it goes along.

Data was written to both partitions

Why? For backups, if you need two copies, then use two drives. KISS.

Why? For backups, if you need two copies, then use two drives.

This is not the point of the problem, but for your understanding… There are data I only use under RISC OS and other for all OS. I didn’t wrote that I wrote the same data to the different partitions.
Why I should not use this at this way? As a USB device it works without problems with both partitions. There was no information before that ADFS use an other solution with the same fat32fs module.
I use such a device (250GB Filecore, 250GB FAT32) more than one year in my MX6. Both partitions often nearly full and I newer lost a bit o data.
Why I not should use the complete capacity of an device.

Jeff has has changed two things in fat32fs. Thanks a lot.
At first the discspace behind 256GB is closed for ADFS devices :-( and second a bug is fixed in the SCSI section of fat32fs (thanks to Anton Reiser).
Additional Toni has made any changes in fat32fs and use SWI_DiscOP64 to adress discspace behind 256GB. Is working without problems for us (have filled all partitions complete without problems). Toni has send this information/code to Jeff. I hope it will find a way inside the next version of fat32fs ;-)

Additional Toni has made any changes in fat32fs and use SWI_DiscOP64 to adress discspace behind 256GB.

Was that an issue? I have been using Fat32Fs for years with drives larger than 256GB on the Pi3. Also when he was writing is partition manager I clearly remember Jon Abbott complaining about the fact that the DiscOp64 implementation just called the old DiscOp code.

@André
My change don’t use the _DiscOp64 SWI.

If the filing-system is ADFS and the sector is beyond 256 GB I talk direct to the disc by ATA commands with the ADFS_IDEUserOp SWI. This is very experimental, but works for Raik and me at the Titanium.

With SCSIFS as filing sytem there is the SCSIFS_Paritions SWI, used as a workaround to access sectors > 256 GB, used in Fat32FS since verion 1.29.
From the Fat32FS ReadMe:
17/03/10 Changed the call to DiscOp64 such that it fakes a partition offset in the
SCSIFS workspace so that drives greater than 256GB can be used.

Excuse me. It looks like I mixed up several things from Anton’s mails. I’m only a dumb user …