Sign in with
Sign up | Sign in
Your question

See a future problem with SATA drives?

Last response: in Storage
Share
August 2, 2009 3:32:49 AM

I am in the process of converting 3 PCs and 2 NAS units over to SATA.

The problem I can see if I have to reinstall XP in the future is it doesn't see the full size of the 1T sata drives until I have installed sp1.

If that is the case, and I have verified by simulating a boot with the xp disk like I was starting from scratch, I can not see the additional D, E. F, etc partitions where data is stored.

If I continued I am doubtful they would magiclly be there after a fresh intall of xp.

So the question then becomes, how do I make the cpu/mb and xp see the full size and existing partitions so I don't trash all my existing data?

There is a floppy disk with drivers I can make to use during boot, but it is for raid which I am not using.

Thanks for any replies,

John
August 2, 2009 4:06:38 AM

Yo dawg

one method of doing this is by slipstreaming all of the service packs into xp,
also it is important to know whether or not you are using sata controllers that need to have drivers installed to function under windows xp.

to learn more about slipstreaming check HERE
http://www.winsupersite.com/showcase/windowsxp_sp2_slip...
August 2, 2009 10:13:27 AM

I was able to solve my problem. I'll tell you this sata stuff is a throwback to the beginning when we had to format MFM drives with a dos debug command for pc-xt 086 comptuers. This sata stuff is crap.

It should be much easier than this.

Well, I tried to use the floppy raid driver disk with the F6 during install. It enabled it to see the entire sata hard drive.

It would go through the entire install but on reboot it would blue screen. No doubt the raid driver.

I know from experience that xp will install but not see the entire drive. Then when you add sp1 it will see the entire drive. But it is good to install sp2 because it is supposed to have some ahci drivers for sata.

So I figured it would be good to do a slipstreamed xp sp2 install. I had a heck of a time making one because I kept getting the code 5 error. Upon learning about the nero 4 instead of 1 on the boot file screen all was good.

I just re-installed with the new slipstreamed sp2, but also had to use the floppy driver so I couuld see the entire drive, and so far all seems good.

PS: the reason I had so much trouble was I had an sp1 directory on the xp cd and if I slipstreamed sp2 combined with the sp1 dir it was to big ro fit on cd.

If you have a standard xp disk and download the sp2 file use autostream. A good program that does all the work for you.


John
Related resources
a b G Storage
August 2, 2009 10:55:20 AM

Misinformed idiot

SATA is not the issue, its your dinosaur OS - pre SP2/3 windows xp - if you read up and actually did some research using google you might actually learn that it has nothing to do with SATA.

If sata ports are in a native ide mode then windows doesnt know or care wether the hdd is sata or ide, and you THINK its a sata problem because larger modern hdd's are all SATA where as its the size not the interface etc.

As for AHCI/RAID support - thats xp's age showing - vista usually will detect and use ahci controllers like normal etc - thats the os age difference, and AHCI does offer benifits for modern systems.

As for solutions - create a smaller patition and resize it AFTER the install is complete etc, and maybe use sata in the native ide mode etc.
August 2, 2009 1:10:16 PM

jake60 said:
It should be much easier than this.


Hate to say it, but if you installed an OS that wasn't almost a decade old, it would be easier :p 
August 3, 2009 3:59:29 AM

apache_lives. You should go back to the original post and reread the problem. Size only counted because windows didn't see the entire size. Your solution didn't account for the original problem.

If Hate to tell you but sata is the issue. In general that is.

It looks to me to be the same old cluster F*** like so many changes that have taken place over the years. It looks to have been implemented piecemeal.

Many mother boards do not have plain sata as an option, they either are raid or ide. A person can only deal with what they are presented with.

Do not be so stupid as to call people idiots when you are only looking at things through your narrow view. Just because they are not using or doing what you are doing is no reason for name calling. It only shows your own idiotcy.

There are reasons to run xp, even though old, instead of vista or other platforms. I know people that run w2k because they believe it is the most stable os of windows.

