dale.j

Wanting to attach more than 4 HDD's would require two Promise ATA/133 cards, and they currently run $90 CAD each plus 14.5% taxes .... not to mention using IRQ's ... One *could* have done it that way. I chose not to. However, no need for others to follow in my footsteps without passing on at least *something* learned.

Re: ATA/133 versus 48-bit LBA. I was led to believe that to access HDD's over 137 GB, I needed a ATA/133 capable host adapter. This is not the case. My recent posts are to clarify this issue for others, having been led down the garden path. I could have saved myself both money & time in changing over the motherboards from the A7V133 to the A7V333. All one needs is a BIOS that has been revised [if it is possible] to support 48-bit LBA. Apparently, the ATA/133 is an attempt to get higher bandwidth through-put to HDD's, which by my experience, is barely noticeable. My speculation is that the bandwidth of the PCI bus is maxed out at 133 MB/sec, and trying to access 100% of that bandwidth *just* for the HDD is a fruitless chase... This difference between what was necessary to access HDD's over 137 GB was not made clear to me. So far, the only advantage to me of the A7V333 is DDR RAM, capable of PC2700, or 2,700 MB/s bandwidth -- a considerable jump over the SDRAM. *IF* someone wants a trolley-load of toys, [particularly I/O] 1394, USB 1.1 & 2.0, ATA/133, on-board audio & NIC, and AMD XP capable... then by all means, this is a wonderful such toy...

http://usa.asus.com/inside/Techref/48bithdd.htm This URL is a list of ASUS motherboards, and the associated version of BIOS that is required to access over 137 GB HDD's.

Apparently the key to accessing HDD's over 137 GB is a BIOS that is capable of 48-bit LBA. The older version of this motherboard, the A7V133, *WITH* BIOS 1008 will access the entire 160 GB HDD, using Win98. I'll be getting around to trying other O/S's shortly. Here's a little info from Promise about 48-bit LBA: http://www.promise.com/company/press_news_detail_eng.asp?press_id=36

If it's on the Internet --- one must digress? ) Anyhoo... Disk Administrator is a Administrative Tool within NT 4.0 & Win2K. I perhaps could get my hands on Partition Magic, but Disk Administrator is an integral part of the O/S, and if DA can't see the whole drive, will it matter that PM can? Dunno,... Still have to attempt to recover the O/S, and if not re-install... this being the [currently] shortest path to a solution, and with luck, may trip across a solution... insight... while I'm meditating during the file transfer process.... Hang tight onto your favourite O/S strings whilst I get some sleep, go about a 'normal' day, get back here.... and give it a shot... and keep this current 'hot' thread going.... until a solution pops...

Perhaps I could be an "idiot," or as I had posted earlier "...it's cheap enough, and I happen to know just enough to know how to get done what I want to do." I had always believed that I would NOT mind learning Linux &/or Unix, however, it's not simply a matter of a File Server here. It's an network & an IIS server, one with logon & Password authentication. Can anyone offer free time to train me, and then trouble shoot, at my beck and call, until I get up to speed & continue with this project? Sound like all I need is to stop *everything,* and learn Samba, Apache, Linux, and whatever it takes to run a NewsGroup Server... sweep the floors, cook breakfast, lunch & dinner, dust, empty the garbage, make DOE to pay the rent with, put gas in the car, have time to date, pay for lunch.... gee...! sounds so simple... Am I talking to a Guru here? Haven't exactly convinced me that your solutions are all that quick, neither spent any time offering a solution.... "I do not pretend to know what many ignorant men are sure of." -- Clarence Darrow

Repair replaced most of the 100+ files requested to be restored. [How did upgrading the VIA IDE driver cause so much corruption?] Some files were missing information, so all I could to is cancel through. I may need to attempt to repair a couple of times [which I will try first]... but I may just need to rebuild the O/S partition... just as well. May finally get this working properly anyways.... At least the data was on different partitions (& mirrored) - at least the data on the same drive as the O/S. The data on the other drives should be ok... l8tr...

BTW... *now* I need to get rid of the BLUE SCREEN dump, and get back into the O/S... and there are other pressing items... So this may take a bit....

