20GB Hard Drive takes a while to boot?

[gizz72]

Greetings,

Hi everyone, I'm using my good ol' IDE Fix, and never had not much problems so far with it. I have an old 850Mb IDE Hard Disk, then a 2GB Hard disk, recently accuired a slightly used, and 20$ cheaper 20GB Hard drive.

The first 2 hard drives I mentioned only takes less than 10 secs(approx) upon COLD booting(Switching ON, not reset). My new 20GB hard disk takes almost 30 secs before it boots up? Well warm reboots would only take less than 10secs.. :-?

I'm using WB3.9 on my 20GB HDD, I have 2GB Partitions which totals 18GB free space. So DH0.... DH5 uses 2GB each. But I leave the rest unpartitioned for the moment to save some chip ram. I hardly scratch the surface of this huuuge storage yet, but I'm just not quite happy about the way it cold boots.

I've already made the File system to OFS. Before Int'l-FFS seems to be making it unstable and always validates!

Does this always happens to Hard drive larger then 4 GB?
Are there any ways to make it faster to boot?

Any comments would be appreciated. 'Size does matter'!!

Regards,

GiZz72

[adolescent]

Is the drive jumpered correctly?  (ie. if a single drive, is it set to master?)

[gizz72]

Greetings,

adolescent wrote:
Is the drive jumpered correctly?  (ie. if a single drive, is it set to master?)

Yes it's set as a single drive. It's set at primary master. It would never work if it's set incorrectly.

The IDECDRom is my secondary Master.

Regards,

GiZz72

[doctorq]

I've already made the File system to OFS. Before Int'l-FFS seems to be making it unstable and always validates!

Hmm, you will regret this bigtime along the way. I suggest that you switch back to FFS. If the disk validates, it is because the data stream as been inturupted.

Maybe try installing SmartFileSystem instead.

If you use OS3.9 you can make your boot partition around 250 MB, and make another partition out of the rest of the partition if you are worried about chipram. It is correct that each partition eats ram, but then lower the values of buffers for each drive.

[Thomas]

HDD partitions don't use chip ram (would be faster without buffers at all then). They use fast ram for sure.

I doubt you manage to use OFS on a HDD. OFS cannot handle partitions bigger than 8MB or so.

Get Check4GB from Aminet to check if your partition setup is correct. Even if it is, post the output here, so we can see what we are talking about.

http://main.aminet.net/search.php?query=check4gb

Bye,
Thomas

[gizz72]

Greetings,

doctorq wrote:
Maybe try installing SmartFileSystem instead.

Ok I'll see to it I'll revert back to FFS and notice anything more wierd than usual happens. I have not tested it yet. I'll give it a whirl!

If you use OS3.9 you can make your boot partition around 250 MB, and make another partition out of the rest of the partition if you are worried about chipram. It is correct that each partition eats ram, but then lower the values of buffers for each drive.

My system partition is ATM 300MB. Maybe lowering buffers would slightly solve the problem. I set it at 250. The default was 30.

Does it slows the access time down when the the buffer is at a lower setting?

Hmm, you will regret this bigtime along the way. I suggest that you switch back to FFS. If the disk validates, it is because the data stream as been inturupted.

Believe me, I spend sleepless nights just trying to format a 2GB partition! :-O

Regards,

GiZz72

[gizz72]

Greetings,

Thomas wrote:

HDD partitions don't use chip ram (would be faster without buffers at all then). They use fast ram for sure.

I doubt you manage to use OFS on a HDD. OFS cannot handle partitions bigger than 8MB or so.

Get Check4GB from Aminet to check if your partition setup is correct. Even if it is, post the output here, so we can see what we are talking about.

http://main.aminet.net/search.php?query=check4gb

Bye,
Thomas

Thanks Thomas, I'll try it out tonight and try to post it online tomorrow.

Regards,

GiZz72

[glitch]

Hi,

     I may be WAY off here...  Do any of you people remember the old fix for drives that wouldn't be recognized because the Amiga (A600/A1200/A4000) booted quicker than the drive was ready?  You would do a warm boot right after and things would be fine.  All you had to do was cut the pin 1 line on the IDE cable and this fixed the problem.  Do you think this may help here?  If you have a spare 40 pin cable lying around, you might give this a shot anyway...

-G

[srg86]

I wonder if the MaxTransfer setting has anything to do with this?

srg

[TjLaZer]

I have a 20GB IDE in my A4000 and it just flies!  I have it set at 4GB for DH0:, 6GB: DH1: and 10GB DH2:  Works fine.  OS3.9, BB1 ROM Update file.

[gizz72]

Greetings,

Well, I'm back from the offline world! :-D Anyway, I've downloaded the Check4gb and save it to a log file. BTW, I've included here the filesystem chart that came with it for everyone's guide.

Here's the FileSystem Guide.

