SFS problem with FastATA MK-III and 160GB drive

Hi,

First of all thanks to the author for continually updating this great product, works very well!

I have a problem with SFSFormat and SFSCheck not working properly with FastATA controller.

My config is:
- A1200/030 with FastATA Mk-III
- 160GB IDE HD
- OS3.9BB2
- SFS 1.275
- FastATA drivers v8.4, NOSPLIT, RESIDENT, INTERRUPTS, PIO4
- FastATA drivers before SetPatch in startup-sequence
- NSDPatch disabled for scsi.device and 2nd.scsi.device

I have successfully used SFS with no problems on a 320GB hard drive connected to a CSPPC on a SCSI-IDE bridge, but the FastATA is causing grief.

SFSFormat reports no errors, but some of the partitions (up to 50GB in size) above 8GB have errors when using SFSCheck, and with these errors the partition remains uninitialized. Formatting one partition sometimes causes another to have errors:

Checking RootBlocks
Incorrect block type at block XXXXX. Expected was 0x53465300 but it was 0x42544d50.

Checking Bitmap at block YYYYY (....)
Incorrect block type at block ZZZZZ. Expected was 0x42544d50 but it was 0x53465300.

SFSQuery and SFSCheck report NSD 64bit is being used.

I have been at this for a little while with Elbox, but so far they haven't been able to get it to work.

FFS above 137GB with 300MB partition works fine and I have had no problems with it. SFS above 137GB with 300MB partition has same problems as above.

Thanks!

@Calgor

Quote:Sorry, I can't help, but you are not the only one with such problems with FastATA. Another user had the same problems, but unlike you not only with SFS, he had them with FFS as well, and no matter what he changed (HDs, cables, settings in the FastATA config, he even tried using PIO0) made it work.
In the end he replaced the FastATA hard- and software with IDEFix, that way he can't use the complete HDs (IIRC he has 2 160 GB ones as well, but since IDEFix doesn't support LBA48 only the first 128 GB can be used), but at least he can use a large part of his HDs without problems now.

@joerg

Quote:

Well, if Setpatch is loaded before the FastATA driver, then I can use up to 137GB without any problems. It also has the speed up. If Elbox can't fix the issue that is probably what I will end up doing.

Good to know I am not the only one with such problems. I wonder if anyone has got the hardware to work as advertised.

@Joerg

Just my luck that 1.275 had that AmigaOS3.x formatting problem. With 1.276 i can get most partitions to work except for one (sdh6:) which seems to work, but SFSCheck reports it has an error.

For example I have 3 partitions with problems, the rest are fine - sdh6:, sdh7:, sdh8:

If I format with SFS in order sdh6 sdh7 sdh8, then sdh6 reports problem, but sdh7 and sdh8 are okay.

If I then format sdh6, then sfscheck on sdh6 reports no errors, but sdh7 and sdh8 then do have problems even though I didn't do anything to them!

I can repeat these steps and sfscheck always fails on the same blocks within each respective partition (middle of sdh6, rootblocks of sdh7 and sdh8).

At the moment, I am leaving sdh6 with the error and all partitions are remembered on reboot and "seem" to have no problems.

Are there any other tools other than sfscheck I can use to verify the partitions?

EDIT: Also, why is sfscheck expecting or finding block type 0x42544d50? Is that the sfs data block type identifier?

@Calgor

Quote:Check the partition start and end offsets in the output of SFSQuery or SFSCheck, it sounds like the partitions are overlapping. If everything is correct the end offset of sdh6 should be the same as the start offset of sdh7 and the end offset of sdh7 the same as the start offset of sdh8 (if they are in that order on the HD without gaps or other partitions between them).

If that's not the problem and these 3 partitions are not inside the first 128 GB of the HD it's probably a bug in the LBA48 code of FastATA, but if that's the case and it's writing to wong sectors in LBA48 mode writing to any partition which is (partitally) after the first 128 GB can destroy all partitions, incl. the ones inside the first 128 GB. Even if SFSCheck reports no errors that could have happened already, if unused or data blocks were overwritten SFSCheck can't detect it.

Quote:No.

Quote:0x42544d50 ('BTMP') is the identifier for the bitmap?blocks, they are stored near the beginning of the partition.

@joerg

Thanks for the info.

I checked and sfsquery shows all of the partitions have end offset == start offset of next partition. HDToolBox also shows that there are no overlaps of start and end cylinders. Check4gb reports no problems, but it cannot check LBA48.

Mask is set to 0x7FFFFFFE, and MaxTransfer to 0x0001FE00.

Only sdh8 is partially over the 128GB boundary, so formatting sdh6 should not affect sdh7 and vice-versa????

Here are the results of sfsquery followed by:
1. sfscheck sdh6 (first bad block 5247 if format sdh7, first bad block 5248 if format sdh8)
2. sfsformat sdh6
3. sfscheck sdh7 (first bad block at end of partition) and sdh8 (first bad block at start of partition).

I would attach, but I don't know how. I will point Elbox to this thread.

