I’ve got some embedded devices at work that expect (for instance) a 250 GB hard disk or a 400 GB hard disk, which are becoming tricky to find.
I remember that during the era of 4-40 GB drives we used to have options to jumper drives and restrict the displayed size of the drives.
Does anyone have options along those lines nowadays?
Can’t you just partition the drive to the size you need?
The devices in question don’t give us that option in software, and use neither FAT(xx) nor NTFS.
On edit:
In fact, many of them use raw access.
I haven’t seen anything like that in ages.
Fortunately, sizes in the low hundred-GBs are only starting to become uncommon - it’s not as if you’re trying to find a 200 MB MFM drive.
Seagate’s got 400 GB drives for $60 at their outlet store.
As these are somewhat esoteric applications, you might want to look for the specific model of drive - it’s entirely possible that a different 400 GB drive may have a different internal architecture (different number of platters and cylinders, for example) and the code that uses raw access may have problems if it tries to write to a physical sector that doesn’t exist.
And when you do find the drives, stock up. 
Oh, believe me, when we find a reliable supplier with the (for instance) 500 GB IDE drives specced for our house-brand product, we call them up and order 300 at a time.
Before you ask why I don’t just stock the 500 GB drives above-referenced, we work on a dozen different brands of embedded devices in the product category, with anywhere from 4 to 20 models per brand…
I’m wondering if we shouldn’t just call up one of the drive OEMs and see if we can order a custom ROM for some drives, to just make their latest-greatest drives emulate being XYZ GB…
Anyone know if the commodity hard disk market is weak or strong right now?
What happens when you plug in a larger drive?
The old jumpers existed because hard drives used to use a convoluted addressing scheme. All modern hard drives use simple, sequential LBA addressing (LBA48 for 128GB+). Software designed for a 250GB hard drive should work with 500GB, on the most fundamental level. If it doesn’t (because of a design flaw), then it probably won’t work with other 250GB hard drives that are of a different brand or series.
What he said. If these devices are accessing the drives it has to be via some sort of standard IO interface and protocol. Unless the embedded devices are set to handle just one specific drive geometry (which would be an insane design decision) you should be able to use other drives.
If this is an in-house product that you buy 300+ HD for, and are contemplating asking the HD manufacturer for custom ROM… why can’t you just get your coders to fix whatever hardcoding they have that’s limiting your choice of HD?
Unfortunately, the product where this is a real issue is not an in-house product.
For our in-house product, engineering is glad to revise the product as needed.
What I’m getting from this thread, however, is that what I’m asking about doesn’t exist in modern times with modern drives.
I’ll pursue another vector… either getting the vendor to certify more drives or testing larger drives with the product myself.
I can try slapping a 750 GB or 1 TB in one of these rigs, then putting it in a fast-drive-usage mode, and see what happens to it in a few weeks.
You really do not need to test it for a few weeks. It will either work, or not. But if you can make it read/write from gigabyte 0 up through 250, then that will be absolutely conclusive.
Also, I suggest you do not ask the vendor to “certify” anything. That will scare them. Just start with, “hey, can you ask the guys who programmed the software if there’s anything wrong with using a larger drive.” That will give you a great, free answer. (An even better one than ours.)
What industry are you in? It sounds like it’s a very over-priced and inflexible industry. (No offense to you, but such things are a major pet peeve of mine.)
Is it possible to use a 2.5" laptop HD with an adapter? I know we used to use 2.5" disks in robots that had regular (micro?) ATX motherboards w/ standard IDE connectors; it never occurred to me that there might be an appreciable difference between 2.5" and 3.5" disks (other than size).
Obviously not a permanent solution, but I’d expect to be able to get <400GB laptop disks for some time to come…
The particular products I’m working on are digital video surveillance recorders intended for business customers.
The particular products I’m writing about are, in fact, made by very inflexible, very big [1] companies with tons of divisions that don’t always talk to one another.
I suppose you nailed that one on the head.
[1] The two vendors I’m most worried about, in fact, are big enough that not only would you know them by name, but you’ve got probably got at least one product made by each one of them somewhere in your home or apartment…
Back in the day, when you had to enter the drive parameters in the BIOS, there where three numbers, cylinder, heads, and sectors. If you could experiment, maybe you can figure out what criteria really need to be met for a drive to work. For example, it may be that as long as all the numbers are as large as expected you’re OK, or maybe there’s one critical number.
Thanks for that idea. I’ll fool around with that next week.
Drive geometries are all in the past. Today there are just simple sector addresses (0-n).
Of course, a drive has other characteristics. Various optional features it might support (like power management). Or just simple stats that the software for some crazy reason expects to be one way and not the other (and checks for).
But like I said, if the latter’s a problem (and only a small chance it is), then you could have that problem with drives of the same size.
Another concern in my niche is software indexes:
One of my apps has an SQL database with a catalog of all surveillance shots recorded on the system, complete with camera names, time and transaction information [the receipt associated with your checking out at a grocery store, for instance] all associated with each picture.
If my vendor didn’t test that DB for scalability with different image counts… ick.
I’m not saying most of my products do the above; they do not!
And, as mentioned above, I should be able to test for that problem by getting a system and just beating the snot out of it with high usage levels…