I'll redo these URL's for the benefit of others... http://usa.asus.com/inside/Techref/48bithdd.htm Appears to support evidence that you don't even need the latest A7V333 to access "48bit Large HD." The A7V133 may have been capable, with a 1008 BIOS update... The Maxtor either is running Clustered Servers, or JavaScript which complicates the capturing of a selected page within their web-site... On the topic of the MBR, I am definately weak on... there are 63 sectors in that "0" track, which I have yet to completely understand... I do know that once I can get the O/S up and running (either NT 4 or Win2K) and primary or extended partitions have become deleted (accidently or on purpose), I can use "dskprobe.exe" on either to both find the backup NTFS sector for all the partitions and re-write them back to the FIRST (or original) sector for each partition, and be able to re-access the data from those recovered partitions... The MS KB Q114841 goes into depth explaining the Boot process, and then differences between IDE, Extended IDE, and SCSI, all of which I am not familiar with: http://support.microsoft.com/default.aspx?scid=kb;en-us;Q114841 Windows NT Boot Process On Intel-based computers, the system BIOS controls the initial operating system boot process. After the initial Power On Self Test (POST) when hardware components are initialized, the system BIOS identifies the boot device. Typically, this is a floppy disk or a hard disk. In the case of the hard disk, the BIOS reads the first physical sector on the disk, called the Master Boot Sector, and loads an image of it into memory. The BIOS then transfers execution to that image of the Master Boot Sector. The Master Boot Record contains the partition table and a small amount of executable code. The executable code examines the partition table and identifies the active (or bootable) partition. The Master Boot Record then finds the active partition's starting location on the disk and loads an image of its first sector, called the Boot Sector, into memory. The Master Boot Record then transfers execution to that Boot Sector image. Whereas the Master Boot Record is generally operating system independent, the Boot Sector of the active partition is dependent on both the operating system and the file system. In the case of Windows NT and Windows NT Advanced Server, the Boot Sector is responsible for locating the executable file, NTLDR, which continues the boot process. The only disk services available to the Boot Sector code at this stage of system boot up are provided by the BIOS INT 13 interface. The Boot Sector code must be able to find NTLDR and file system data structures such as the root directory, the File Allocation Table (FAT) in the case of an MS-DOS FAT volume or the Master File Table in the case of an NTFS volume. These must be present within the area of the disk addressable by the 24-bit side, cylinder, sector structure used by the BIOS INT 13 interface and the partition table. This limits the size of the system partition to 7.8 gigabytes regardless of which file system is used. NOTE : Other constraints may apply depending on the computer hardware and file system. Some of these constraints are discussed below. In order to accommodate partitions larger than 7.8 gigabytes, Windows NT ignores the values in the Starting and Ending sector address fields of the partition table in favor of the Relative Offset and Number Of Sectors fields. This provides eight additional bits to represent sectors. These additional bits allow partitions to be described with up to 2^32 sectors. With a standard sector size of 512 bytes, the 32 bits used to represent the Relative Offset and Number of Sectors translates into a maximum possible partition size of 2 terabytes or (2,199,023,255,552 bytes). When partitioning a disk, Windows NT will write the correct values to the partition table fields whenever possible. When the total number of sectors in a partition exceeds the number which can be described in Side, Cylinder, Sector notation, Windows NT writes the maximum permitted values to these fields in the partition table. This prevents the system BIOS from attempting to calculate the Starting and Ending addresses based on erroneous data. For example, assume you have a 3.5GB SCSI drive attached to an Adaptec 154x series SCSI controller. If the extended sector translation feature is disabled on the adapter, it might report the following disk characteristics to the system BIOS: Cylinders: 1023, Sides: 64, Sectors: 32 which translates to about 1 gigabyte. With the extended translation enabled, the device might be reported as having these characteristics: Cylinders: 435, Sides: 255, Sectors: 63 which translates to about 3.5GB. Once Windows NT is up and running, it uses its SCSI drivers to directly interact with the disk without using the BIOS INT 13 interface. So, during normal operation the BIOS parameters are largely unimportant. However, the differences are critical if the disk is to be formatted with a single partition and used as the boot drive. Without extended translation, Windows NT notices that the disk is larger than the BIOS parameters indicate. When Windows NT partitions the drive during initial installation, the starting and ending sector addresses will be filled in with their maximum possible values. This makes it impossible for the Master Boot Record code to function correctly despite the fact that the drive is less than 7.8 gigabytes. With extended translation, Windows NT will be able to write valid values for the starting and ending addresses into the partition table, and thus, the partition remains bootable. [complete text at URL]

http://www.promise.com/support/mix_dwn_eng.asp?product_id=88&family_id=2 Is drivers / documentation / reviews on ATA/133, Promise TX2000 installation. Loaded IDE Tools from Promise, because I noticed that the "viadsk.sys" driver was dated around april 2000, and now I get blue screen dump when the O/S boots up. CAUTION! Will update ....

http://www.promise.com/search.asp?Keywor...=50&Send=Go might just be what I'm looking for... 1. FastTrak TX2000 Brief: Ultra ATA/133 RAID 0, 1, and 0+1 Controller FastTrak™ TX2000 raises consumer-based ATA RAID to professional levels. The FastTrak TX2000 ATA RAID card supports Ultra ATA/133 drives to rock workstations and boost small (or large) office servers like never before.

http://www.ntcompatible.com/article.php?sid=9564 might be a solution, if I could find corresponding drivers for Promise FastTrak 133 [instead of 100]

