PFS3 or PFS3 SCSI Direct

[xalakibaniou]

I hane an A1200 with and ide-fix 97 4way adapter. I have an old WD400 40GB ide hdd and and a TEAC DVD-ROM connected to separete cables. Both configured as master. I have downloaded PFS3 from aminet and installed. The ide hdd is using scsi.device driver.
I want to ask which filesystem is better, pfs3 standard or pfs3 scsi direct (pds\3) ? Thaksbin advance.

[thomas]

It does not matter in your case actually. The main difference is that without IDEfix PFS3 can access only the first 4GB of your harddrive while PFS3DS can access almost 8GB. To access all 40GB you need IDEfix anyway and with it both can access the entire drive.

You should however change the entry in startup-sequence to read C:LoadIDE RESET instead of C:IDEfix. This is described in the comment added to startup-sequence during installation. It makes IDEfix resident so that the 40GB harddrive is really accessible. With C:IDEfix partitions might not show until they are accessed by a Shell command (for example DiskChange).

[xalakibaniou]

Thanks Thomas. that realy helped

[mfilos]

Or you can also use a newest scsi.device that supports bigger HD's like Toni's/Chris's 43.45, or Cosmos's 43.47 and load it via LoadModule as first command in your Startup-Sequence.
Sadly Doobrey's 44.2 scsi.device doesn't support PFS3 partition over 4GB but with SFS it's awesome.

[fgh]

Originally Posted by mfilos

Doobrey's 44.2 scsi.device doesn't support PFS3 partition over 4GB