I still have a msdos 6.22 bootable partion for programs I wrote 25 years ago that city governments are still using.

One of the major problems is microsoft and the hardware manufacturers do not inform the public about specific details of their products. They think they are protecting trade secrets when in fact they are confusing people in the use and limitations of their products. hence it gets implemented piecemeal.

A lot can be laid at the feet of microsoft. They don't like to do anything until there is a large demand. I mean, usb2 wasn't fully implemented until xp sp1?

And what is with labeling sata as an ide if it isn't a raid setup? It looks to be more scsi than anything. scsi was around at the same time as mfm. It was faster than mfm and mostly used in business applications because it was so much more expensive.


[Defaults]
scsi = VCOMBORAID_I386_NT5


[SCSI]
VCOMBORAID_I386_NT5="VIA VT8251/8237/8237A/6421/6410 SATA RAID Controller(Windows XP/SRV2003)"
VCOMBORAID_I386_WIN2K="VIA VT8251/8237/8237A/6421/6410 SATA RAID Controller(Windows 2K)"
VCOMBORAID_I386_NT4="VIA VT8251/8237/8237A/6421/6410 SATA RAID Controller(Windows NT4)"

[Files.SCSI.VCOMBORAID_I386_NT5]
driver = D-I386-NT5-RAID, viamraid.sys, CFG_NT5
inf = D-I386-NT5-RAID, viamraid.inf
catalog = D-I386-NT5-RAID, viamraid.cat

[Files.SCSI.VCOMBORAID_I386_WIN2K]
driver = D-I386-NT5-RAID, viamraid.sys, CFG_NT4
inf = D-I386-NT5-RAID, viamraid.inf
catalog = D-I386-NT5-RAID, viamraid.cat

[Files.SCSI.VCOMBORAID_I386_NT4]
driver = D-I386-NT4-RAID, viamraid.sys, CFG_NT4
inf = D-I386-NT4-RAID, viamraid.inf
a c 357 G Storage
August 5, 2009 6:41:19 PM

Your main problem is the size of the hard drive, NOT a SATA problem. The separate issue of access to SATA devices of any size I'll address later.

Up to the early 1990's access to a hard drive was done as part of the work of the OS and CPU, and they had to specify the Cylinder, Head and Sector co-ordinates to access a part of the disk containing the data required. As hard drives got larger, however, that became a problem because the maximum value of each of these three was an addressing limit. Rather than just extend the system, a new system was devised which turned over the addressing function to a dedicated controller built into the hard drive. The OS used a single binary number to specify the desired location (just a sequential numbering system for all the sectors on the disk), and the disk itself translated that into the traditional 3 co-ordinates, but using larger numbers to do it. It was called LBA for "Logical Block Addressing". At the time it was implemented in the mid-90's, they chose to use 28 binary bits in the LBA address, which would allow specifying at most 268,435,456 sectors, or 128 GB as M$ counts the term "GB". At the time, hard drives were typically 300 to 800 MB, and headed towards the huge capacity of 2GB! Future expansion was anticipated.