4.SystemBack3:check4gb> sfsquery sdh6:
SFSquery information for sdh6: (SFS Version 1.276)
Start/end-offset : 0x00000001:f83f0000 - 0x0000000e:78538000 bytes
Device API : NSD (64-bit)
Bytes/block : 512 Total blocks : 104860224
Cache accesses : 102 Cache misses : 36 (35%)
Read-ahead cache : 8x 8192 bytes (Copyback)
Flush timeout : act. 20s - inact. 0.5s
Max Name Length : 107
DOS buffers : 80
SFS settings : [RECYCLED]
4.SystemBack3:check4gb> sfsquery sdh7:
SFSquery information for sdh7: (SFS Version 1.276)
Start/end-offset : 0x0000000e:78538000 - 0x0000001a:f8680000 bytes
Device API : NSD (64-bit)
Bytes/block : 512 Total blocks : 104860224
Cache accesses : 36 Cache misses : 14 (38%)
Read-ahead cache : 8x 8192 bytes (Copyback)
Flush timeout : act. 20s - inact. 0.5s
Max Name Length : 107
DOS buffers : 80
SFS settings : [RECYCLED]
4.SystemBack3:check4gb> sfsquery sdh8:
SFSquery information for sdh8: (SFS Version 1.276)
Start/end-offset : 0x0000001a:f8680000 - 0x00000025:1e3bc000 bytes
Device API : NSD (64-bit)
Bytes/block : 512 Total blocks : 85125600
Cache accesses : 51 Cache misses : 18 (35%)
Read-ahead cache : 8x 8192 bytes (Copyback)
Flush timeout : act. 20s - inact. 0.5s
Max Name Length : 107
DOS buffers : 80
SFS settings : [RECYCLED]

4.SystemBack3:check4gb> sfscheck sdh6: 400 lock
Partition start offset : 0x00000001:f83f0000 End offset : 0x0000000e:78538000
Surfaces : 24 Blocks/Track : 252
Bytes/Block : 512 Sectors/Block : 1
Total blocks : 104860224
Device interface : NSD (64-bit)

Checking RootBlocks
...okay
Checking AdminSpaceContainers at block 2
...okay
Checking NodeContainers at block 7
...okay
Checking ObjectContainers at block 3
...okay
Checking Bitmap at block 34 (26216 blocks, 4000 bits/bitmap)
Incorrect block type at block 5248. Expected was 0x42544d50 but it was 0x53465300.
...error in bitmap block at block 5248
...damaged
4.SystemBack3:check4gb> sfsformat drive sdh6: name Games
Press RETURN to begin formatting or CTRL-C to abort:
4.SystemBack3:check4gb> sfscheck sdh6: 400 lock
Partition start offset : 0x00000001:f83f0000 End offset : 0x0000000e:78538000
Surfaces : 24 Blocks/Track : 252
Bytes/Block : 512 Sectors/Block : 1
Total blocks : 104860224
Device interface : NSD (64-bit)

Checking RootBlocks
...okay
Checking AdminSpaceContainers at block 2
...okay
Checking NodeContainers at block 7
...okay
Checking ObjectContainers at block 3
...okay
Checking Bitmap at block 34 (26216 blocks, 4000 bits/bitmap)
...okay
4.SystemBack3:check4gb> sfscheck sdh7: 400 lock
Partition start offset : 0x0000000e:78538000 End offset : 0x0000001a:f8680000
Surfaces : 24 Blocks/Track : 252
Bytes/Block : 512 Sectors/Block : 1
Total blocks : 104860224
Device interface : NSD (64-bit)

Checking RootBlocks
Incorrect block type at block 104860223. Expected was 0x53465300 but it was 0x42544d50.
...damaged
4.SystemBack3:check4gb> sfscheck sdh8: 400 lock
Partition start offset : 0x0000001a:f8680000 End offset : 0x00000025:1e3bc000
Surfaces : 24 Blocks/Track : 252
Bytes/Block : 512 Sectors/Block : 1
Total blocks : 85125600
Device interface : NSD (64-bit)

Checking RootBlocks
Incorrect block type at block 0. Expected was 0x53465300 but it was 0x42544d50.
...damaged

@Calgor

Can you insert a gap between two partitions and check again?

@Calgor

Cache accesses : 102 Cache misses : 36 (35%)
Read-ahead cache : 8x 8192 bytes (Copyback)
Flush timeout : act. 20s - inact. 0.5s
Max Name Length : 107
DOS buffers : 80


when you will get the problem fixed (which i have no clue about why happens) rise the dosbuffers to at least 400, or you will get a lot a cache misses and then setup a good Read-ahead cache setup with SFSConfig OR SetCache

edit- here i'm not 100% sure but seems that the latest SFS versions are very sensitive to the identifier set in HDToolbox.

For some reason HDTB, doesn't recognize correctly the identif?er, setting it at CFS (Custom File System or so)

Type in HDToolbox the identifier manually

0x53465300 for SFS\00

0x53465302 for SFS\02

@Framiga

I did have to manually type in 0x53465300 in HDToolbox. Will set the caches etc when (if) it starts working.

@Jack

I tried different partition positions, and then it reported no errors, but after I copied a number of large files and rebooted, there went part of my RDB and my main boot partition!

So as shown earlier with sfsformat, writing to one partition writes to another!

Surely there is something I have missed or am doing wrong! Elbox have confirmed that they have it working and many of their customers have it working too. But I guess no one on EAB or amigans.net.

@Calgor

Try disabling MAPROM jumper and also completely reinstall drive.

Just thought I would let you guys know that this problem has been solved by a beta driver from Elbox. The only change in configuration to my initial post was to use SFS 1.276 (to fix the SFS bug) and the new beta Elbox driver (to fix a bug possibly with interrupt mode - maybe it would have worked with that mode off?).

I can also use PIO5 mode which is slightly faster and get 8.5MB/s without interrupt mode.

Thanks for all the help and suggestions.