Ext HDD's greater than 137GB under Win ME

[piikea]

Did you do this:

As for the BSODs, my guess is the USBHUB20.SYS v. 4.90.3000.1 installed by USB20DRV is great for VIA chipsets but not so much for Intel chipsets, which is your case. I'd like to substitute it for the one present in NUSB 3.3, which is v. 5.0.2195.6891. You can extract it from the NUSB33 installer by opening it with 7-zip. But it's best to install it from true DOS.

and nothing changed?

I haven't yet. Couldn't remember where to put it & couldn't locate the answer amongst the threads about it. Also, I am getting less blue screens & so was leaving well enough alone for the moment. It may be rather non-scientific, but in my subjective experience w/ this computer, it will balk at changes (& other things) but often adapts over time & works ok without further intervention.

* On a side note -

I have had doubts since installing extra RAM beyond 512 that it is either:

actually not being "used" - or - perhaps there is a "memory leak"

since the computer seems, if anything, slower. Especially the internet loading webpages which all the usual remedies has not improved and is not the connection as all speedtests overtime show consistently proper speeds. This "slowness" is even after reboots when system resources are 84% available.

Anyway, if anyone has any opinions please provide. Perhaps a new thread would be in order?

Edited October 18, 2010 by piikea

[dencorso]

The active copy of USBHUB20.SYS is located in C:\WINDOWS\SYSTEM32\DRIVERS.

You should rename it (say, to USBHUB20.VIA), not delete it, just in case.

Then you add the USBHUB20.SYS v. 5.0.2195.6891 from NUSB33.

This should be all done in True DOS (i. e., after booting from a floppy).

Other copies of USBHUB20.SYS may exist, and ought to be findable by searching, but are not the active one.

BTW, if you are in doubt whether more RAM is beneficial or detrimental, the simplest way to establish it is by (I) timing some assorted events like opening IE to the default page, opening a Word document and/ or an Excel spreadsheet, and other things relevant for you to create a benchmark and then (II) removing temporarily some RAM and timing your benchmark again. Then you'll know for sure, specifically for your case.

[jds]

BTW, the GDISK utility from Symantec Ghost 8.3.0.1331 is able to partition and optionally format USB drives in pure DOS, WITHOUT needing USB drivers. Ironically, GHOST itself, from the same version, which is also supposed to work directly with USB drives (without drivers), doesn't (well, at least for me). However, once you've partitioned and formatted such drives, you can then load third-party USB drivers and use Ghost that way.

Note, although the GDISK utility is strictly command line only (no menu), it is surprisingly easy to use.

3. I can (& did) (re-)format each of them (full) in Win ME. (It said to run Scandisk on them which I did not do).

I get the impression (albeit without rigorous testing) that Format in MSW only starts the formatting process, and that you NEED to run Scandisk to finish the job (complete the FAT1 + FAT2 entries).

To have a "robust" (meaning both CHS and LBA correct) partitioning, using this approach we have some limitations.

Since 16x255=255x16 we need to find Cylinder numbers on a 16 head device that "fall" on the same boundary on a 255 head one.

Since 255 and 16 have no "common divider" we have a "minimal step" of 255x16=4080.

In other words:

4080x16x63= 4,112,640 x 512 = 2,105,671,680 i.e. roughly 2 Gb

and:

256x255x63= 4,112,640 x 512 = 2,105,671,680 i.e. roughly 2 Gb

This is the "minimum" partition size you can have and all partition sizes must be a multiple of this.

There must be something I'm overlooking. What's wrong with simply? :

255x16x63 = 257,040 x 512 = 131604480 (roughly 128M)

16x255x63 = 257,040 x 512 = 131604480 (roughly 128M)

Such a minimum/multiple partition size should be OK, right?

Joe.

[jaclaz]

There must be something I'm overlooking. What's wrong with simply? :

255x16x63 = 257,040 x 512 = 131604480 (roughly 128M)

16x255x63 = 257,040 x 512 = 131604480 (roughly 128M)

Such a minimum/multiple partition size should be OK, right?

Joe.

Yep , you are correct.

255x16x63=16x255x63 allright, and that's about 128 Mb.

But, stricly speaking, the 255x16=4080, when in the 16 Heads geometry, it is beyond the 1024 Cylinder limit, thus the OS is "forced" to use LBA type partition ID's.

It is true that this would only be needed for first partition, but since the idea was to partition a big disk in 4 partitions, where it was likely that each partition was biggish, and judging from the fact that notwithstanding the spreadsheet I posted final user was unable to replicate the experiments I suggested, the "simplified" approach wasn't even simplified enough .

jaclaz

