Lots of junk there, never really checked it out. Thanks.
Printable View
Lots of junk there, never really checked it out. Thanks.
I Never found any reall need to Back-Up All my stuff, (n I have Loads) I Prefer to Re-Format C: & Install from scratch....ALL My Important stuff is on a Different HD + CDRs.......
Do have a Question though. This was Discovered yesterday, after downloading "AIDA 32" that someone mentioned....It shows that I have this on my Old 20Gbt Fujitsu HD.....
05 Reallocated Sector Count 24-1-1 Pre-Failure: Immenent Loss of Data is Being Predicted.....
C4 Reallocated Sector Count 24-1-1 Pre-Failure: Immenent Loss of Data is Being Predicted.....
Does the above mean that my Fujitsu is on it's way OUT.....Should I buy a New un!!?......It is attached to my PCI ATA 100......
Only got about 1.9Gbt of Downloads n Giffs n saved WordPad Files on it......It's about 5 years old...
Oh! By The Way! Did I say "Well Done for running a Good Thread".. If Not, "WELL DONE"......
I would be getting a replacement if I got that. Seems that hdd may have smart capabilities and is giving you a hint.
Crikey that was QUICK Train!.......Thanks...
I had a sneeky feeling i would have to replace it soon.....
It has Served me Well.....I will now transfer what's on it to my 40Gbt n just use it for odds n sodds till it gives up the ghost...Then Replace it with another Maxtor, about 40Gbt should do it.....Catch ya Later....Take Care....Dennis..
scarecrowdr,
From personal experience please back up you "stuff" now.
Can I ask a personal question. Do you sleep well at night? :D
Well if you stay up until 3.30am in the morning playing Commodore 64 games on an emulator, you sleep just fine.Quote:
Originally posted by greengoose1
Can I ask a personal question. Do you sleep well at night? :D
Except for when the alarm goes off at 7.00am.
And then fall asleep on the bus and miss your stop. :o
Man there were some good games about for the time.
Well said, Nix, well said. Thank Goodness for flextime :DQuote:
Originally posted by Nix
... playing Commodore 64 games on an emulator...there were some good games about for the time.
Yes, getting in to work at 9.40am probably isn't the best thing to do often.Quote:
Originally posted by K G G
Thank Goodness for flextime :D
I find it absolutely horrible to get up at 5 am to go to work....but I find it just as appalling to get up at 8 am to go to work....so I get up at 5 and get home early.. :D
The SMART feature is normally giving you a 1-2 weeks advance warning about an emminent drive failure. There's no guarantee given it will warn you in time but when it does so it's usually a good idea to take action.
Since I got a few minutes here I figured I’d pop in and add some confusion.
But first… I’d like to thank Goose and Train for starting these Delta threads again. They have been a tremendous source of information and help in the past, not to mention some good times.
Sorry for perhaps backtracking here a bit, but… Goose raised an important point related to the system bios, its role, limitations, etc. Any limitation a bios (its disk I/O components) may have in terms of its ability to handle/communicate with a drive only has importance in those cases where the bios is actually called upon to communicate with a drive (obviously). It’s often thought that the bios is the lord and master of (involved in) all I/O. In days gone by, with older Oses, this was much more the case. But for some time now the reliance on the bios I/O routines by OSes and the software that runs under them has been decreasing. Today this has reached the point where the dependence/use is basically nill. So depending on circumstances, such as how a drive is used and in particular what OS and underlying applications will be utilizing it, the significance of any bios limitation and what the options are to deal with it may not be as previously discussed here.
If a bios has a limitation (size, including the ability to address greater than 137GB drives using 48-bit LBA) there’s basically only two places where this would rear its ugly head. The first is when the bios itself, for its own internal purposes, needs to conduct an I/O operation relating to a drive. The second is when an OS or application utilizes the bios to perform an I/O operation relating to a drive (on its behalf).
Looking at the first case, pretty much the only time this applies is when a drive is being used to boot an OS off of. Here the bios must know the drive exists, and must be able to communicate with it such that it can read certain partition information, locate and load the appropriate boot record containing the OS’ boot code.
So what does this mean? Well, first of all it means that if a drive will not be used to boot off then the bios (in terms of our first case here) has no need to know anything about a drive or be able to address the areas on it. Any inherent bios size limitation is irrelevant (more on this below). But what if a drive will be booted from? Well, as long as any bios limitations do not impact the performance of the above mentioned actions, again, the limitation is irrelevant. In other words, as long as the information the bios needs (ie. partitioning, boot record) are within the size limits it can address then it can properly/successfully initiate the boot process. And in most typical instances (we’ll ignore some multi-boot caveats until later in this thread or another) this is not a problem, or can easily be accommodated without the need necessarily of overlays or add-on controls. Huh? What?
Say you have a bios that can only address disks up to 32gb. Say also that you have a 40gb drive that you would like to use and boot an OS off. Can this drive be used? Sure, all you have to do is be willing/able to set things up right. Clearly you’re gonna have a problem if you set the bios to auto-detect the size of the drive and are hell-bent on defining a single primary boot partition as 40gb. But if you’re willing to make a few adjustments… First, nothing says a bios has to be told about (or know about via auto-detecting) the full capacity of a drive. If your willing to keep the size of your boot partition at or below the maximum size your bios can handle then you can manually enter (in bios setup) the appropriate size parameters. So you could manually set the bios up to “think” the drive is any size less than 32gb (in our example here). The bios will then be happy, a boot partition (and other partitions for that matter) can be defined within the disk area (size) defined, and (once an OS is installed in it) the bios will be fully capable of initiating a boot from the partition. So it is completely possible to be able to use and boot off a given drive even if its total size exceeds the bios’ ability to handle its full size. Ya just need (be willing) to make a few adjustments.
OK, fine. But what about the rest of the space on a drive? If I only define a (say) 40gb drive to be (say) 32gb then the rest of the space is wasted/unusable, right? Not necessarily. This brings us to case two, where the dependence/use of the bios routines by the OS and underlying software comes in.
Obviously if the OS or applications under it are going to rely on the bios (its disk I/O components) to preform disk I/O then the bios has to be able to fully handle a drive. But as stated earlier, over time the dependence/use of the bios routines by the OS and applications has diminished. Up until Win95 (I’ll stick with the Windows line of Oses, but the Unix world is similar) OSes relied completely on the bios for disk I/O related operations. Thus, any bios limitation was a true limitation. But starting with Win95 disk I/O (and other) related functions began being moved in to the hands of OS code. I/O began being conducted more and more directly between the OS code and the device (disk) itself, bypassing the bios (its routines), moving the bios more and more out of the loop. Within the Win9x/ME OSes the bios is “almost” completely taken out of the loop. Within the NT based OSes (NT, 2k, XP) there is pretty much no reliance on the bios for disk I/O functions (pre-2k/XP has a little more dependence). And what this means is twofold. First, once the initial phase(s) of the boot process is past it doesn’t necessarily mater what the bios sees, thinks it sees, can handle, can address (etc). Second, if a drive will not be booted from then (again) bios limitations can often be inconsequential. In fact, for non-boot drives it may be completely unnecessary for the bios to know (be told) anything about the existence of a drive or its size.
In the case of the Win9x/ME Oses, they have roots based back in DOS. And given this there are certain times, parts and/or components with these OSes that are still reliant on the bios disk I/O services (not a lot, but…). As a result any limitations in the bios can be a factor and, therefore, may need to be considered and compensated for. For instance, during the first (relatively short) phase of the OS boot process when Win is operating in what’s called “real mode” it relies on the bios for I/O services. At this point it needs to read/load certain information/routines from disk, and the bios (routines) must be relied upon to do this. But once this is done it switches to what’s called “protected mode”, and the bios is taken (pretty much) out of the loop. So what does this mean in terms of bios limitations? Well if a drive in question is the boot drive it simply means the Win boot partition (the partition containing any files/code windows needs to load during its time in protected mode) should lie within the area/size that the bios can handle. Going back to the example above (40gb drive, 32gb bios limitation), as long as the windows boot partition is defined in the first 32gb of the disk (or less) then there’s no problem. So if we tell the bios that (say) we have a 32gb drive, define a 32gb (or less) primary partition and load windows there then all will be fine.
Now for the NT based OSes there is none of this real-protected mode stuff to worry about in terms of the boot partition. From the moment the bios loads the boot record, passes execution control to its code, and NT takes over the bios (and its limitations) become (can become) irrelevant. The only gotcha here is the fact that the bios still needs to be able to access the boot record to kick off the OS boot process. But with NT there are only 3 or four files that need to be in this partition the bios needs to access (there are quite a few more with Win9x/ME).
Ok, so assuming you can live with your boot partition being within the size limitations your bios may impose, what about that utilizing the rest of the space on a drive? What if the drive I want to use isn’t going to be a boot drive? Let’s start with the case of a drive that will be a boot drive. Where we’ve defined the drive size and set the boot partition up such that things are within the limitations of the bios. What now?
Well, with Win9x/ME once it is in real mode and running in its GUI state the potential exists for us to gain/have access to the rest of our drive (subject to certain restrictions and internal win9x/me limitations, more on this to follow). Were other partitions already defined on the drive, you could see and access them in Explorer or whatever. So say, for example, you had partitioned and formatted a drive on another computer (without bios limtations) and then moved it to your computer (with a bios limitation). You would see these other partitions, be able to read and write to them, etc. Why, how? Because Win is not (for the most part) relying on the bios for information about or for access to the drive. It is dealing with the drive directly.
But what if I want to (further) partition and format the drive on the current machine (with a bios limitation)? It can be done but there’s a “but”. As it turns out Window’s (9x/me) FDISK is one routine that depends on the bios for I/O services. And for this reason if the bios has limitations they will be passed on to FDISK. So the use of FDISK (and the dos based version of Format for that matter), even from within a dos box within Win, is limited by what ever the bios is limited to in terms of the drives seen, their size seen and addressing the areas on them. If you defined a 40gb drive as 32gb to the bios, FDISK will only see 32gb and won’t be able to see and, therefore, partition the rest. Now as it turns out, a lot of 3rd party partitioning (disk management) utilities also rely on the bios in their operation, so these would be unusable also. But there are some 3rd party tools that don’t rely on the bios (or not enough to be a problem). As I recall, the partition manager tool in Ranish is one example. Armed with these you could set up (partition and format) areas of a drive that were inaccessible to/via the bios. And once this was done you could have full access/use of your drive.
Continued in a seperate post...
Continued from above (LOL, I managed to exceed the vdr single message character count limit. Geez, forget about bios limits). Anyway...
What about Win9x/Me and a drive that will not be booted from (eg. a second, a slave drive)? Well here you can begin by setting the bios detection to None. That’s right, “none”. Setting it to none does not prevent access to the drive (unlike disabling a controller in the bios). Instead it simply tells the Bios to ignore the existence of the drive and not worry about it. Since the bios is not going to have to boot from the drive, and assuming we can (want to) only use this drive from within windows and not by any programs that rely on the bios (for I/O services), the bios doesn’t need to know anything about or worry about the drive. From here we can just proceed as above, partition and format the drive from within windows, an start using it.
Now a couple notes/caveats to the above… As stated above, there are a few windows routines that still have their routes in DOS and, therefore, rely on the bios and are subject to its limitations. For the most part these are the command-line type utilities (like Fdisk Scandisk, Scanreg, etc). The limitations in regards to these will apply whether run from a dos box in windows or from a command prompt you boot to. Likewise, there could be other applications, 3rd party software that relies on the bios directly, and therefore would be subject to its limitations. Finally, Win’s detachment from dependence on the bios is only applicable when it is running in normal mode. In safe mode it does not make use of the same drivers and such, and is much more dependent on the bios. So in safe mode Win would be subject to limitations inherent in the bios.
The steps and procedures when an NT (such as XP) system is involved are basically the same. However, under NT there is no need for 3rd party tools to partition and format things. The native tools provided can/will do the job just fine. Also, as mentioned, in general NT systems have gone much further in reducing their reliance on the bios, under all circumstances. Things like safe mode, whether you are operating in the gui vs. non-gui environment, at a command prompt or what ever aren’t an issue. The full capacity of a drive can be dealt with and accessed. There “could” be some 3rd party application that “may” be an issue. But given the architecture of NT it pretty much has (and keeps) control over everything, so the possibilities are all but nil.
OK, so what’s the bottom line in all this? Basically that even though a bios has a limitation in its ability to handle/access a particular drive size that may not be as much of an issue as one might have thought. And one may be able to deal with it even without upgrading bioses, using overlays, adding controller cards. It depends on the situation, the OS in use, etc. I’m not saying that one of these solutions may not be better or more appropriate in a particular situation. But I figured it might be worthwhile mentioning another possibility. I also thought it was worthwhile to pursue the “role of the bios” issue Goose raised. Some of this stuff also has implications/relevance to issues of multi-booting as well.
Now, while the above babblings can be applied for the most part to all bios drive size limitation issues, I’d like to give issues involving drives greater than 137gb (those requiring 48-bit LBA support to fully access) a little special/separate/additional treatment.
First, bios upgrades and controller cards were mentioned as means of adding 48-bit LBA support. There are also a couple other options available that can or might be able to provided required support. The first is the Intel Application Accelerator drivers. If a motherboard uses certain of the Intel chipsets and the operating system in use is Win9x or up then the IAA drivers may alone be able to provide the required 48-bit LBA support. In addition, if the OS in use is Win2k or XP then these operating systems have the capability inherently to support 48-bit LBA (all you need is a certain service pack and a bit turned on in the registry).
For non-boot drives and/or access to areas above the 137gb mark where 48-bit LBA is needed these solutions can be all that is needed. Particularly with 2K and XP. With 98/ME, with the IAA driver scenario, there would/could be similar issues as with drives not requiring 48-bit LBA, namely that any routines (windows or others) relying on the bios for I/O would have problems. And, again, in safe mode or if booted to a command prompt the IIAs would not be in the picture, so… Under this/these non-boot drive scenarios you could/would (as before) set the bios detection to None.
For a boot drive you can basically do what has been discussed before. You could/would define the drive size and set up the primary boot partition within the limits your bios can handle. Then later on (in windows) you would finish the process of partitioning the rest of the drive so you would be able to use it.
One quick note/warning in regard to drives larger than 137gb in Win98/ME. There “can” be certain situations/instances where because of inherent architectural limitations within the OS issues can exist with drives over 137gb even when any of the means of providing 48-bit LBA support are used. It is possible for these to result in data corruption or loss. The capability to use drives greater than 137gb (48-bit LBA) is kind of a retrofit (might even call it a kludge) in Win8x/ME. And as such…..
OK, one more final thought/point (I promise) here. The bios can be an issue in terms of being able to handle/access particular drive sizes and/or partitions within them. We can’t forget (and have seen to some extent) that the OS can impose limits as well (or instead). In some case can be dealt with in one way or another. But in others… Take one example. Even if your bios (or a controller card, or overlay) can handle say a 40+gb drive, it won’t matter if you were going to use an OS like (say) DOS6.22, or Win95. Here the limitations in the internal data structures and routines of the OS would prevent you from being able to fully use your drive (at least within the confines of these OSes or any software running under them), period. And no bios, software or controller card is gonna change that. Just another thing to consider when putting a hard drive in a system. And when dealing with particular multi-boot scenarios (but that’s another topic…).
Well I’m done now (and the crowd lets out a collective sign of relief) I apologize if I confused, bored or otherwise nauseated everyone. If I did, just remember: Bistro made me write this, so blame him. At least that’s my story.:D ;)
Wow Doc....that was a great 2 part post.
Excellent writing DrMDJ, very understandable and informative !!! I learned a boatload.
You aren't a professor by any chance :)
Good Morning All,
I spent the most of the morning digesting what DrMDJ posted. Nice to have him back in the area. That looked like an article about everything you wanted to know but didn't think anyone else did.
DrMDJ - glad you are back - I think - let me read that one more time. :D :D
Nix, last weekend i saw a Commodore 64 and it was working. Living history at work. :) Probably if you and Kallikru had a more ordered life etc. etc. :D
Thanks DrMDJ. That describes several conditions that I have experienced but could never find any explanation for. Now I'm spurred to do s'more testing along these lines... :)