24 November 2009, 21:55 | #1 |
Moderator
Join Date: Jun 2001
Location: I'm behind you!
Posts: 3,763
|
Clearing up the best files for Large Hard Drive support
I've mentioned the next ClassicWB packs are going to have all the necessary files for Large Hard Drive support. That means files to allow up to 8GB without a patched "scsi.device" and >8GB with a patched "scsi.device".
Problem is, there are a lot of different solutions and standards to achieve this, so I want to cut down to the best files to use as I'm confused. Partitioning and software that support large hard drives:
Replacement file system for up to 8GB support:
Replacement "scsi.device" for greater than 8GB support:
The latest SFS or PFS can be used with the above "scsi.device" replacements for large hard drive support. Have I missed any? What does the NSD patch do? Is it necessary? http://aminet.net/search?query=nsdpatch Where does it fit in to all of this? I'm confused as to which are the best files to include in the next packs? There are a few options and I want to keep things as simple as possible. Please help! All the talk of NSD64, TD64, scsidirect and several different versions of these files is a little overwhelming! Last edited by Bloodwych; 24 November 2009 at 22:07. |
24 November 2009, 22:30 | #2 | ||||
Registered User
Join Date: Jan 2002
Location: Germany
Posts: 6,985
|
Please do not recommend HDInstTool. It does not work any better than HDToolbox (except that it displays the right numbers), but it has one major bug which makes it incompatible to any other partitioning tool: it does not use the values for cylinders/heads/sectors which the user enters or which are already stored in the RDB, but it always uses its own values internally. This makes it completely unusable for editing HDDs which were already partitioned with another program. And it also makes it unusable for big harddrives if the values it uses are not good.
Quote:
Quote:
Quote:
Quote:
See these two lists (from memory, might be incomplete or wrong): scsi.device V40: NSD -> no, TD64 -> no, SCSI -> yes, but only up to 7.8 GiB. scsi.device V43+: NSD -> yes, TD64 -> no, SCSI -> yes scsi.device V116+ (IDEfix): NSD -> yes, TD64 -> yes, SCSI -> yes cybppc.device (and most other Phase5 controllers): NSD -> no, TD64 -> yes, SCSI -> yes FFS V40 and below: NSD -> no, TD64 -> no, SCSI -> no FFS V43: NSD -> yes, TD64 -> no, SCSI -> no FFS V44 (FFSTD64): NSD -> no, TD64 -> yes, SCSI -> yes FFS V45 (OS 3.5 or 3.9): like V43 PFS: NSD -> no, TD64 -> yes, SCSI -> no PFSds: NSD -> no, TD64 -> no, SCSI -> yes SFS V1.84: NSD -> yes, TD64 -> yes, SCSI -> yes SFS V1.279: NSD -> yes, TD64 -> yes, SCSI -> no Now take a device and a file system which both have a "yes" in the same column, then this combination can be used for large hard drives. If you don't find a combination, large hard drives are not possible. Basically that's all check4gb does, nothing else. Depending on whether the combination is already active before the boot process starts or not, the boot partition has to be inside the first 4GB or not. For example cybppc.device + PFS3 are active early enough so that you can create boot partitions of any size and anwhere on the disk. But scsi.device V43 or higher is usually loaded only after the boot partition is already mounted, therefore the boot partition has to be inside the first 4GB (or inside the first 7.8 GB if you use a file system which "speaks" SCSI). Is this enough confusion for now ? |
||||
25 November 2009, 16:44 | #3 |
Moderator
Join Date: Jun 2001
Location: I'm behind you!
Posts: 3,763
|
Oh man, Thomas you are awesome as usual! That makes it all really clear - really appreciate your help.
I don't have the time I used to for working on the packs, so being able to rely on knowledgeable Amiga users when doing the updates saves loads of time. Ok, partitioning. I'll take your advice and won't include the "HDInstall" replacement. I take it HDtoolbox can see up to 8GB yes? But it can be used for larger than 8GB drives, but doesn't calculate the correct values. Is that correct? So do you think it's best just to stick to the standard HDtoolbox or do you know a better utility that handles greater than 8GB calculations? Ok, on to the "scsi.device". doobrey's patch uses a OS3.9 file - since it isn't free AND not well tested, I guess I'm better sticking to the patched v43.24. I also noticed there is a patch on Aminet: http://aminet.net/package/driver/media/SCSI4345p but again, this uses the OS3.9 scsi.device so I can't include it except for the ClassicWB OS39 pack, which could do the patching during the install. In your opinion (or anyone else that may know/tested these), does the patched v43.24 work adequately and without problems? Or are their definite advantages to using the v43.45 or v44.2? Finally, the command sets. So NSD, TD64 and direct-SCSI a.k.a. HD_SCSICMD are all ways for the device driver and filesystem to communicate and support larger hard drives. As long as I have a scsi.device and file system that can communicate using one of those, the others are not required. Is that right? |
25 November 2009, 20:08 | #4 | |||||
Registered User
Join Date: Jan 2002
Location: Germany
Posts: 6,985
|
Quote:
Quote:
It "sees" everything the driver can see. It is scsi.device which sees only 8GB. As soon as scsi.device has been patched to support larger drives, HDToolbox allows to partition the larger space. Quote:
A beginner probably runs better with HDInstTool, because he does not care about internal values anyway. But HDInstTool cannot be used to edit a partition table which was created by another program or to recover an RDB which was created by another program. I.e. HDInstTool cannot be used for "advanced" actions. Quote:
I can't remember if I ever used it. Quote:
43.43 (the unpatched BB2 version) crashes when using harddrives bigger than 128 GB. 43.45 (and probably Doobrey's too) is the only version which can use LBA48 (> 128 GB drives). No idea if it's safe, though. I never had anything bigger than 20 GB in one of my Amigas. |
|||||
25 November 2009, 20:14 | #5 | ||
Crazy Collector
Join Date: Aug 2006
Location: Munich/Bavaria + Saxony + Thailand
Age: 52
Posts: 151
|
Quote:
Call NSDPatch in ur startup-sequence when using Kick 3.1 + WB 3.1 and u don't need to load a patched scsi.device or have to burn an updated Kickstart-EPROM. And NSDPatch does much more than that. Quote:
The only reason why cybppc.device is supporting TD64 right out of the box is that TD64 is a brainchild of Ralph Schmidt (and Ralph Babel and others of course). Ciao, Rick ... Last edited by Skylight; 25 November 2009 at 20:37. Reason: don't forget Ralph Babel ;) |
||
25 November 2009, 20:28 | #6 |
Crazy Collector
Join Date: Aug 2006
Location: Munich/Bavaria + Saxony + Thailand
Age: 52
Posts: 151
|
btw ... NSD was the official solution of AT and is part of AmigaOS 3.5 and 3.9 .. so it was the way to go for me.
TD64 was a dead end in my eyes. But u can still use TD64, especially on older Kickstarts. Ciao, Rick ... |
26 November 2009, 00:53 | #7 |
Moderator
Join Date: Jun 2001
Location: I'm behind you!
Posts: 3,763
|
Thanks Thomas for getting back to me and to you Skylight for adding to the info.
I'm now crystal clear on how everything works. I'll probably use a lot of this info in a sticky when I get around to updating the >4GB thread. It would be useful in the abime wiki too I'd imagine. |
26 November 2009, 07:57 | #8 |
Crazy Collector
Join Date: Aug 2006
Location: Munich/Bavaria + Saxony + Thailand
Age: 52
Posts: 151
|
btw .. i forgot to mention the NSDPatch 43.20 works with Kickstart 2.04 and up.
So u don't need Kick 3.1 to use it. Ciao, Rick ... |
26 November 2009, 08:39 | #9 | |||||
Registered User
Join Date: Jan 2002
Location: Germany
Posts: 6,985
|
Quote:
The same can be achieved by FFSTD64 or SFS V1.84 or PFS3ds in a much more comfortable way. Quote:
Quote:
Quote:
Quote:
Regarding 64bit support NSD and TD64 work just the same way (put the upper 32 bits into io_Actual), they just use different command codes (24 vs. 0xc000). So IMHO one should prefer the command set which supplies more compatibility. And for Phase5 and Elaborate Bytes controllers this is TD64 because their firmware does not support NSD without a patch. |
|||||
26 November 2009, 17:24 | #10 |
Moderator
Join Date: Nov 2004
Location: Eksjö / Sweden
Posts: 5,602
|
Ah, a nice and juicy thread! I appreciate your efforts at trying to get info down on all these obstacles and custom drivers/tools/file systems
I've visited Thomas' webpage and read the stuff here, but I'm having a hard time getting "into" all the stuff. I must say I've not quite been "un-confused" by this thread either, hehe. If I take an example: I have an A600 with kick 3.1 and WB 3.1 (and also an A1200-060 with the same kick/WB, but the question is about the A600). I'd like to keep WB 3.1 on both. On both I have a Hong Kong IDE-CF adapter and a SanDisk Extreme IV CF-card. If I were to buy a bigger CF-card, what is the largest I can go, while keeping some FFS-compatible filesystem (ie. sees standard FFS partition and WinUAE "harddisk folders" for when I backup stuff), how big a card could I buy, and how small do the partitions need to be? And what files would I need? If I get some tips on what to go with, I could write up a tutorial when I've made it work. |
26 November 2009, 18:11 | #11 | |
Registered User
Join Date: Jan 2002
Location: Germany
Posts: 6,985
|
As always: "it depends".
For drives up to 8.45 GB (1 GB = 10 to the power of 9 bytes) or 7.87 GiB (1 GiB = 2 to the power of 30 bytes) it is sufficient (and most efficient) to install a file system which supports HD_SCSICMD. You don't need any further patch and can create partitions anywhere and as big as you like. Such file systems are SFS 1.84, FFSTD64 or PFS2/3ds. (Links see in Bloodwych's first post). For bigger drives you also need a patch for scsi.device. Please note that each patch needs some memory as well as the buffers for partitions need memory. The more partitions you make and the bigger the partitions are, the more buffers you need. For a 40 GB HDD with let's say 10 partitions (historically grown) with buffers for decent performance you might loose 1 or 2 MB of memory. For an A600 this is clearly too much. So for computers with few RAM I would stick with small hard drives. Nevertheless, you can put scsi.device (any version, preferably 43.45 or 44.2) into the Devs directory and add a line like loadmodule devs:scsi.device to the top of your startup-sequence and there you go with big harddrives up to 2 TiB / 2.2 TB. (You see, the difference between binary and decimal measurement units grows significantly in these dimensions. The difference between 2 TB and 2 TiB is 200 GB). With big harddrives also the limits of the file systems become relevant. With PFS3 you can use partitions up to 107 GB, with SFS up to 128 GB. I don't know the limit of FFS and how it calculates but I am sure that with a block size of 1024 bytes you can safely create partitions of 20 or 40 GB. With SFS2 there is no limit AFAIK (SFS2 = SFS with an identifier of 0x53465302). For the decision which file system to use you should look into the two tables I mentioned above. Take the version of scsi.device you've got, look up which command sets it supports and choose a file system which also supports at least one of these command sets. Whether you go the SFS, the PFS or the FFS route is up to your personal taste. SFS and PFS both are much faster than FFS but less redundant and therefore more difficult to recover in case of an error. Edit: SFS needs a 68020 and PFS maybe too (I am not sure atm). So they are not usable on a plain A600. Quote:
Harddisk folders are completely independant from all of the above because they are completely handled by WinUAE internally. And of course you can use as many file systems as fit into your RAM. Each partition can have a different file system. So which file system you use for one HDD is completely unrelated to other HDDs. Only if you try to run all this with a very small amount of RAM, you'll run into troubles. Last edited by thomas; 26 November 2009 at 18:21. |
|
26 November 2009, 20:32 | #12 | |||
Crazy Collector
Join Date: Aug 2006
Location: Munich/Bavaria + Saxony + Thailand
Age: 52
Posts: 151
|
I know some people don't like NSD.
And there were even religious wars between TD64 and NSD believers. But "Bullshit" is something else ... Quote:
Are u sure? I'm pretty sure i used 36 GB IBM SCSI hard drives with Kick 3.1 and NSDPatch before i moved on to AmigaOS 3.9. And here is the NSDPatch already included in setpatch. I'm in Bangkok now, but when i'm back home i will check what NSDPatch will support on Kick 3.1 and even on Kick 2.04. btw ... u can load setpatch and NSDPatch even from floppy. And with a patched scsi.device u would have the same "Floppy-Problem", if u don't burn an updated Kickstart-EPROM. Quote:
U must keep ur first partition below the 4GB boundary anyway if u don't use an Phase5 or Elaborate Bytes controller or a patched scsi.device in an updated Kickstart-EPROM with TD64 support right out of the box. I always had a System partition with max. 2GB and FFS and every other partition could use the remaining disk space. For large partitions i prefer SFS anyway. And i never had any problems. Quote:
And NSD would cover more devices than TD64. NSD is part is part of AmigaOS 3.5, 3.9 and 4.x anyway. Like it or not, but NSDPatch is an easy way to use large hard drives, especially with scsi.device and other devices without TD64 support right out of the box. Ciao, Rick ... |
|||
26 November 2009, 20:39 | #13 |
Moderator
Join Date: Nov 2004
Location: Eksjö / Sweden
Posts: 5,602
|
I have 7.5 MB ram right now, to make it not overlap PCMCIA memory addresses. I can add a 4MB PCMCIA ram card (if I could somehow get hold of one! :P)
The reason I mentioned WinUAE is because it seemed I had succeeded in partitioning and formatting a CF card as PFS. But when booting from it, it couldn't see the harddisk folders that FFS could see, and if I booted from a harddisk folder, it couldn't see the PFS volume. So I couldn't really do anything. It's likely that I simply messed up the install. PFS should work fine, but some parts of SFS do require 68020. Buzz will maybe have a look at recompiling the last version that has a source on SourceForge when he has time, I think. CF cards are pretty expensive at sizes over 8GB, and SSD is of course the best you can get (apart from battery-backed ram drives), but much faster than the CPU/DMA can reach. So CF cards are perfect. So if I would do it right away, I'd probably go with PFS2/3ds. Redundancy/error-fixing is not really an issue since I'm a backup-freak and it's so quick to copy even 8GB back. If partition size is not limited to < 8GB, I'll go with one partition. On the other hand, I'm using two 980MB partitions on a 2GB card with FFS, and really, it's all I need. Using a single card for all my Amigas saves tons of copying "the same old files to each card and keep them all up to date", so maybe I'll go with that and spend some time on an "adaptive startup-sequence" to cope with the differences in setups (see signature) instead. |
26 November 2009, 21:11 | #14 | |
Registered User
Join Date: Jan 2002
Location: Germany
Posts: 6,985
|
With PFS buffer size calculation is easy. It only suports a block size of 512 bytes which means two blocks are one kilobyte. I don't remember exactly but if I am not wrong the manual recommends at least 300 buffers (150 kb) for each partition but not more than 600 buffers (300 kb) even for the largest partition.
FFS is different. Firstly it supports block sizes up to 32768 bytes and secondly it runs faster the more buffers it has. 1000 or 2000 buffers can make sense when working with large files. Quote:
Edit: perhaps you gave them the same names as the partitions ? Duplicate names can cause all kinds of strange things. |
|
28 November 2009, 00:46 | #15 |
Moderator
Join Date: Jun 2001
Location: I'm behind you!
Posts: 3,763
|
Another question.
Whilst the v40 scsi.device from 3.1 supports up to 8GB through directSCSI, what about the v37 scsi.device in the 3.0 ROM? And in the 2.0 ROM? Can they support 8GB in the same way using SFS v1.84 and FFS v44 FFSTD64 without further patches? |
28 November 2009, 07:10 | #16 |
Registered User
Join Date: Jan 2002
Location: Germany
Posts: 6,985
|
Not sure, but it should work the same. HD_SCSICMD was available from the very beginning of scsi.device and the 8 GB limit arises from the way the hardware is addressed (CHS mode with a maximum of 16383 cylinders, 16 heads and 63 sectors).
37 is the version of the 2.0 ROM, so if 3.0 still uses the same version, it seems they didn't make many changes. |
30 November 2009, 18:24 | #17 | |
Registered User
Join Date: Feb 2009
Location: Glasgow, Scotland
Age: 44
Posts: 637
|
Quote:
BUT if the revision is to be read as v1 revision 84 VS v1 revision 279.... I've done this before and got it wrong so could someone enlighten please ? |
|
30 November 2009, 19:22 | #18 |
Moderator
Join Date: Jun 2001
Location: I'm behind you!
Posts: 3,763
|
v1.84 can be read as v1.084, so it's older than v1.279.
|
30 November 2009, 19:30 | #19 |
Registered User
Join Date: Sep 2009
Location: UK
Posts: 146
|
Version numbers are usually two (or more) separate numbers that just happen to be separated by dots. For example, 2.13 is newer than 2.7, but 1.10.3 is newer than 1.10
|
30 November 2009, 21:38 | #20 | ||||||||
Registered User
Join Date: Jan 2002
Location: Germany
Posts: 6,985
|
Sorry, I missed your post, so I anwser only now.
I am not about liking or not, I am about usabiliy. Quote:
Quote:
Quote:
Quote:
Quote:
Quote:
Quote:
Quote:
I do not complain about NSD in general. I only say that NSDPatch is not needed in any cases. And it does not add large harddrive support to devices which do not already have it through HD_SCSICMD. And again, if a device already supports larger harddrives by HD_SCSICMD, then it's much easier and much more comfortable to use a HD_SCSICMD file system rather than NSDPatch. NSDPatch is not needed. Nice to have, but not needed. It does not give any functionality to the average user. From a programmer's point of view it might be different, but a user can live better without it. |
||||||||
Currently Active Users Viewing This Thread: 1 (0 members and 1 guests) | |
Thread Tools | |
Similar Threads | ||||
Thread | Thread Starter | Forum | Replies | Last Post |
Performance Issue - ClassicWB Large Hard Drive Support (> 4GB) | dabone | project.ClassicWB | 10 | 13 May 2010 21:15 |
Brand new guide to large hard drive support | Bloodwych | project.ClassicWB | 4 | 17 February 2010 15:45 |
Large Hard Drive issues... | Info-Seeker | support.Hardware | 2 | 08 September 2009 12:07 |
Getting large hard drive support into Workbench 3.0/1 without idefix | Bloodwych | project.ClassicWB | 13 | 07 July 2009 23:14 |
ClassicWB Large Hard Drive Support (> 4GB) | Bloodwych | project.ClassicWB | 2 | 22 September 2007 13:54 |
|
|