PFS  0.0  TD64 -   -       Professional File System
PDS  0.0  -    -   SCSI    Professional File System Direct SCSI
DOS 45.0  -    NSD -       FastFileSystem OS 3.5
DOS 43.0  TD64 -   -       FastFileSystem Phase5 Patch
SFS 1.187 TD64 NSD -       SmartFileSystem by Joerg Strohmayer
SFS  0.0  TD64 NSD SCSI    SmartFileSystem by John Hendrikx
FAT  0.0  TD64 -   SCSI    Win95/98 compatible file system
SWP  0.0  TD64 NSD SCSI    Linux Swap Partition
LNX  0.0  TD64 NSD SCSI    Linux Root Partition
USR  0.0  TD64 NSD SCSI    Linux User Partition
*
* The following entries are for those who don't read manuals and
* install all file systems with HDToolbox's default 0x434653 (CFS)
*
CFS 19.0  -    -   -       unknown file system
CFS 18.0  TD64 -   -       Professional File System
* Note: PFS2/3ds cannot be recognized by version !
CFS  2.0  -    -   -       unknown file system
CFS 1.187 TD64 NSD -       SmartFileSystem by Joerg Strohmayer
CFS 1.80  TD64 NSD SCSI    SmartFileSystem by John Hendrikx
CFS  0.0  -    -   -       unknown file system

And here is my FileSystem Log entry:

Name     Volume       Size Device       Unit Version  DosType  Version   Big Check
CD0                   685M atapi           2 119.5    CD01     42.23      no ok
CC0                    20K carddisk        0 40.1     DOS1     45.13      no ok
MEMORY               2718G memory          0          DOS1     45.13     yes *
MS1                   720K mfm             1          FAT0     3.11       no ok
MS0                  1440K mfm             0 40.9     FAT0     3.11       no ok
DH0      Amiga1      2015M scsi            0 119.4    DOS0     45.13      no ok
DH1      Work        2014M scsi            0 119.4    DOS0     45.13      no ok
DH2      BackUp      2015M scsi            0 119.4    DOS0     45.13     yes ok
DH3      Work_1      2019M scsi            0 119.4    DOS0     45.13     yes ok
DH4      Empty1      2018M scsi            0 119.4    DOS0     45.13     yes ok
DH5      Empty2      2018M scsi            0 119.4    DOS0     45.13     yes ok
DF0      Install3.1  1760K trackdisk       0 40.1     DOS0     45.13      no ok

I hope this would help you guys to check if there's something wrong with my HDD?

@TJLazer
 I'm sure your CPU is a 040 which would make it fly tho.. Mine is just a 030 Viper. Not much, I know..

Regards,

GiZz72

[platon42]

1. Don't use OFS. It will slow down the drive big time (each data block needs to be copied around) and you have less space on it. Use FFS-Intl (NOT DC) or SFS instead.

2. Don't use block sizes of 512 on big partitions. This will increase the size of the free blocks bitmap considerable (and that's probably what takes so long to load on bootup). Moreover, these small block sizes increase the space overhead on big files and the seeking time overhead. My suggestion is to use 4KB Blocks for <2GB partitions and 8KB above.

3. Use less partitions, but bigger ones. Each partition will take away ram for its buffers (take care that the amount of ram required for the buffers == buffers*block size).

4. My suggestion to be on the safe side:
- Use a small (e.g. 100-200MB boot partition with FFS-Intl). Block size 1024 KB.
- Create another working partition for your programs that fits nicely below the 4GB border (e.g. 3,8GB) with FFS-Intl. There are enough recovery tools that will be able to fix stuff, if {bleep} happens. Blocksize 4KB. (if you wish to run other operating systems like Linux, NetBSD or MacOS/Shapeshifter, leave some space for it in the lower 4 GB).
- Create a third partition with the rest of the space using SmartFileSystem and 1KB Blocks.
- (Optionally, create a small (e.g. 100MB) partition TMP: for temporary files like IBrowseCache using SFS).

[gizz72]

Greetings,

@Platon24
Okey I'll take your advice, It'll be awhile to try these settings. Wish me luck.

@all
I'll post again of any further developements. Thanks for your inputs. Thank you. ;-)

Regards,

GiZz72

[Framiga]

2. Don't use block sizes of 512 on big partitions. This will increase the size of the free blocks bitmap considerable (and that's probably what takes so long to load on bootup). Moreover, these small block sizes increase the space overhead on big files and the seeking time overhead. My suggestion is to use 4KB Blocks for <2GB partitions and 8KB above.

are you speaking about FFS, i suppose.

No need to use large blocksize with SFS . . .anyway NEVER over 1024.

Bye :-)

[platon42]

@framiga:

Yup, was talking about FFS. Increasing the blocksize of SFS partitions normally has some drawbacks, because the B-Tree splitting/reordering will consume more cpu power than with smaller blocks. The IMHO only advantage is that it will cause less scattering of admin spaces across the harddisk (and I also think the maximum number of entries inside the .recycled drawer depends on the blocksize).