Wooops! By the end of the '90's it was clear that hard drive makers soon could do drives over that 128 GB size, and a new version of LBA was developed that uses 48 bits in the LBA address, not 28. This would allow drives up to 131,072 TB (right now we're using 2 TB max). To work, this new addressing scheme has to be implemented ("supported") in three places: in the hard drive itself, with its on-board controller that receives and decodes it, in the mobo hard disk controller that sends the address out, and in the Operating System that has to generate the address. The new system began to be implemented in updated hardware in the late '90's. On mobo's with hard disk controllers built into their chips, some could do it simply by updating the BIOS coding, and hence you see advice about "update your BIOS". Others could not do this, and a replacement add-in hard drive controller card was needed. At the hard drive itself, no upgrading was needed for older smaller drives, but obviously it was built into any drive over 128 GB. At the OS side, Win XP already was under development and its first release did NOT include 48-bit LBA support. However, it was added with Service Pack 1 and, of course, maintained in SP2 and SP3. M$ even went back one generation and added it to a late SP for Win 2000.

SATA was under development at that time, too, so 48-bit LBA support was included in the specs, both for hard drives and their mobo controllers, from the very beginning. ALL SATA systems support 48-bit LBA.

Yours is a common situation. With SATA devices you have 48-bit LBA support at the two hardware levels, but not in your older OS, Win XP original. You have three choices. The simplest is to install XP to a large hard drive, recognizing that it will NOT create a boot Partition larger than 128 GB (can be smaller if you choose it). Then you update your Win XP to SP3. With that in place you can use it to create some new Partitions in the Unallocated Space of the hard drive, which will serve as separate drives with their own name(s). Or indeed, you can install to a smaller boot drive, upgrade, and then use large (over 128 GB) drives only as data drives. This way you can not BOOT from a large hard drive, but you can use them after booting from a smaller one.

Apache_lives' last sentence is misleading. Using SATA in "native IDE mode" does NOT solve your size issue. Installing old XP, updating it, and then expanding the original C: drive Partition is a possible route, but NOT within Windows alone. Windows can expand Partitions, but for its own safety it refuses to to that for the BOOT Partition. It can be done with third-party software tools like Partition Magic and with a few free shareware tools, if you want to go that route.

To escape all this and have full 48-bit LBA support from the outset, you can do it in two ways. The simplest of these is to buy a new version of Win XP with at least SP1 included, preferably even newer. Only problem is, it will cost you a bit of money. But with that you CAN install to a large hard drive as your boot drive, making your Primary Partition as big as you and the drive will allow.

The last option is Slipstreaming. This is a perfectly legal and free way to update your existing licensed XP (original) Install disk to a new one that has all the Service Packs included. It will take you some time and work, but you will end up with a new CD-ROM disk burned yourself which is your Win XP Install disk for all future use. Then you use it to install XP, just as if you had purchased a new version.

Now, the issue of how to use SATA drives at all is separate from the size issue. And even if you get a SATA drive working with drivers, etc, you still cannot use the large ones without 48-bit LBA installed as above.

All hard drives need a software driver added into the OS (Windows), just like any other device. But for a long time, Windows has arrived with the IDE device drivers installed already - just no other hard drive drivers. Back at least in early 1990's it became clear users might want to use other hard drive systems (like SCSI or RAID) as their boot devices, so the Windows Install system was modified. Early in the process a screen pops up to ask whether you want to add outside drivers to Windows, and you do that by pushing the F6 key, then following instructions. The problem, though, is that it only allows installing those drivers from a FLOPPY disk. If you do this, the driver and its abilities are added into Windows right then. They become a permanent part of the Windows you install, and they are available right away for the Install process itself.

When SATA devices first entered the market this existing system was used. Thereafter, however, mobo makers started to eliminate floppy drive ports in response to decreasing popularity of those devices among users. That could have been a major problem, except that many offered a good solution instead. Within the mobo BIOS they offer three options for how a SATA port is used. One is RAID controlled within the mobo's own chipset, and this still requires installation of outside drivers, as well as use of the RAID utilities to create and manage the array. A second choice is "native SATA" operation, with or without AHCI capabilities. This also requires driver addition. The novel third choice was to have the mobo take over the low-level control of the port to make it appear to the outside world (that is, to Windows etc.) as if it were simply another IDE port which Windows already knows how to use! This is called IDE Emulation - and no, it is not "native IDE mode". With this mode you don't get the advantages of AHCI, which are unimportant to many users anyway, but you do NOT need to add special drivers! So you get to use the SATA device(s) with no trouble and can install Windows in any version. As I said, though, you still cannot use disks over 128 GB unless you upgrade the OS to support 48-bit LBA.

The ability to use SATA, a new device standard, needs to be resolved in the OS. In the case of Win XP which was already being deployed as SATA emerged, no device drivers were ever built into Windows, but the SATA makers ensured there was a good way to use their devices, anyway. Since then VISTA and Win7 have included native SATA device drivers as part of the basic ability, just as IDE was included, and no extra driver is needed to install those operating systems using native SATA mode (note IDE Emulation is not needed there). I'm not sure if native AHCI mode drivers also are built in, too.

Large hard drive sizes are not a SATA issue - it is an issue for all large drives. Use of a new type of hardware device called SATA requires integration of hardware and OS software which has been done after the new devices were brought to market. For those caught in the interim situation with an older OS, the tools to adapt are readily available and relatively simple, even if you choose not to spend money to update to a new OS.
a c 127 G Storage
August 5, 2009 7:49:04 PM

Didn't read whole thread but XP SP1 supports 48-bit LBA which means it supports disks up to 2TiB (fdisk partition limit). So XP SP1 or later would read all disks up to 2TiB.

The original version of Windows XP (also called "RTM"), does not support larger drives than 128GiB. If your C drive is lower than that, it would boot. But it cannot access any data or partitions beyond the 128GiB boundary.
a b G Storage
August 5, 2009 9:07:21 PM

Here's what I would do:

(1) buy an 80GB like this WD from Newegg:

http://www.newegg.com/Product/Product.aspx?Item=N82E168...

You may need to downgrade the interface speed
by adding a jumper to pins 5 and 6:

http://www.supremelaw.org/systems/wd/western.digital.ju...
(see Figure 2.)


(2) freshly install your (antiquated) OS to this (small) HDD:
size C: any way you choose -- 30GB is more than enough for XP;


(3) after your XP/Old is installed and working AOK,
keep repeating Windows Update until your OS
is completely up-to-date with all Service Packs;

(3a) at this point, you can cable your larger SATA HDD
to SATA2+, and format at least 1 partition
that is the same size as, or larger than, the C: partition
you created on your 80GB SATA HDD;


(4) run a drive imaging program like GHOST and
write the output file to your second HDD, preferably
to a second data partition on your larger SATA HDD
wired to SATA2;


(5) switch your SATA1 cable to your
larger/newer SATA drive, and switch
your SATA2 cable to your 80GB HDD;


(6) run the GHOST Restore task and
restore your drive image file to the primary
C: partition on that larger SATA drive;


(7) as an added option, reformat your 80GB HDD
and create a contiguous "pagefile.sys" using the
freeware program CONTIG; remember to change
its attributes: attrib pagefile.sys +A+S+H


(8) move your swap file "pagefile.sys"
to this new swap file, where swapping I/O
will use the shortest possible armature "strokes"
because pagefile.sys is assigned to the lowest
possible sector addresses in that partition.


MRFS
a b G Storage
August 6, 2009 1:44:10 AM

jake60 said:
apache_lives. You should go back to the original post and reread the problem. Size only counted because windows didn't see the entire size. Your solution didn't account for the original problem.

If Hate to tell you but sata is the issue. In general that is.

It looks to me to be the same old cluster F*** like so many changes that have taken place over the years. It looks to have been implemented piecemeal.

Many mother boards do not have plain sata as an option, they either are raid or ide. A person can only deal with what they are presented with.

Do not be so stupid as to call people idiots when you are only looking at things through your narrow view. Just because they are not using or doing what you are doing is no reason for name calling. It only shows your own idiotcy.

Sorry, but SATA is not the issue. You'd have exactly the same problems with a PATA drive that was >128GB. The difficulty is in the addressing capability of XP pre SP1, not the drive interface. If you weren't using an antiquated OS, you wouldn't have any trouble. Vista and 7 even support AHCI and RAID with no additional drivers. As for marking SATA as IDE? There should be 3 options in your BIOS - IDE, RAID, and AHCI. IDE acts exactly like an old PATA drive in how it responds to commands and what commands it supports. AHCI stands for Advanced Host Controller Interface, and supports all of the new SATA commands and features, such as native command queuing. RAID is almost exactly like AHCI in what it supports, other than the fact that it supports RAID volumes.
!