[jds]

255x16x63=16x255x63 allright, and that's about 128 Mb.

But, stricly speaking, the 255x16=4080, when in the 16 Heads geometry, it is beyond the 1024 Cylinder limit, thus the OS is "forced" to use LBA type partition ID's.

Yes, also true with 255 head geometry! [edit: actually, I'm not sure why I was thinking 4080x255x63 here, maybe needing sleep]

[Historical trivia]

The "native" drive geometry is 16 heads here because ATA aims to emulate ST-506, and the latter hardware interface had 4 head-select bits, hence a maximum of 16 heads.

Normally, the BIOS is configured to provide LBA-to-CHS translation, using the "fake" 255 head geometry, where the 255 limit is mostly due to the maximum number of heads supported by the BIOS Int 13h software interface (256, from 0-255). Now, either someone at MS couldn't count, or else somewhere it was convenient to represent the number of heads in 8 bits, so instead of having a maximum 256 head geometry, we have 1 less.

Without the above "slide of hand", the Int 13h software interface would only be able to support a maximum CHS geometry of 1023x15x63, or about 504MB (1024x16x63 sectors). With the "fake" geometry, the maxiumum capacity is about 7.8GB. Now, I don't know why sectors are numbered 1-63, since 0-63 would give a small increase in the maximum capacity via CHS addressing.

[/Historical trivia]

Now, it seems to me that restricting partition boundaries to multiples of 255x16x63 = 16x255x63 sectors shouldn't really be necessary, if we ensure that the BIOS is configured to provide the above LBA-to-CHS translation (which is standard practice anyway). Nobody these days would use "native" CHS geometry, surely? Yet reading this thread, that's what the Partition Logic utility seems to assume. I wonder if there's a way to make it support the "fake" CHS geometry, like all the other partitioning tools? That would have made this exercise (to align the partitions) simpler and more flexible.

Sorry for rambling. I guess I'm just wondering if it's really necessary to be so strict with the partition alignment (if it weren't for the apparent limitation of the Partition Logic utility, as used here).

Joe.

Edited October 25, 2010 by jds

[jaclaz]

Now, it seems to me that restricting partition boundaries to multiples of 255x16x63 = 16x255x63 sectors shouldn't really be necessary, if we ensure that the BIOS is configured to provide the above LBA-to-CHS translation (which is standard practice anyway). Nobody these days would use "native" CHS geometry, surely? Yet reading this thread, that's what the Partition Logic utility seems to assume. I wonder if there's a way to make it support the "fake" CHS geometry, like all the other partitioning tools? That would have made this exercise (to align the partitions) simpler and more flexible.

Sorry for rambling. I guess I'm just wondering if it's really necessary to be so strict with the partition alignment (if it weren't for the apparent limitation of the Partition Logic utility, as used here).

No, it was intended as a quick and dirty workaround for this SPECIFIC case of this SPECIFIC user on the SPECIFIC combo of hardware+missing software+missing experience.

If you re-read the thread you will see how OP had a "shaky at best" usb support in Windows Me, strange (I would say "queer") behaviour of RPM under DOs, so I throwed in the Partition Logic as an "independent tool".

BTW, at least on my hardware, partition logic detects external USB hard disks with the "right" 255 heads geometry.

About using "correct", or "standard", or "better be safe than sorry" settings, it usually pays.

There are more "queer" BIOSes than stars in the sky, and to it you add the awful number of mis-programming or "non-standard" programming a number of apps related to partitioning and formatting show (mind you mostly due by the actual lack of a "real" standard).

For a strange paradox, usually people with less experience usually want to have disks partitioned in the most extravagant ways, and since the ONLY value you have is the actual data you store on a device, I tend to be very, very strict (and cautious) expecially when other people's data is at risk.

Just to have an idea of what can happen - this is a "by design" feature of XP ("strict" approach) that can easily turn a disk partitioned under Vista /7 ("loose" approach) into a meaningless sequence of bytes :

http://www.boot-land.net/forums/index.php?showtopic=9897

In other words until you are positive that there is NO way that a "strict" utility/app will ever be used on the "loosely" partitioned, you'd better be "strict".

Also remember that NT based OS bootsectors are "sensible" to CHS values, in the FAT32 and NTFS versions:

http://www.911cd.net/forums//index.php?showtopic=21702&st=129

jaclaz

[jds]

Thinking more about this, I realize I was thinking of how the BIOS supports ATA (PATA or SATA) drives directly, and how this affects partitioning. I don't know how well this corresponds for USB drives, in case these are supported by newer BIOSes (as my BIOS isn't new), although it possibly still does.

At least in older BIOSes, my reference to whether the BIOS is configured to provide LBA-to-CHS translation is not quite relevant here, because in that case, it's the Windows mass storage driver that provides any support that may exist for CHS addressing, and I have no idea if/how this can be configured to choose between "native" or "fake" CHS geometry.

Until I have more certainty about this, I'll follow the safest option, as you've recommended, and locate partition boundaries for USB drives, so as to match both "native" (probably 16 for modern drives) and "fake" (almost certainly 255) CHS geometrues.

Just to have an idea of what can happen - this is a "by design" feature of XP ("strict" approach) that can easily turn a disk partitioned under Vista /7 ("loose" approach) into a meaningless sequence of bytes :

http://www.boot-land.net/forums/index.php?showtopic=9897

OMG!!!

It took quite some time to read this (and the corresponding links to further information), but it is certainly an eye-opener!

One of the references however, http://support.microsoft.com/kb/923332/en-us , has been deleted by MS! Fortunately, the Portuguese version hasn't been deleted (yet), so I read that instead and posted the following feedback :

"Firstly, WHY HAVE YOU DELETED THE ENGLISH VERSION OF THIS KB?!

Secondly, how on Earth did you figure that a starting offset of 2048 sectors for the boot record would solve alignment problems (and hence performance issues), when this is not a multiple of 63, hence isn't the start of a track (cylinder & head combination) and thereby invite incompatibility with existing O/S and tools?! Since the new large sectors are a binary multiple of 512 bytes, the new offset should have been a binary multiple of 63!"

The background to all this is that drive manufacturers have started to use 4K sectors internally, translating them into 8 regular sectors to the outside world. The implication is that all your major disk structures, also file clusters, must be aligned to the internal 4KB sectors to achieve best performance. Put another way, we need to make all our boundaries divisible by 4KB (or 8 regular sectors), as well as whatever other constraints already exist (ie., as per this thread).

So, the 128MB partition quanta we've just been discussing is fine. However, the normal 63 sector offset (corresponding to 1 track) for the boot sector isn't, this needs to increase to 63x8=504 (regular) sectors. This wastes an extra 7 tracks (441 sectors, or 221kB) but still maintains proper CHS boundaries.

What MS did instead with Vista (and now 7), is follow the 4KB multiple requirement (for performance), while totally ignoring the CHS boundaries that most of the existing O/S seem to require, and chosen a huge 2048 sector (1M) offset to the boot sector. Just a little more thought and they could easily have met all requirements. (Maybe someone rather stupid, thought 1MB was a nice round figure?)

Joe.

[jaclaz]

Just a little more thought and they could easily have met all requirements. (Maybe someone rather stupid, thought 1MB was a nice round figure?)

Sometimes decisions are not actually *taken*, they just *happen*:

http://www.imdb.com/title/tt0109830/quotes?qt0373705

(and usually in MS - no matter if "right" or "wrong" - perpetuated mindlessly ).

Just for your entertainment , a wholly fictional (unrelated) story:

http://www.boot-land.net/forums/index.php?showtopic=2362

http://www.boot-land.net/forums/index.php?showtopic=2362&st=7

jaclaz

[rloew]

Thinking more about this, I realize I was thinking of how the BIOS supports ATA (PATA or SATA) drives directly, and how this affects partitioning. I don't know how well this corresponds for USB drives, in case these are supported by newer BIOSes (as my BIOS isn't new), although it possibly still does.

At least in older BIOSes, my reference to whether the BIOS is configured to provide LBA-to-CHS translation is not quite relevant here, because in that case, it's the Windows mass storage driver that provides any support that may exist for CHS addressing, and I have no idea if/how this can be configured to choose between "native" or "fake" CHS geometry.

Until I have more certainty about this, I'll follow the safest option, as you've recommended, and locate partition boundaries for USB drives, so as to match both "native" (probably 16 for modern drives) and "fake" (almost certainly 255) CHS geometrues.

Just to have an idea of what can happen - this is a "by design" feature of XP ("strict" approach) that can easily turn a disk partitioned under Vista /7 ("loose" approach) into a meaningless sequence of bytes :

http://www.boot-land.net/forums/index.php?showtopic=9897

OMG!!!

It took quite some time to read this (and the corresponding links to further information), but it is certainly an eye-opener!

One of the references however, http://support.microsoft.com/kb/923332/en-us , has been deleted by MS! Fortunately, the Portuguese version hasn't been deleted (yet), so I read that instead and posted the following feedback :

"Firstly, WHY HAVE YOU DELETED THE ENGLISH VERSION OF THIS KB?!

Secondly, how on Earth did you figure that a starting offset of 2048 sectors for the boot record would solve alignment problems (and hence performance issues), when this is not a multiple of 63, hence isn't the start of a track (cylinder & head combination) and thereby invite incompatibility with existing O/S and tools?! Since the new large sectors are a binary multiple of 512 bytes, the new offset should have been a binary multiple of 63!"

The background to all this is that drive manufacturers have started to use 4K sectors internally, translating them into 8 regular sectors to the outside world. The implication is that all your major disk structures, also file clusters, must be aligned to the internal 4KB sectors to achieve best performance. Put another way, we need to make all our boundaries divisible by 4KB (or 8 regular sectors), as well as whatever other constraints already exist (ie., as per this thread).

So, the 128MB partition quanta we've just been discussing is fine. However, the normal 63 sector offset (corresponding to 1 track) for the boot sector isn't, this needs to increase to 63x8=504 (regular) sectors. This wastes an extra 7 tracks (441 sectors, or 221kB) but still maintains proper CHS boundaries.

What MS did instead with Vista (and now 7), is follow the 4KB multiple requirement (for performance), while totally ignoring the CHS boundaries that most of the existing O/S seem to require, and chosen a huge 2048 sector (1M) offset to the boot sector. Just a little more thought and they could easily have met all requirements. (Maybe someone rather stupid, thought 1MB was a nice round figure?)

Joe.

There is no need to deviate from the CHS standards to align Disk I/O in Windows 9x. I have already added alignment options to my Partitioning and Formatting tools. At the most, you may need to waste one Cylinder.

[M()zart]

I have just ordered a 320 Mb external USB HDD. Hope that I will not have such painful experience

Though a few days ago I have tried such HDD of my friend - unsuccessfully. It was recognized, but it was not assigned letters (partitioned into two partition, and I suspect they were NTFS partitions). I didn't have NTFS driver installed then. To simplify the situation, I'll partition my drive to a single FAT32 partition. And yes, I know about BigHDD patch

[jaclaz]

To simplify the situation, I'll partition my drive to a single FAT32 partition.

Good , EXACTLY what is NOT advised.

Unless of course:

I have just ordered a 320 Mb external USB HDD.

it is ACTUALLY a 320 Mb HD

jaclaz

Edited October 26, 2010 by jaclaz

[piikea]

The active copy of USBHUB20.SYS is located in C:\WINDOWS\SYSTEM32\DRIVERS.

You should rename it (say, to USBHUB20.VIA), not delete it, just in case.

Then you add the USBHUB20.SYS v. 5.0.2195.6891 from NUSB33.

This should be all done in True DOS (i. e., after booting from a floppy).

Other copies of USBHUB20.SYS may exist, and ought to be findable by searching, but are not the active one.

I did this in Windows but still get blue screens occasionally. Don't know how to in True DOS so ill just let it go & live w/ it. It's not that big a deal to work around.

BTW, if you are in doubt whether more RAM is beneficial or detrimental, the simplest way to establish it is by (I) timing some assorted events like opening IE to the default page, opening a Word document and/ or an Excel spreadsheet, and other things relevant for you to create a benchmark and then (II) removing temporarily some RAM and timing your benchmark again. Then you'll know for sure, specifically for your case.

Perhaps I will attempt this when I have enough free time & am feeling daring.

Thanks

[dencorso]

If you were able to substitute USBHUB20.SYS in windows (i. e.: windows didn't prevent you from doing it), It should be enough. But do check its version (by right-clicking on it, then going to "Properties", then "Version"), to make double sure you actually had success at substituting USBHUB20.SYS. If so, the occasional BSODs you're still experiencing may be ralated to other sources, but if the frequency of the BSODs is less, at least part of the problem is solved.

[M()zart]

To simplify the situation, I'll partition my drive to a single FAT32 partition.

Good , EXACTLY what is NOT advised.

Unless of course:

I have just ordered a 320 Mb external USB HDD.

it is ACTUALLY a 320 Mb HD

jaclaz

Sorry, Gb of course. Hmm... Is it not advised? I have read this thread, but I have not seen this. May be I missed something...

I have already formatted the HDD, but still haven't tried it with Windows 98 yet. May be in a couple of days.

[jaclaz]

I have read this thread, but I have not seen this. May be I missed something...

There is NOT only this thread in the world (or even on MSFN) .

If there is even a small possibility that an external USB disk will EVER be connected or booted to a system/OS that doesn't have larger than 128 Gb partition support you risk that you will get a correupted partition.

ALWAYS have a first partition (Primary, Active) below the LBA28 limit, to play safe.

jaclaz