Do you know why this is? (Cosmos' readme mentions it, but is not very clear..)

PFS3 doesn't support NSD, only TD64 and directSCSI, and AFAIK the only scsi.device to support TD64 is idefix.
So to have Doobrey's scsi.device work with PFS3 >4GB, you need to use the direct-SCSI version.
(Or you can use idefix with the normal TD64 version)
Are you sure this doesn't work?

[thomas]

IDEfix replaces scsi.device completely. It is useless to patch scsi.device and then add IDEfix on top of it. If you use IDEfix you don't need a patch for scsi.device because it is superseded by IDEfix anyway.

[fgh]

Yes my sentence was not very clear, sorry. I've changed it in the previous post.

As PFS3 doesn't support NSD, it is not supposed to work without using direct-SCSI version with any version of scsi.device other than idefix.
I guess I'll have a go and check 44.2 with PFS3DS..

[thomas]

You could use this to make PFS3 work: http://aminet.net/package/disk/misc/td64patch

But PFS3ds ist the better solution IMHO.

[Toni Wilen]

Perhaps PFS3 should have built-in 4G/other limit check and requester that complains if current configuration is bad?

It would be quite easy to add to SVN version.

NSD support would be also easy to implement but personally I think NSD is perfect example of useless Not Invented Here (NIH) feature.

[thomas]

No requester please. SFS has this and it is highly annoying.

There are situations where no >4GB support is present but later there is. For example before LoadIDE has been run for the first time after power-on.

Regarding NSD, yes it is bad to have two command sets which work exactly the same way but only use different command codes. However, now that there is this situation and different drivers support different command sets, it would be nice if file systems would support both (i.e. check once and then use the one which works).

Similarly it would be nice to incoporate PFS3 and PFS3ds into one load module which automatically checks which one to use.

[Toni Wilen]

Originally Posted by thomas

No requester please. SFS has this and it is highly annoying.

There are situations where no >4GB support is present but later there is. For example before LoadIDE has been run for the first time after power-on.

ok

Regarding NSD, yes it is bad to have two command sets which work exactly the same way but only use different command codes. However, now that there is this situation and different drivers support different command sets, it would be nice if file systems would support both (i.e. check once and then use the one which works).

I'll think about this.

Similarly it would be nice to incoporate PFS3 and PFS3ds into one load module which automatically checks which one to use.

Unfortunately this is impossible to do without breaking some existing installations. PFS3 does not care about dostype and there are many PFS3DS installations that use normal PFS3 dostype. (or in worst case whatever hdtoolbox suggests as default..)

[thomas]

What does dostype have to do with it? If you have only one load module, you need only one dostype. Two dostypes were only needed if you installed PFS3 and PFS3ds at the same time. But if you incorporate Direct-SCSI support into the TD64 module so that it automatically selects DS if TD64 does not work, then different dostype is no longer needed. FFS V44 (FFSTD64) does it the same way. And SFS, too (selects either TD64 or NSD, whichever is present).

[Toni Wilen]

Originally Posted by thomas

What does dostype have to do with it? If you have only one load module, you need only one dostype. Two dostypes were only needed if you installed PFS3 and PFS3ds at the same time. But if you incorporate Direct-SCSI support into the TD64 module so that it automatically selects DS if TD64 does not work, then different dostype is no longer needed. FFS V44 (FFSTD64) does it the same way. And SFS, too (selects either TD64 or NSD, whichever is present).

I don't think it is that simple.

DS is special case, TD64 either is supported or not, same with NSD. Both TD64 and NSD generally always return same disk size (uses exact same driver calls)

Things get hairy when DS _and_ TD64 or NSD is supported. It is very possible that DS returns different disk size than TD64/NSD.

Which one is correct? I don't think it is necessarily the bigger one..

EDIT: I mean problems happen when updating PFS3 because above would mean change in default behavior.

[fgh]

Both FFSTD64 v44 and SFS v1.84 support direct-SCSI and TD64 simultaneously, so I guess it should be possible somehow.
Also FAT95 supports both direct SCSI and TD64.

Thomas: Is there a version of FFS44 that supports both NSD and TD64? Edit: Forget it, I misread your post..

[thomas]

Originally Posted by Toni Wilen

Things get hairy when DS _and_ TD64 or NSD is supported. It is very possible that DS returns different disk size than TD64/NSD.

Which one is correct? I don't think it is necessarily the bigger one..

File system does not need disk size. It gets geometry from DOS during mount. It should first check for NSD / TD64 and only if both aren't supported fall back to DS. Then it could try to read the last block of the partition (given by Surfaces/BlocksPerTrack/HighCyl) to check whether DS works or not.

[Toni Wilen]

Originally Posted by thomas

File system does not need disk size. It gets geometry from DOS during mount. It should first check for NSD / TD64 and only if both aren't supported fall back to DS. Then it could try to read the last block of the partition (given by Surfaces/BlocksPerTrack/HighCyl) to check whether DS works or not.

I forgot TD_GETGEOMETRY returns "fake" data.

We probably have totally different point of view. From my point of view backwards compatibility must not be broken at any cost and it must work even if used with some broken (for example crashes or does something strange if unsupported command is sent) late 1980s A500 controller.

Which means NDS/TD64 test can cause problems, which probably is the reason for original separation of normal and DS versions. (Maybe I am too paranoid but I remember reading about these kinds of buggy controllers)

[thomas]

I still don't see a reason why a (hard drive) file system would need to call TD_GETGEOMETRY. Scsi.device does not even support TD_GETGEOMETRY.

Do these old controllers with crashing drivers support disks bigger than 4GB? If they don't, the discussion is pointless.

IMHO a proper sequence of checks is this:

1. calculate the last block of the partition. If it is inside the first 4GB of the drive, use CMD_READ and CMD_WRITE. No 64 bit or SCSI support needed.

2. call NSCMD_DEVICEQUERY and check the list of supported commands if NSCMD_TD_READ64 and NSCMD_TD_WRITE64 are among them. If they are, use them.

3. if NSCMD_DEVICEQUERY succeeded, check the list of supported commands if TD_READ64 and TD_WRITE64 are among them (unlikely). If so, use them

4. call TD_READ64 with all numbers set to 0. If it returns no error or IOERR_BADLENGTH or IOERR_BADADDRESS, use TD64 commands

5. try to read the last block of the partition with HD_SCSICMD. If it succeeds, use HD_SCSICMD.

6. fail to mount

Depending on experiences during tests, 2. and 4. may be swapped, 3. may be skipped.

[Toni Wilen]

Originally Posted by thomas

I still don't see a reason why a (hard drive) file system would need to call TD_GETGEOMETRY. Scsi.device does not even support TD_GETGEOMETRY.

Forget it, I thought it was needed.

Do these old controllers with crashing drivers support disks bigger than 4GB? If they don't, the discussion is pointless.

Good point, but see below.

1. calculate the last block of the partition. If it is inside the first 4GB of the drive, use CMD_READ and CMD_WRITE. No 64 bit or SCSI support needed.

A590 with pre-7.0 ROM and CDTV SCSI expansion (all available ROM versions) have 1G limit (returns error if >1G access) when using CMD_READ/WRITE but HD_SCSICMD is "unlimited".

AFAIK there are also other old true SCSI controllers that convert CMD_READ/WRITE to SCSI Read(6) and Write(6) which has 1G limit. HD_SCSICMD and Read/Write(10) works fine, even if drive is >4G. (But on the other hand some controllers simply hang if drive is too big..)

This is the remaining annoying problem.

ADDED: I guess this should work: if end of partition is <4G and CMD_READ fails, re-read using HD_SCSICMD SCSI Read(6). Select DS if it succeeds.

[fgh]

Keep going guys, it would be great to have NSD support in PFS3, and/or TD64 support in a modern scsi.device. If anyone can do it it's you two

In the meantime, I checked my 16GB CF card with PFS3DS and scsi.device v44.2 on my A600 (ks37.300 68000, WB2.1) . It works well - all partitions show up as they should.

[thomas]

Originally Posted by Toni Wilen

Forget it, I thought it was needed.

A floppy file system could need it in order to distinct between DD and HD floppies. But not a hard disk file system.

Originally Posted by Toni Wilen

A590 with pre-7.0 ROM and CDTV SCSI expansion (all available ROM versions) have 1G limit (returns error if >1G access) when using CMD_READ/WRITE but HD_SCSICMD is "unlimited".

AFAIK there are also other old true SCSI controllers that convert CMD_READ/WRITE to SCSI Read(6) and Write(6) which has 1G limit. HD_SCSICMD and Read/Write(10) works fine, even if drive is >4G. (But on the other hand some controllers simply hang if drive is too big..)

This is the remaining annoying problem.

ADDED: I guess this should work: if end of partition is <4G and CMD_READ fails, re-read using HD_SCSICMD SCSI Read(6). Select DS if it succeeds.

If Read(6) has the same limit as CMD_READ, then it would be better to use Read(10) instead, wouldn't it?