CF card formatting for OS installation - scsi.device issue?

[Jope]

Hmm, which filesystem are you using now? With the OS3.1 FFS you can only use 4GB of the disk. With pfs3aio you can use the full CF card and the partition can be the entire card's size too.

If you have an updated scsi.device, PFS3 can have partitions up to 104GB in size, as many as fit on the disk.

[Fenris]

I'm using pfs3aio, I haven't touched the default scsi.deviceIDE - Auto set in WinUae, and scsi.device without any other version specification in HDtoolBox, so I must be doing something wrong...hmmmm

[thomas]

Originally Posted by vulture

I used nsdpatch to access my big partition after the first 4gb on my 32gb CF

There is no file system outside OS 3.5/3.9 which requires NSDPatch for large harddrive support. And these OS have NSDPatch included, they don't need it installed.

NSDPatch allows file systems to use NSD commands to access large harddrives. The only file system which requires NSD commands is the FastFileSystem which comes with OS 3.9. All other file systems already support either TD64 or Direct SCSI.

NSDPatch does not do magic. It only translates NSD commands into either TD64 or Direct SCSI commands. Which means it only allows FFS V45 to access large harddrives on drivers which already have large harddrive support.

And on those drivers which only partially support large harddrives (like scsi.device V40 with Direct SCSI), their limits still apply. Like the 8 GB limit on the internal IDE controller.

I am quite sure that you did not need NSDPatch on your 32 GB CF card.

Regarding SFS vs. PFS, people have different experiences. Some say SFS is rock stable and PFS is not, some say the opposite.

The main disadvantage of SFS is that if something goes wrong, you loose everything. If there is a file system error, it does let you access the whole partition any more. And there is no repair tool and the only salvage tool does not work, it only creates empty directories.

[vulture]

@thomas

Well, it's SFS and the big partition beyond the first 4gb won't show until I run NSDPatch. WB 3.1 , KS 3.1. It boots, no big partition. I run nsdpatch, it appears. How's that happening?

You're right about SFS, but I have access to Morphos and the recovery tools are good there.

[Jope]

You have the version of SFS that doesn't do directscsi, but has TD64 and NSD support.

[vulture]

@Jope

Probably so. But that means NSD isn't useless.

[Jope]

Well the solution it provides is better provided by something that isn't an intermediate wrapper, so while it's not fully useless, the New Style Devices it promised was never really used for more than getting past the scsi.device size barrier. It was supposed to be a lot more. :-)

But as with everything Amiga, this is a dividing subject. "everyone else" had gone behind TD64 except for the person who invented NSD and added it to OS3.5 way back when. The idea was to extend the device driver api further, but in the end hardly anything took advantage of the extensions. For the 4GB limit, we already had TD64 with directscsi fallback years before..

And as Thomas mentioned above, NSDPatch alone will not solve the 8GB problem on a 3.1 scsi.device, you still need to load an updated scsi.device, which will most likely support TD64, and if not, directscsi will work for large disks.. So why bother with NSD on top.

[vulture]

True, I was just wondering how it can be considered completely useless.

But, hmmm, you said "NSDPatch alone will not solve the 8GB problem on a 3.1 scsi.device" , but I simply used it with KS 3.1 scsi.device , not an updated one, and worked with 32gb fine. Hpw can that be?

[alexh]

Originally Posted by vulture

you said "NSDPatch alone will not solve the 8GB problem on a 3.1 scsi.device" , but I simply used it with KS 3.1 scsi.device , not an updated one, and worked with 32gb fine. How can that be?

It is not alone, it's with a filesystem that presumably supports NSD but not TD64 or DirectSCSI.

[Jope]

Then it must do some magic for scsi.device, even though the docs and cfg file mention that we mustn't expect magic. :-)

Reading the docs it sounds like it's wrapping the 64bit calls via directscsi, but it must be actually fixing the V40 scsi.device in addition to adding the NSD wrapper. Or it's not and SFS will bork the beginning of the disk after you write past 8GB. But I guess you have filled the partitions up past that and your disk didn't corrupt.

[alexh]

I don't think we should speculate as to what it might be doing.

[thomas]

There are very rare CF cards which report their real size using "illegal" CHS values. These can be fully used with scsi.device V40.

No, NSDPatch surely does not "fix" scsi.device. It only does what is documented, it uses either Direct-SCSI or TD64 for large harddrives, whichever is available.

I don't think we'll get any further in this discussion. NSDPatch is superfluous software because you can find a good combination of IDE driver and file system which works without it.

You can also find a combination which does not work without it, but that's just a stupid choice, not a reason to use NSDPatch. My opinion that is.

[vulture]

@Jope

Yes, only 3gb left empty off the big partition, it would've wrapped around a long time ago

@thomas

Maybe that's it then. Maybe it's one of those rare CF cases. How could I check that?

[thomas]

Originally Posted by vulture

How could I check that?

Boot with plain Kick 3.1 + Install 3.1 floppy. No patches, clean memory (= immediately after power on, no harddrive boot before). Run HDToolbox, change drive type -> define new -> read configuration.

Check the values for cylinders / heads / sectors. "Legal" values are 16383 / 16 / 63. If your values are higher, it's one of those rare pieces.

[vulture]

Ah, good, makes sense, thx!