Re: "thekourier" Decent analysis... Yes, the ASUS A7V333 provides ATA/133, as the BIOS and POST both acknowledge. It winds up being 19,929 / 255 / 63 CHS x 512 Bytes/sector = 193,928 MB. On this track at looking at the LBA in the BIOS, I experimented with the following. I set the HDD type to USER, and was now given the choice of setting the TRANSALATION METHOD: - LBA CHS CAP resets to 8422 MB - LARGE CHS CAP resets to 7927 MB - NORMAL CHS CAP resets to 528 MB - MATCH PARTITION TABLE CHS CAP resets to 528 MB - MANUAL set C = 19,929 / H = 255 / S = 63 POST still reports the drive as 163,928 MB. DISK ADMINISTRATOR *still* only sees 131,069 MB, and can still see the DATA, FOLDERS, etc on the drive... HMMMM.... WHY PERSIST? Well, if I hadn't of persisted on prior occasions, the I wouldn't have been able to map drives from an IIS 4 FTP server onto the FILESERVER.... given the MS interface, until I found an undocumented solution -- about a month later. I cannot even begin to recall all of the other solutions that I either eventually found, or discovered that there was no solution -- at all. So, this is the *beginning* of why I persist. Other reasons are the alternatives. If I were to acquire a SCSI RAID box (the box for 12 drives alone) would be in the area of $3,500 CAD + 14.5% taxes alone. Each 70 GB SCSI 3 drive would be around another $1,100 +14.5% taxes... which is fine if I have unlimited resources -- which I don't. *IF* I can manage to get this UDMA/6 or ATA/133 accessing over 127 GB limit (well, the ATA/100 limit -- different actual MB #'s depend on who's counting what, in binary or decimal mode), then I have in mind placing 6 x 160 GB HDD's in a software RAID 5, which will give me *some* kind of fail-over, in case *one* drive fails, to recover the data with a minimum of cost. So far the FileServer has cost $600 - $700, plus the cost of drives. The 160 GB Maxtors currently run as low as $400 CAD / drive OEM. Six (6) drives in a RAID 5 will provide me with an estimated 800 GB of storage in one volume set, with fail-over. So the entire 800 GB of storage will be in the range of $3,000 CAD, well withing the feasibility range of my resources as a volunteer for the IIS project, and I contribute both the knowledge, hands on time, and the funds... Does this help to explain, why? I currently speculate that the solution lies in how the O/S is accessing the information in the MBR, and whether the solution becomes yet another overlay file (like for the older, 'NORMAL' drive limit of 528 MB), creating a driver that translates the MBR information into a form that the O/S can use to access all the way to 2 terabytes, or even toying with the BIOS settings manually (like I just tried, but have not attained a solution -- yet) ... or some-such....

Just had my second email reply from MAXTOR, their current solution is to contact Microsoft for a solution. Microsoft no longer supports NT 4.0. No solution will be forthcoming from MS, short of the KB article posted above. I was retesting the HDD performance and noted some errors in prior posts, as well as a lack of my ability to duplicate prior performance. The sector size that I have is 2,048 KB per sector. The performance from slave on primary to slave on secondary IDE I produce is in the 20 MB/s to 24 MB/s. I have 2,848 files on 135 GB -- ranging from 30 MB to 700 MB in size, *.mpg digital videos. This results in something like 2 hours to copy one drive to the other, or some 80 GB/hour. There does NOT appear to be significant performance differences between 4,096 byte sectors and 2,048 byte sectors, but either one of these sector sizes produce twice the performance of 1,024 byte sectors. I pull these figures out of my head, and because I [& others] do acknowledge my cognitive abilites [sanity] am known to make errors... I am hoping to provoke MAXTOR to assist in a solution, seeing as Microsoft is out of the picture, and the ASUS appears to be working -- as indicated by the BIOS & POST. Since it also appears that the functionality of how the O/S interacts with the hard-drive has not changed from NT 4.0 to Windows 2000, I do NOT see any apparent advantage to upgrade the O/S, especially given the differences in cost...

USB 2.0 & 1394... agreed... Don't have *that* many toys... however, I'd like to be able to stuff it with 8 HDD's each 160+ GB.... and turn this puppy into a troublefree File Server... I've got some kind of 1 MB AGP video card hooked up to a 800x640 monitor -- [hay ! at least it's color!] I don't even use the on-board Audio, could put the on-board NIC to use I suppose, but I think it's more of a fact of a I/O feature packed board, [in relation to finding a board that more accurately matches my needs] whereas I wanted to be able to access the UDMA/6 -- otherwise known as ATA/133 drives... not so much for the marginal bandwidth improvement... but for the anticipated lack of SIZE limits... It was the first MoBo available from ASUS, with the AMD CPU socket that featured ATA/133, and I've got to say that I'm happy with the quality of their boards... I've currently have 3 other boxes with their MoBo's, two of them running PPro's -- if that gives you some idea of the date of *that* technology...