Forums - The Amigans website

Re: SFS problem with FastATA MK-III and 160GB drive

Subject: Re: SFS problem with FastATA MK-III and 160GB drive
by joerg on 2007/9/8 20:01:08

@Calgor

Quote:

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!

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:

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

No.

Quote:

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

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