If this is your first visit, be sure to check out the FAQ by clicking the link above. You may have to register before you can post: click the register link above to proceed. To start viewing messages, select the forum that you want to visit from the selection below. |
|
|
Thread Tools | Display Modes |
#11
|
|||
|
|||
WinDbg: Unable to get verifier list
Kai Harrekilde-Petersen wrote:
Are you using ECC-RAM? I've seen 'unexplainable' crashes on an old non-ECC machine that was caused by memory corruption. The problem increased over time until I replaced the system with an ECC-enabled system. If you don't use ECC, try memtest86 and/or unplugging some of the RAM modules. That was on my list of things to try. Memtest86 is automatically part of my multi-boot options since I run Ubuntu. However, so far the problem hasn't really occurred under Ubuntu, just under Windows. Mind you I don't run Ubuntu long enough on this system to get an adequate idea. The machine pretty much stays on 24 hours, so it's difficult to take it down and run a memtest on it for several hours. Another reason I don't totally suspect it's RAM-related is because the problems began happening after I installed a new external USB hard drive to the system. So I'm going to investigate if that contributed to it. Yousuf Khan |
#12
|
|||
|
|||
WinDbg: Unable to get verifier list
Mark Hobley wrote:
Yousuf Khan wrote: The Windows crashes are spaced out 3 or 4 days apart, and I can't run Ubuntu on it for this long to test it. This particular system is a home server, it runs a few background apps that are only available on Windows, so it is limited to running Ubuntu only occasionally, like for example when Windows crashes. :-) To run a Windows application in Ubuntu: apt-get install wine Already have it, and it does run a few apps, which is fine. But not the one I need it to run (needs access to low-level hardware interfaces). I've also been looking at getting Virtualbox to run on this thing, but I don't really have time to get it working at the moment. And regardless, when you have virtualization, you still need Windows. Yousuf Khan |
#13
|
|||
|
|||
WinDbg: Unable to get verifier list
Jose wrote:
If you are using the small memory dump you will have that message. You need to adjust your Startup and Recovery Debugging information to do a complete memory dump and try again with a new dump file. Did you get nothing useful from !analyze -v Okay, I've had another crash, and this time I got a full core dump saved. It was the following Stop code: BugCheck 24, {1902fe, f78beba0, f78be89c, b83fb504} Probably caused by : Ntfs.sys ( Ntfs!NtfsDeleteCcb+84 ) I can't see anything particularly wrong when I run the Debugger's "!verifier" command, and get the following output: 1: kd !verifier Verify Level 9b ... enabled options a Special pool Special irql All pool allocations checked on unload Io subsystem checking enabled DMA checking enabled Summary of All Verifier Statistics RaiseIrqls 0xd50089c4 AcquireSpinLocks 0x6f16d5ff Synch Executions 0x0 Trims 0x19e7df6 Pool Allocations Attempted 0x426ff0e3 Pool Allocations Succeeded 0x426ff0e3 Pool Allocations Succeeded SpecialPool 0xddd6d41 Pool Allocations With NO TAG 0x0 Pool Allocations Failed 0x0 Resource Allocations Failed Deliberately 0x0 Current paged pool allocations 0x23b7f for 059076CC bytes Peak paged pool allocations 0x23b88 for 05910BDC bytes Current nonpaged pool allocations 0x29871 for 014AED80 bytes Peak nonpaged pool allocations 0x29888 for 014BF6E4 bytes However, when I run the "!verifier 3" command, I get what looks like an endless list of not-freed pool allocations. The list just scrolls off the debugger window and there isn't enough to time or space to capture them all. Is this normal? Yousuf Khan |
#14
|
|||
|
|||
Windows can't handle NTFS on external hard disks?
Yousuf Khan wrote:
Mark Hobley wrote: Have you changed something on the system? Has the harware changed? Has any software been updated? (Beware of automatic updates) Actually, the only change that I made to the system is that I added a second external USB HD to it. It had a previous USB HD already attached to it before, which is still attached to it, but then I picked up a second one right after Boxing Day. Come to think of it, the first crash occurred just a couple of days after that. I'm willing to entertain the possibility that this new external drive is somehow to blame, but I don't see why. It's just using a standard Microsoft USB Mass Storage driver, and so was the previous external drive. I don't think it could be due to power supply issues as I upgraded the system's power supply early last year to a high-capacity Zalman 650W unit. Yousuf Khan I've added the comp.sys.ibm.pc.hardware.storage newsgroup too, since it's looking like this is becoming storage-related. First, so to summarize again, I've now had 5 BSOD crashes on one of my systems since Christmas. The only change to my system happens to be a new external USB hard disk that I got after Christmas. The first crash occurred only a few days after attaching this device, on Dec 30th. The system previously had a similar external storage enclosure which has had no problems. They were similar, however the older drive was a 500GB formatted in FAT32, whereas the newer drive is a 1TB formatted in NTFS. Secondly, the most recent crash occurred right in the middle of a large file transfer from one my internal drives to the new external drive. This is pretty strong circumstantial evidence that something about this drive is causing the problem. But I've also been analysing the crash dumps, and they all implicate either the OS kernel itself, NTOSKRNL, or the HAL.DLL driver, or the NTFS.SYS driver. In fact the most recent BSOD was a Stop 0x24 (NTFS_FILE_SYSTEM) right on the NTFS.SYS driver (see quote below): BugCheck 24, {1902fe, f78beba0, f78be89c, b83fb504} Probably caused by : Ntfs.sys ( Ntfs!NtfsDeleteCcb+84 ) So the question is, perhaps USB hard disks formatted to NTFS might not respond fast enough to the system's liking, since NTFS usually goes on internal hard disks. Is there some way to increase a timeout or anything for this drive? I always wondered why Microsoft bothered to create a new ExFAT file system, to replace FAT32, when NTFS was already around. This might be the answer. Yousuf Khan |
#15
|
|||
|
|||
WinDbg: Unable to get verifier list
Yousuf
See the following http://support.microsoft.com/kb/314477 -- Peter Please Reply to Newsgroup for the benefit of others Requests for assistance by email can not and will not be acknowledged. "Yousuf Khan" wrote in message ... I've been attempting to get to the bottom of a recurring BSOD crash happening on my system. I've already had 4 crashes so far over the past two weeks. So I've identified that NTOSKRNL.EXE is involved in all of them so far. It always somewhere in the stack. So I enabled Driver Verifier on NTOSKRNL, as well as HAL.DLL, NTFS.SYS, and FLTMGR.SYS which were also identified on the stack during various of the events. Okay so I had my latest crash yesterday, and it occurred on NTOSKRNL as well. The Verifier was already enabled on the system prior to this crash, and then when go to Windbg and execute the "!verifier" command, it comes back with the message, "Unable to get verifier list". Why not, it should be enabled? When I check them on the command-prompt I get the following output back, and they confirm that all of the files are being monitored. So can somebody familiar with Driver Verifier and Windbg help me out here? Yousuf Khan *** verifier /query 10/01/2010, 3:30:34 PM Level: 0000009B RaiseIrqls: 314843045 AcquireSpinLocks: 1893615496 SynchronizeExecutions: 0 AllocationsAttempted: 90514901 AllocationsSucceeded: 90514901 AllocationsSucceededSpecialPool: 7614086 AllocationsWithNoTag: 0 AllocationsFailed: 0 AllocationsFailedDeliberately: 0 Trims: 2452146 UnTrackedPool: 2872921 Verified drivers: Name: ntoskrnl.exe, loads: 1, unloads: 0 CurrentPagedPoolAllocations: 83397 CurrentNonPagedPoolAllocations: 77485 PeakPagedPoolAllocations: 87305 PeakNonPagedPoolAllocations: 77674 PagedPoolUsageInBytes: 49624396 NonPagedPoolUsageInBytes: 11791484 PeakPagedPoolUsageInBytes: 49827760 PeakNonPagedPoolUsageInBytes: 12139000 Name: hal.dll, loads: 1, unloads: 0 CurrentPagedPoolAllocations: 0 CurrentNonPagedPoolAllocations: 4 PeakPagedPoolAllocations: 8 PeakNonPagedPoolAllocations: 6 PagedPoolUsageInBytes: 0 NonPagedPoolUsageInBytes: 992 PeakPagedPoolUsageInBytes: 768 PeakNonPagedPoolUsageInBytes: 32784 Name: fltmgr.sys, loads: 1, unloads: 0 CurrentPagedPoolAllocations: 2 CurrentNonPagedPoolAllocations: 7161 PeakPagedPoolAllocations: 16 PeakNonPagedPoolAllocations: 7173 PagedPoolUsageInBytes: 16 NonPagedPoolUsageInBytes: 1166244 PeakPagedPoolUsageInBytes: 3440 PeakNonPagedPoolUsageInBytes: 1169508 Name: ntfs.sys, loads: 1, unloads: 0 CurrentPagedPoolAllocations: 32443 CurrentNonPagedPoolAllocations: 28514 PeakPagedPoolAllocations: 33133 PeakNonPagedPoolAllocations: 29174 PagedPoolUsageInBytes: 9261776 NonPagedPoolUsageInBytes: 1880368 PeakPagedPoolUsageInBytes: 9472944 PeakNonPagedPoolUsageInBytes: 1965028 |
#16
|
|||
|
|||
Windows can't handle NTFS on external hard disks?
In comp.sys.ibm.pc.hardware.storage Yousuf Khan wrote:
Yousuf Khan wrote: Mark Hobley wrote: Have you changed something on the system? Has the harware changed? Has any software been updated? (Beware of automatic updates) Actually, the only change that I made to the system is that I added a second external USB HD to it. It had a previous USB HD already attached to it before, which is still attached to it, but then I picked up a second one right after Boxing Day. Come to think of it, the first crash occurred just a couple of days after that. I'm willing to entertain the possibility that this new external drive is somehow to blame, but I don't see why. It's just using a standard Microsoft USB Mass Storage driver, and so was the previous external drive. I don't think it could be due to power supply issues as I upgraded the system's power supply early last year to a high-capacity Zalman 650W unit. Yousuf Khan I've added the comp.sys.ibm.pc.hardware.storage newsgroup too, since it's looking like this is becoming storage-related. First, so to summarize again, I've now had 5 BSOD crashes on one of my systems since Christmas. The only change to my system happens to be a new external USB hard disk that I got after Christmas. The first crash occurred only a few days after attaching this device, on Dec 30th. The system previously had a similar external storage enclosure which has had no problems. They were similar, however the older drive was a 500GB formatted in FAT32, whereas the newer drive is a 1TB formatted in NTFS. Secondly, the most recent crash occurred right in the middle of a large file transfer from one my internal drives to the new external drive. Maybe you have some USB disconnects and the NTFS layer gets confused. As NTFS flushes some data with high priority, I would imagine this can happen. This is pretty strong circumstantial evidence that something about this drive is causing the problem. But I've also been analysing the crash dumps, and they all implicate either the OS kernel itself, NTOSKRNL, or the HAL.DLL driver, or the NTFS.SYS driver. In fact the most recent BSOD was a Stop 0x24 (NTFS_FILE_SYSTEM) right on the NTFS.SYS driver (see quote below): BugCheck 24, {1902fe, f78beba0, f78be89c, b83fb504} Probably caused by : Ntfs.sys ( Ntfs!NtfsDeleteCcb+84 ) So the question is, perhaps USB hard disks formatted to NTFS might not respond fast enough to the system's liking, since NTFS usually goes on internal hard disks. Is there some way to increase a timeout or anything for this drive? That should not be the cause. You would need to get USB errors to cause this behaviour and moybe you have some. It is possible thet the FAT32 driver is more resilient, also because it is far mor simple and NTFS is a complexity nightmare. I always wondered why Microsoft bothered to create a new ExFAT file system, to replace FAT32, when NTFS was already around. This might be the answer. Indeed. Also they have ExFAT better locked down with patents and hope that people will be stupid enough to adopt it anyways. Arno -- Arno Wagner, Dr. sc. techn., Dipl. Inform., CISSP -- Email: GnuPG: ID: 1E25338F FP: 0C30 5782 9D93 F785 E79C 0296 797F 6B50 1E25 338F ---- Cuddly UI's are the manifestation of wishful thinking. -- Dylan Evans |
#17
|
|||
|
|||
Windows can't handle NTFS on external hard disks?
Yousuf Khan wrote:
Yousuf Khan wrote: Mark Hobley wrote: Have you changed something on the system? Has the harware changed? Has any software been updated? (Beware of automatic updates) Actually, the only change that I made to the system is that I added a second external USB HD to it. It had a previous USB HD already attached to it before, which is still attached to it, but then I picked up a second one right after Boxing Day. Come to think of it, the first crash occurred just a couple of days after that. I'm willing to entertain the possibility that this new external drive is somehow to blame, but I don't see why. It's just using a standard Microsoft USB Mass Storage driver, and so was the previous external drive. I don't think it could be due to power supply issues as I upgraded the system's power supply early last year to a high-capacity Zalman 650W unit. Yousuf Khan I've added the comp.sys.ibm.pc.hardware.storage newsgroup too, since it's looking like this is becoming storage-related. First, so to summarize again, I've now had 5 BSOD crashes on one of my systems since Christmas. The only change to my system happens to be a new external USB hard disk that I got after Christmas. The first crash occurred only a few days after attaching this device, on Dec 30th. The system previously had a similar external storage enclosure which has had no problems. They were similar, however the older drive was a 500GB formatted in FAT32, whereas the newer drive is a 1TB formatted in NTFS. Secondly, the most recent crash occurred right in the middle of a large file transfer from one my internal drives to the new external drive. This is pretty strong circumstantial evidence that something about this drive is causing the problem. But I've also been analysing the crash dumps, and they all implicate either the OS kernel itself, NTOSKRNL, or the HAL.DLL driver, or the NTFS.SYS driver. In fact the most recent BSOD was a Stop 0x24 (NTFS_FILE_SYSTEM) right on the NTFS.SYS driver (see quote below): BugCheck 24, {1902fe, f78beba0, f78be89c, b83fb504} Probably caused by : Ntfs.sys ( Ntfs!NtfsDeleteCcb+84 ) So the question is, perhaps USB hard disks formatted to NTFS might not respond fast enough to the system's liking, since NTFS usually goes on internal hard disks. Is there some way to increase a timeout or anything for this drive? I always wondered why Microsoft bothered to create a new ExFAT file system, to replace FAT32, when NTFS was already around. This might be the answer. Yousuf Khan Don't know if any of this is relevant, but... I started having file transfer problems when I installed vista. Network file transfers to/from XP failed randomly, but only when the file being transferred exceeded ~4MB and was in the middle of a multi-file transfer. Also seemed to matter which end of the pipe initiated the transfer. I couldn't make a vista to vista file transfer fail. I use totalcommander as my file manager. It has the option to use file transfer compatibility mode, whatever that is. Doesn't fail in that mode, so I quit looking for the problem. I've had usb file transfer failures to external drives when using the front-mounted ports on my dell. Hubs are a no-no. If I look in device manager, I see more entries for root hubs than for controllers. Don't know exactly what this means, but sometimes, moving the usb drive to another port helps. Bus-powered drives are problematic, but I expect your TB drive isn't. Power supplies that come with external drives are problematic. Might be worth a look at the PS voltages with a scope under load. There have been numerous complaints about recent generations of hard drives in the 1TB range. NTFS doesn't seem to matter on smaller drives where you can do a direct ntfs/fat32 comparison on the same hardware. |
#18
|
|||
|
|||
Windows can't handle NTFS on external hard disks?
In comp.sys.ibm.pc.hardware.storage mike wrote:
Yousuf Khan wrote: Yousuf Khan wrote: Mark Hobley wrote: Have you changed something on the system? Has the harware changed? Has any software been updated? (Beware of automatic updates) Actually, the only change that I made to the system is that I added a second external USB HD to it. It had a previous USB HD already attached to it before, which is still attached to it, but then I picked up a second one right after Boxing Day. Come to think of it, the first crash occurred just a couple of days after that. I'm willing to entertain the possibility that this new external drive is somehow to blame, but I don't see why. It's just using a standard Microsoft USB Mass Storage driver, and so was the previous external drive. I don't think it could be due to power supply issues as I upgraded the system's power supply early last year to a high-capacity Zalman 650W unit. Yousuf Khan I've added the comp.sys.ibm.pc.hardware.storage newsgroup too, since it's looking like this is becoming storage-related. First, so to summarize again, I've now had 5 BSOD crashes on one of my systems since Christmas. The only change to my system happens to be a new external USB hard disk that I got after Christmas. The first crash occurred only a few days after attaching this device, on Dec 30th. The system previously had a similar external storage enclosure which has had no problems. They were similar, however the older drive was a 500GB formatted in FAT32, whereas the newer drive is a 1TB formatted in NTFS. Secondly, the most recent crash occurred right in the middle of a large file transfer from one my internal drives to the new external drive. This is pretty strong circumstantial evidence that something about this drive is causing the problem. But I've also been analysing the crash dumps, and they all implicate either the OS kernel itself, NTOSKRNL, or the HAL.DLL driver, or the NTFS.SYS driver. In fact the most recent BSOD was a Stop 0x24 (NTFS_FILE_SYSTEM) right on the NTFS.SYS driver (see quote below): BugCheck 24, {1902fe, f78beba0, f78be89c, b83fb504} Probably caused by : Ntfs.sys ( Ntfs!NtfsDeleteCcb+84 ) So the question is, perhaps USB hard disks formatted to NTFS might not respond fast enough to the system's liking, since NTFS usually goes on internal hard disks. Is there some way to increase a timeout or anything for this drive? I always wondered why Microsoft bothered to create a new ExFAT file system, to replace FAT32, when NTFS was already around. This might be the answer. Yousuf Khan Don't know if any of this is relevant, but... I started having file transfer problems when I installed vista. Network file transfers to/from XP failed randomly, but only when the file being transferred exceeded ~4MB and was in the middle of a multi-file transfer. Also seemed to matter which end of the pipe initiated the transfer. I couldn't make a vista to vista file transfer fail. I use totalcommander as my file manager. It has the option to use file transfer compatibility mode, whatever that is. Doesn't fail in that mode, so I quit looking for the problem. I've had usb file transfer failures to external drives when using the front-mounted ports on my dell. Hubs are a no-no. I find this surprising. I have both used long USB cables (5m) and USB hubs to transfer large volumes of data. However that was with Linux, it is possible that Windows vista / 7 has a very low resilience to USB errors. Linux does up to 4 (I think) retries and bus reset on disk access errors, whether it is (S)ATA or USB. If vista / 7 fails the transfer directly after any error, that would explain the ibserved behaviour. Long cables and USB hubs make errors more likely. If I look in device manager, I see more entries for root hubs than for controllers. Don't know exactly what this means, but sometimes, moving the usb drive to another port helps. That means that there are "virual hubs". Bus-powered drives are problematic, but I expect your TB drive isn't. Again, depends. They have a tendency to cause more transfer errors, but not to unusability, at least not with Linux. Power supplies that come with external drives are problematic. Might be worth a look at the PS voltages with a scope under load. I agree. However I did the scope test with one that caused one specific drive to have problems and I did see nothing with a 10MHz 10mV/div (elCheapo, I know) scope. I also played around a bit with one of these PSUs and it seems some have very little stability margin. There have been numerous complaints about recent generations of hard drives in the 1TB range. Oh? I have several Samsungs and WDs and no issues. I don't remember reading more about these or other 1TB drives. Do you have specifics? NTFS doesn't seem to matter on smaller drives where you can do a direct ntfs/fat32 comparison on the same hardware. So far the advantage I see for NTFS is extended attributes, i.e. per user permissions. For a single-user machine and for external drives this is rather irrelevant. Arno -- Arno Wagner, Dr. sc. techn., Dipl. Inform., CISSP -- Email: GnuPG: ID: 1E25338F FP: 0C30 5782 9D93 F785 E79C 0296 797F 6B50 1E25 338F ---- Cuddly UI's are the manifestation of wishful thinking. -- Dylan Evans |
#19
|
|||
|
|||
Windows can't handle NTFS on external hard disks?
mike wrote:
Don't know if any of this is relevant, but... I started having file transfer problems when I installed vista. Network file transfers to/from XP failed randomly, but only when the file being transferred exceeded ~4MB and was in the middle of a multi-file transfer. Also seemed to matter which end of the pipe initiated the transfer. I couldn't make a vista to vista file transfer fail. Weird. There's apparently a new networking paradigm with Vista and 7 than there was for XP. You need to enable some kind of compatibility mode to make it work with XP. I've had usb file transfer failures to external drives when using the front-mounted ports on my dell. Hubs are a no-no. Good point, I just plugged the drives into whatever free ports were available at the time without much thought. I just now traced them all, and it looks like the drive was plugged into a hub -- actually both external drives were plugged into the same hub! I've now rearranged some wires and put them directly on their own motherboard ports. Let's see if that helps out. Yousuf Khan |
#20
|
|||
|
|||
Windows can't handle NTFS on external hard disks?
Arno wrote:
In comp.sys.ibm.pc.hardware.storage mike wrote: Yousuf Khan wrote: Yousuf Khan wrote: Mark Hobley wrote: Have you changed something on the system? Has the harware changed? Has any software been updated? (Beware of automatic updates) Actually, the only change that I made to the system is that I added a second external USB HD to it. It had a previous USB HD already attached to it before, which is still attached to it, but then I picked up a second one right after Boxing Day. Come to think of it, the first crash occurred just a couple of days after that. I'm willing to entertain the possibility that this new external drive is somehow to blame, but I don't see why. It's just using a standard Microsoft USB Mass Storage driver, and so was the previous external drive. I don't think it could be due to power supply issues as I upgraded the system's power supply early last year to a high-capacity Zalman 650W unit. Yousuf Khan I've added the comp.sys.ibm.pc.hardware.storage newsgroup too, since it's looking like this is becoming storage-related. First, so to summarize again, I've now had 5 BSOD crashes on one of my systems since Christmas. The only change to my system happens to be a new external USB hard disk that I got after Christmas. The first crash occurred only a few days after attaching this device, on Dec 30th. The system previously had a similar external storage enclosure which has had no problems. They were similar, however the older drive was a 500GB formatted in FAT32, whereas the newer drive is a 1TB formatted in NTFS. Secondly, the most recent crash occurred right in the middle of a large file transfer from one my internal drives to the new external drive. This is pretty strong circumstantial evidence that something about this drive is causing the problem. But I've also been analysing the crash dumps, and they all implicate either the OS kernel itself, NTOSKRNL, or the HAL.DLL driver, or the NTFS.SYS driver. In fact the most recent BSOD was a Stop 0x24 (NTFS_FILE_SYSTEM) right on the NTFS.SYS driver (see quote below): BugCheck 24, {1902fe, f78beba0, f78be89c, b83fb504} Probably caused by : Ntfs.sys ( Ntfs!NtfsDeleteCcb+84 ) So the question is, perhaps USB hard disks formatted to NTFS might not respond fast enough to the system's liking, since NTFS usually goes on internal hard disks. Is there some way to increase a timeout or anything for this drive? I always wondered why Microsoft bothered to create a new ExFAT file system, to replace FAT32, when NTFS was already around. This might be the answer. Yousuf Khan Don't know if any of this is relevant, but... I started having file transfer problems when I installed vista. Network file transfers to/from XP failed randomly, but only when the file being transferred exceeded ~4MB and was in the middle of a multi-file transfer. Also seemed to matter which end of the pipe initiated the transfer. I couldn't make a vista to vista file transfer fail. I use totalcommander as my file manager. It has the option to use file transfer compatibility mode, whatever that is. Doesn't fail in that mode, so I quit looking for the problem. I've had usb file transfer failures to external drives when using the front-mounted ports on my dell. Hubs are a no-no. I find this surprising. I have both used long USB cables (5m) and USB hubs to transfer large volumes of data. However that was with Linux, it is possible that Windows vista / 7 has a very low resilience to USB errors. Linux does up to 4 (I think) retries and bus reset on disk access errors, whether it is (S)ATA or USB. If vista / 7 fails the transfer directly after any error, that would explain the ibserved behaviour. Long cables and USB hubs make errors more likely. If I look in device manager, I see more entries for root hubs than for controllers. Don't know exactly what this means, but sometimes, moving the usb drive to another port helps. That means that there are "virual hubs". Bus-powered drives are problematic, but I expect your TB drive isn't. Again, depends. They have a tendency to cause more transfer errors, but not to unusability, at least not with Linux. Power supplies that come with external drives are problematic. Might be worth a look at the PS voltages with a scope under load. I agree. However I did the scope test with one that caused one specific drive to have problems and I did see nothing with a 10MHz 10mV/div (elCheapo, I know) scope. I also played around a bit with one of these PSUs and it seems some have very little stability margin. There have been numerous complaints about recent generations of hard drives in the 1TB range. Oh? I have several Samsungs and WDs and no issues. I don't remember reading more about these or other 1TB drives. Do you have specifics? Don't know how you missed it. Back around September, the press was so bad on Seagate .11 series drives in the 1-1.5TB range that they were practically giving them away. They had a program for free data recovery if you sent in your permanently-locked-up drive. Not clear how many firmware updates they had. Seems that people were not satisfied that the firmware fix did anything other than throttle the performance. Interesting coincidence that they also changed the warranty from 5-years to, I think, three. I stayed away from that whole mess. NTFS doesn't seem to matter on smaller drives where you can do a direct ntfs/fat32 comparison on the same hardware. So far the advantage I see for NTFS is extended attributes, i.e. per user permissions. For a single-user machine and for external drives this is rather irrelevant. Doesn't fat32 have a 4GB file size limit? Big problem if you store DVD images or large backup files on your external drive. Arno |
Thread Tools | |
Display Modes | |
|
|
Similar Threads | ||||
Thread | Thread Starter | Forum | Replies | Last Post |
Once you have completed your preparation to list the item, you willneed to choose a price. Take into consideration the original cost of the item,its current condition and items that are similar on the website. You are nowready to list your used cloth | [email protected] | Homebuilt PC's | 0 | April 21st 08 11:16 AM |
P4 FSB a b c 2.8c 2.8b 2.4b 2.4c e.t.c. what does it mean? + list of p4 temps? | [email protected] | Intel | 4 | August 27th 06 12:52 AM |
List? | JimNorma | Dell Computers | 11 | April 23rd 04 09:34 PM |
best CPU to OC out of the list | Daniel Czajko | Overclocking AMD Processors | 3 | March 2nd 04 06:54 PM |
Where to list this? Thanks! | [Portatiles] | UK Computer Vendors | 6 | September 25th 03 11:32 AM |